Engineering Successful IAM Projects to Support Digital Business

Welcome to our call webinar engineering successful. I am projects to support digital business. The speakers today are who is CTO at IC consult group and me Martin principle Analyst at Analyst Analyst in the next 45, 50 55 minutes entre. And I will share some of our experience. We have guys over the past 15, 20, or even more years around making IM projects success. Before we start, I'd like to quickly highlight some upcoming events. And I also like to do some housekeeping. And then we directly dive into the context of today or the content of today's webinar.

We have two upcoming virtual events in early next year. One is about becoming a better privileged access manager. So it's a privileged access management team. One is called zeroing in on zero trust. Both I believe very important and very interesting themes. And then in, from May 10th to 13, we will run our European identity and cloud conference. The most relevant identity management gathering globally. You run the EIC in Berlin or on online. So you can choose which approach you want to take regarding housekeeping. We are doing the audio control, so you don't have to care about that.

We will do a Q and a session by the end, but you also can enter your questions at any time. So the more questions we have, the better it is, we are recording the webinar. Slides are not that much this time, because it's mainly guiding through the conversation I have and we will do polls. So we will do two polls in fact, and the first poll I'd like to right now. So please take a few moments to, to answer and to pick your question and the Polish one, which is about your experiences with the reasons for IM projects, stalling or even failing.

So is it lack of budget, insufficient stakeholder management, insufficient requirements gathering too much of a technology focus or a lack of proper expectation management. So which of these see you as the biggest reason, please take a few seconds to enter your, your results. The more we have to better it is I give you another 15 to 20 seconds. Okay. I think we can close the poll. Thank you. We will pick this up later on latest during the Q and a session. And with that, let's have a look at the agenda. This is a very, very lean agenda today because it only has two points.

The one is the Q and a are already mentioned. The O is, and entre should be visible here as well in the second. The second is really, and so our first point, but I have this second I talk about is about lessons from practice. What to look at for engineering successful IM projects, welcome entre. Maybe you give a quick intro about yourself and then we dive into our subject.

Oh, here we go. Yeah. Thank you very much, Martin. Yeah. My name is I'm the C of the I group and I near the 18 GS.

And as, as a consult, we are completely focused on digital identities, identity, access management, management, privileged access management. And so everything in that, in that, in that area.

And yeah, the roots of the company are Germany, but we are not just in German speaking markets in Europe, expanded to the UK, us Spain, China, and recently started our subsidiary. Ingar Okay.

So entre, we know each other for quite a couple of years already. And as I said, we, we want to discuss a couple of, of things. And a couple of, we have sort of lessons and seems we have looked at.

And, and so the one I'd like to start with is requirements. So my experience is that one of the most important things, but frequently not done as good as it could be is grasping requirements. So I've seen everything from the very long lists and sometimes really good ones, not only the ones we deliver to whatever list of audio. So unstructured criteria, my perspective is that this is really the starting point to, to take time for that exercise.

And not only look at today, so what you have today and what you feel is missing, but try to understand how will will the market segment, how will the technology, how will demand potentially change over the next couple of years? What is your take on that?

Yeah, there are some, some points which, which are important. We, every two perspectives on that. One is being part of the process, gathering the requirements together with the customer to figuring out what other requirements and then how kinda solution look like. And the other perspective, and the requirements has been gathered by the customer by some, some maybe external support. And then we on the side of getting a view as an system integrator, who proposal to implement such a solution, so different perspectives, but anyhow, what, what are the points from my perspective?

So first of all, gathering these requirements in a niche like identity access management is not very easy because the knowledge required for doing that is not everywhere available within the it and within the business organization. So therefore upfront some education is often required to, to be able to, to, to gather these requirements, to, to talk with a, with, with a customer about, about what, what should the solution look like and what should it fulfill at the end of the day? That's that's one, one very, very important aspect. Yeah. Yeah.

And I think that's a good point because, and I think two good points at the end. So the one is everyone needs this requirements. It's the end organization to, at the end, the right solution and to implement it the right way to prioritize cetera. I think the second point is yes, you as a system integrator, for instance, it helps you a lot because you better understand what is the prioritized feature set, et cetera. And it also helps the vendor to, to come up with, okay. They would always try to sell, but at the end, they can come up with a better understanding of this.

Is this really a fit and what will be complex in the project, etcetera. The point I like this year is so I can trust convince it that it's this knowledge. When I look at some of the, the things we are doing, then part of that is really the customers educating them. What is the terminology? What are the segments in the market? What are you really looking for? And very frequently, it is a multistep approach, educating them, identifying out of the bigger areas within identity management.

So access management versus user lifecycle provisioning versus privilege, access management, others, what are the big blocks first prioritized these and then go into the detailed requirements for each and every broad check and saying, okay, what is what you specifically need here? And, and I think the other point is not only creating a list of priorities, but also of requirements, but also prioritizing that list because, and having some but few ma criteria.

So, so I've seen projects where, where this list consisted of more than 30, 40 ma criteria, which inevitably means no vendor will fulfill the requirements because if you have too many ma criteria, then that definitely will be at least one criteria per vendor where the vendor fails. And so I, I, I, my, my hint is always stay around 10 at maximum for math criteria. You might have high priorities for, you should also have low priorities, but for do this exercise.

Yeah, I completely agree because implementing this project, typically the 60 must criterias at the end of the day are not 60 must. Criterias maybe 20, because a couple of requirements, which are well must because of, of misunderstanding or because that, that the team was not aware about alternative approaches, how to solve it, maybe better, maybe in a modern way, these kind of things.

And therefore, really like the point prioritize really important and not trying, it's really not, not vendor on a product of able to deliver, but there's one other point, which is, well, typically we learn more about the things which went wrong than what we did right by accident, right. What you can really do wrong. And it's about requirements engineering is following an approach. We are going to focus just on an MVP. Yeah. Just on the first iteration.

I'm not interested in, in anything else, because if you are starting that way, you'll realize I have just very requirements and implement implementing these kind of things from the outgoing of software is much more efficient, faster. Yeah. I can do that. Anyhow.

After 2, 3, 4 iterations, it'll completely different than you're stuck as a solution. You cannot maintain.

And, But, but, but it's, it's a little bit of common standing of, of air trial methodologies in some way, because child is not trust the now part. It's also the soon part and the later part and actual that never happens in a, in a, without any restrictions. So actual development happens in a defined environment in a sort of a defined flavor. And I think, yes, it's important. We'll touch this later on.

Maybe, maybe we go also to the next point here. So we understand requirements gathering prioritization. It's a super important thing, because this is really what ensures that you at the end pick something and implement it in a way, in an order that meets your requirements. The second theme I'd like to bring up is stakeholders. And you probably can also tell a ton of stories around situations where stakeholder and expectation management sort of costs some of the, the trouble. And I was also this, this overpromising the quick wining.

So, so maybe you, you can tell a little bit from your experience here. Yes, sure. Yeah. Expectation management is something which is really important because what is typically happening it's process, the requirements are gathered then are presenting their solutions approaches. There is actually kind of overselling over promising and everything is simple to implement. There are no no problems which cannot be solved very easily by that extremely innovative product, this kind, this kind of, of thing.

And, and also looking into the requirements, of course, the product supports password less MFA, and it supports windows. And so on realizing that this product is not supporting past what less MFA for the windows login is something which then happens inside the project after a solution selected and, and so on.

And it, these are typically the things which then resides in burn situation where safe protection of not met. And that's something, what, what we all of course want, want to prevent. Yeah.

And, and, and I think the end, it all starts for my first point is stakeholders. So who's involved in the problem is identity management or the challenges you always is a cross system approach. It's not just something you do in your small domain, but it affects, it means you talk with HR, you talk with a ton of application owners, you talk with the security people with infrastructure, people, and so on. It is not a, a simple thing.

And, and the other thing is I think then giving or managing the expectations in appropriate manner and just over promising, I think this is, and you bring it up. Yes. When there's, I think that's by nature. And that's also okay that they, they are sort of oversimplifying some of the things. And I think it's important that, that we, that, that everyone in the project doesn't over promise.

And I'm a big believer in this, this idea of having not only quick wins, defined, I think everyone has learned this over the years, defined what your quick wins are, but also thinking about what are the big wins, what will be, what I deliver at the end, or after a larger pace of my project as the, the bigger achievement. And, and, and maybe maybe to add something, or you mentioned is important of this stakeholder management and cannot agree more because what is really required during an IM project.

And it's nearly the case in all projects, latter projects I'm aware of is the support of the, of the management. And, and because Martin, you mentioned, yeah, it's something which is affecting the whole organization. And you need the applications from the specific business unit, maybe an, maybe an application it network team, maybe from HR, whatever. But if you do not have as a, didn't a stakeholder management in a good way, you would likely not get the support if it is required. And you have delays in the project, not, not able to fulfill the time, timelines again, expectations not met.

And, and, and, and therefore, therefore it's reverse spending time, time, time on that understanding who are my stakeholders, talking to them, what are their expectations in order, in order to make the project success? It's always, yeah. And this list of stakeholders always gets longer as, than the people think at the beginning of the project.

So, so talking about expectations, I think that that is very close to, to the buy-in of everyone. So it's not only saying this is what we will do, but it's also getting them on board.

So, so either by, by saying, okay, this is free. What we want you to deliver best case, or at least, okay. I have understood the need for that. And I will not sort of become an obstacle on that, on that way, because so sometimes it is that they say, okay, do what you want.

Don't, don't both me with that. But I, I think this understanding is important because what I learned over the years is if you do an identity management project and you as a system integrator, you, you are way longer in this projects. And that we as analysts are, it is about, there will be a storm. There will be the need to weather the storm at a certain time. And only if the people have understood what you're doing.

And also if the entire project team knows why did have chosen the tool, why they pick the system, create why they follow that approach only then, then we able to stand sort of well and good and stay on their boat, tearing a storm. Exactly. At the beginning, we do not know from whos organization, we will need need support, but we are sure we will need that from a couple of, of people, couple from of departments.

And while, if any reason, this is not, not happening as expected, then we, we need our champion in the organization yeah. To make, to make sure that we get it, which is required.

Otherwise, there are a couple of, of persons which can make such a project fail. That's, that's, that's easy.

And, and that's, that's what, what all want prevent. Yeah. And it costs, it costs so much power and time to deal with these obstacles and with typically very few persons, which, which take a different, and I think that is something you, you ideally solve at the beginning and that at the end or during the project, which also means we, we need to talk about organization at the end, we need my strong belief. We need to, we need to have to have identity management being a department of its own. So it's not part of infrastructure. It's not just part of security.

It's identity and access management is too important from my perspective, from a digital business. And it shouldn't be many identity management departments not to speak about what still S identity management here and access management here. No go for one identity management organization. That's my perspective, what your Experience's.

So, so cause it's of course, very closely related to, to it security and bring a very, very important role maybe today, even more than, than in the past. But, but on the other hand, it's also about business enablement. It is about providing digital services to enable, to enable collaboration alliances between enterprises. This is all going cause of, of, of the digital identities and the capabilities provided by, by these, by these solutions and dedicated team makes absolutely absolutely sense.

Also it is, from my perspective, very important to have a very strong product owner, because there will be a lot of demand from the whole organization, of course, focusing on their very, very specific problems and identity access management cannot solve all of them, but have to make, make sure that it's providing value to the whole organization. And not just to this very specific single requirements of very specific single, single use case.

So that's, it's a trade off and, and therefore strong product owners also very important to make. So program successful, How would you structure an IM organization?

So, so have you any, any sort of S structures as the, sort of the bigger areas within identity management? So do we, do you do it more per, per technology area or more like operations and the sort of the IM core functions, like managing roles and then more business oriented functions. So what is your preference? Yeah. So first of all, I would completely agree that that should the organization should one head, which is covering, covering the whole aspect. Yeah. So there are different approach, which, which can be successful.

So for example, going from a functional perspective makes some more sense because it's the technologies, which is used the protocols, which are relevant, are different. Yeah. So from novel perspective, makes sense to have IGA, to have plan to havea management, these kind of things. On the other hand, the counterparts, the application owners on the other side are then talking to different people and different teams maybe.

And that, that is a drawback of that approach from my perspective, therefore, therefore, I, I like having approach in which we are more focusing on the types of identities. Yeah.

Having, yeah. The customers, consumer identities on the one side and the B2B direct for employee contractors on the other side, something like that, because then it's, it's easier for, for the digital touchpoint application owners, mobile apps to, to integrate and connect Tom world. Yeah. I also like sort of having layers because especially when you look at the operations part, that part is, is more and more run and managed services like you do as part of your consult group.

So that is something where you have sometimes really a different model where, where parts are not within your organizations while, while the, the inner parts are managing S that are commonly something more internal and also skill requirements at the different layers are, are, are vastly different. And can it also to be somewhere of a governance department clearly in that, but all of that will need without any doubt that will need skills.

And so I, I think everyone in identity management ever run in cybersecurity is, is currently confronted with this skills gap. There are just not enough experienced educated people out there, which, which are the identity management experts.

You might, you might need him. So, so my perspective on that is that it's very important anyway, to, and not only have the externals, I think you will always need him. You rarely can run something, a large intervention project of, so just with CRT, but I also believe in, in erring knowledge.

So my, my perspective is always a project is good and the customer is under able to do it sort of himself write it himself. Then I did a broker job. Yeah.

So that's, that's, that's our experience as well. So first of all, there might be the idea, if so, as system integrator, if the customer has no knowledge about it, you cannot be replaced there.

But, but it's exactly the opposite as opposite thing for the following reason. Yeah. Someone who is, has no clue about what you are doing for them. It is simple. Yeah. IM can be done by company a can be done by company B. I can exchange them easily. As soon as someone is getting deep understanding about what, what is happening there. As soon as you understand the complexity, it's not so likely for the, for the contractor to be, to be replaced. That's one thing, the other thing is an identity access management solution on identity program in an enterprise can only be successful.

If, if the owner within the organization is able to sell the solution to, into his, his own company. And without an understanding, this is also not, not possible.

Therefore, we believe that information hiding is, would be completely damaging the relationship, being bad for the company and being there for their I consult is contractors as well. So being educating the customer to understand, really understand the challenges, understand the solution. That's something is best players, The same are not looking for, but they, they need to understand what they're doing. And you will be more successful in your project if you have a good counterpart, because you will move way faster in that case.

And, and so I think it it's, it leads to better relationship and better relationships last longer. It's, it's relatively simpler.

So, so one of the other favorite themes I have and, you know, requirements gathering are not probably done requirements gathering is one of the things I see as one of the biggest challenges. The second one I, I, I really see is sort of, I call it trust technology overkill. It is this, this two technology focused approach, starting with a tool, not having done the, the crown work before.

So, so like you want to build ours and, and you end up with like the, the tower of pizza out because it's the crown wasn't prepared well, and it was the wrong thing at the blend didn't work and stuff like that.

But, but, but even reverse, I, you know, I sometimes see than than companies and they have a list of, of vendors they want to look at, and these are not only apples and oranges, but these are apples, they're tomato and cucumber, whatever else, it's, it's a total totally nonsense mix of, of vendors because they requirements customer is understanding everything, but I I've seen it part of frequent. So do You think, yeah, so we have sometimes the situation that we entering a project and a later stage. Yeah. So the products are decided. Yeah.

And the high level architecture, some somehow designed up in the situation that is, unfortunately doesn't fulfill the requirements, which are now there up during, during the, the project, because our missing pieces. Yeah. Then in situation that, to introduce additional tools. Yeah. Because the selected solution can just not solve it. Some others would have thought everything, but anyhow, wasn't selected. So which then has an impact on the timeline and of course, on the budget and these kind, these kind of, of things, and that's unfortunately happening more than you would all like to see that.

Yeah. And so I'm getting the very good understanding upfront is, is very, very critical. Yeah.

Just, just, just one, one point. It doesn't matter how good the requirements engineering is. It'll not be complete. So a couple of requirements which will come in a later stage. Yeah. Maybe after the product is finished. Yeah. And so not focusing just on the existing requirements, but also having in mind to build a very, very flexible solution. That's something which is really, really important because of lifetime of an identity access management solution is often, much larger, some expected before Solution. Yeah.

That leads us later on also to, to a little bit touching modern architecture and stuff like that. I think we can do a lot if we do it, do it implemented. Right.

But yes, the requirement gatherings never will be complete. And, and our experience, you do the RFI. And then when you prepare for the POC, you already have some, some additional requirements already. You can check there and then you need the flexibility. But before that, I, I strongly believe in saying, okay, I have some big picture of identity management. I know where I want to move. And I also recommend strongly in west time and defining processes. And I believe it helps you, for instance, massively, if a customer says, these are all the processes, this is how I see them.

Because as an integrator, I believe life is way simpler. Processes are well defined than when they say, oh, do the onboarding users then say, oh, but I had another idea in mind. So policies, all these things are required to be successful. Completely, completely agree. And it should spend time not before selecting the solution.

Then, then you have to spend the time later in the implementation phase anyway. Yeah.

So it's, yeah. There's no way, no way to, to go without that.

I, I, I'm a hundred percent convinced that time for planning. We don't talk about years here. We don't talk about really endless times.

We can, this can be done relatively fast and efficient, but that time always, always pays off during the implementation and later on operations of a product. So it, it is really a misconception, oh, we need it. So urgent. We can't plan probably if you do that, then you're just increasing the project risk, risk. Yeah. And likely the time for implementation anyway, And the time and the cost. So yeah. Change management entree. What's your take on that? Yeah. That's often completely underestimated again from what did not go very well. And so one approach, which I experienced a few times yeah.

Which was sometimes just, just the disasters. Okay. We have our identity access management team. They have the legacy solution. We focusing on that. And so we need integrated with building up some new IM solution for us. And then the existing team can send on the old one and take over the new one. Yeah. A big change for people who are working with a solution for 10 years or 20 years even, and now should be in charge for something which is not their child. It's something arbitrary. They don't know about it. They don't like it.

And, but they're just overruled by their management on the long run of such a project, there will be so much resistance, lack of access to that knowledge of the people, which we have the knowledge of the organization, that it will become very hard to make such a project success. And so having these kind of, of things in mind, how to, to bring a solution to the organization, what, what people will be affected, how can we make sure that they are with us said they, that is also their child. Yeah. What is now born? Yeah. That's something which is very, very important to make an project success.

And it meets again, having the stakeholders, having the people on board early, listen to them, ask with them, talk with them, explain to them. So, so does I actually, for instance, in British access management projects, the situation you say, we need to do that. And then the administrator Linux administrator say, oh, but then we can't work efficiently anymore. And this is also being prepared and saying, okay, this, this is maybe how it changes, but this might be, make it better. What do you need?

Also asking them gas tech concerns, the requirements, and it'll make projects way more successful, way better. I believe, than that. Let's them try two different alternatives to propose them.

Yeah, we can do that this way or that way. And then they can, can, can, can participate delivering their input, which is affecting their work in a few weeks or months.

And, and, and then we have friends in the organization which, which likes the solution. Otherwise they'll find the smaller, larger issues and, and complaining. Yeah. And sometimes it's also waiting a little, so supplanting the idea and, and waited for weeks. And until they come back and say, Hey, Hey, I had this great idea. Then don't, don't say, oh, that was my idea. But just say, Hey, great idea. Yeah. Okay. Focus. Also one of these things, I I've seen quite a, quite a lot of time and HR is my, my example here, but there are other areas. So HR data comes in is in horrible quality.

And, and no one feels responsible for that. At the end, the identity measurement project builds complex solutions to integrate the data, to, to improve the quality. It does a lot of work, which is not identity management. So how do we deal with these challenges?

Yeah, yeah. Yeah.

Well, very aware of, of these kind, this kind of things. For example, when there a use case defined how to fix the master data, the active directory of the, of the employees, because that's a process how they did it all the time. They're not in large our system, but in the ad. And then that's the point where we realize, oh, okay, there is an issue. The data quality and yeah. And not as mentioned, but of course it's the same.

It's the, on the CRM side, for example, if it's about the custom identities. So remembering one project where we, where we detect couple of large number of tablets in, in the, in the, in the repository, because some of the dealers out there were not entering the mail address and phone numbers of the real customers, but their own to prevent that someone add is going to contact them. Yeah. This kind of things. And if you, this, this data is a source by digital identity, this cause how, how to deal with it. Yeah.

Unfortunately there's no, no easy way, but to try really, to fix it, fix the root cause of it. Not, not making a work around, but the root cause. Unfortunately not all organizations have the access to come that point. I think before talking about the stakeholders about very high level organization, who's parting your project. This is the point in time. You have to call him and say, well, we need now your help to make the project successful. Yeah.

We, we, we need to talk and we need to understand what is the process? What is the interface? What are your responsibilities? What are our responsibilities? Let's find a solution for, for the things which are somewhere in the gray area in between. I believe that's, that's exactly the point at the end. It's about change management. It's about stakeholder management, about expectation management, about responsibilities.

And you, you know, the one thing you never should do. My, my rule, number one, when you come into a customer and the customer says, oh, you know, we have this global HR program running.

So, so we don't need to care about this because until we start really start with identity management, they will be done. Don't believe it. I've never seen the global HR program being ready when the IM program needed it. Never. Yeah. Okay. That's good. Let's get modern.

And, and I think you brought up a very important point. That is even just the best requirements gathering. And by the way, to the attendees, if you have questions, enter the questions into the questions tool into, of go to webinar so that they can pick them in the Q and a session. But back to your point, you brought up this point, you will never have a perfect requirements gathering, not for this, whatever, seven or 10 or 15 years, the IM solution will be in place.

You will, might be good. You might be horribly bad, but even if you're good, there will be things that change over time, new requirements that come in and also there's this risk of, oh, I have this special requirement can be customized.

And, and at a certain point, it's hard to possible to maintain it. So why, why do modern architectures help us here? Andre? You're the CTO. It's your team number one.

Yeah, exactly. Yeah. So we have lifetime 10 maybe, maybe, or maybe established architectural approach, which it's a little bit outdated already. How will it look like in five years and 10 years, that's, that's, that's, that's really points that we should, should really make sure that, that when we start that this is, this is really this really state state of CR. And because there will be couple of, of requirements. We cannot even imagine today, but they will be there five years. It's it's clear.

So we have to have the solution, which we can easily maintain up upgrade, which we can enhance without having too much technical, collecting too much technical depth. So of course you're talking about things like, like, like, like microservice where, you know, okay, it's much better to maintain than theistic monolithic approach talking about things like infrastructure is called configuration is called.

So these, these, these pattern that can apply, apply them to have a solution, which is easy to maintain. And, and also each very specific feature we have to implement, we should really think about, is this something, what we are able to maintain for the next decade? Yeah. Cause if you too many, too much maintenance efforts, it's not easy anymore to be flexible to, to fulfill the new, important requirements of business as Yeah. I think the good thing is that the more and more, if not most was today are, are shifting into modern architecture's modern deployment models.

So you can do all coding and segregated microservices using the APIs and, and sort of segregating it from the core product, which was a big challenge in, in older products. But yes, you, you never will be perfect, but you need to, well understand what does it mean? What does a customization mean? What is the depth?

You, you, you, you are, you are gathering here. Also. The one thing I, I, I see is that Sometimes it might be so, so, or phrase it differently. Customers sometimes say, oh, this product I have here, it doesn't work anymore. I can't upgrade to the next big release or because I would have to change so many things. And I have totally lost control about what I had customizations over the past 10 years. Sometimes they, they just say, and then it's it's I think I understand that. Or they blame the vendor and say, oh, this is because of the product.

And, and, and after these discussions, sometimes quite lengthy discussions, we had a couple of the situations where we, where, where we said to the customer at the end, the best thing you can do is go to the next big release of the winter you already had, but sort of do a restart, reuse the parts. You can reuse your knowledge, your experience, maybe all the connectors, cause they might be pretty much the same.

And, and then build on maybe the standard processes that are delivered. That might be the fastest way forward sometimes. Yeah. Yeah. I completely agree. And something else, or we should have, should have in mind, as you brought up the point, sometimes non replacement of components, maybe just new version of the same, same product, maybe with another product. Another very important point is we should, wherever it is possible using standard protocols to integrate with applications out there where it's not possible, have an abstraction layer in between to be, to be flexible.

Because one thing which is really tough is if you have the proprietary interface, which is used by maybe hundreds of applications, the enterprise and the end, you have to change to something else. This is a pain. Yeah. And will take a lot of effort time. I have a good tip on, on how to under guarantee, get in trouble. That is program against the data model of the product. We have a hundred percent guarantee that you will get in trouble sooner or later. So last at least our, our, our last point. And then we do a little bit of Q and a. So enter your questions.

Now, I believe you also need to be pragmatic, pragmatic in the sense of having a program, but small projects, not overengineering, but understanding the bigger picture and solving problems, small stuff. And I think this goes back to the MVPs thing you brought up.

Yes, you can do MVPs if you know where this should end up. And if you know that from what you did first, you have a realistic chance to end up where you want to end up my, my take on that. Exactly. The MVP is the first step to the big picture. I completely agree. Completely agree, not putting too much risk, delivering fast value with your solution and, and, and also be able to adapt a little bit left, right? The very early, early stage. This is very, very valuable doing that MVP without having that big picture is the opposite thing likely running in the wrong direction.

You are not aware of that. Yeah. Okay. I think we, we spent quite a, quite a lot of time right now talking about some of our experiences I'd want to bring up a second poll and hopefully we get some, some questions from the audience. So as I've said, having more questions makes Q and a way more likely, but first let's do the second poll. And then we will look at the poll results and take questions if there are, there are any, so, so do you, the question to the audience, do you already have a comprehensive blueprinted architecture across all of IM in place?

So did you do this Crowdwork thing already? Simple answers yes or no. If the poll place, so the poll show up in a second, here we go. Okay. I give you another 10 seconds. The more answers, the better it is. Okay. Then I'll close the poll. So thank you you for, for participating in that Paul.

And so, as I've said, we, we had quite, quite a lot of discussion here. And right now let's move to the, to the Q and a part. So I don't have questions from the audience yet, or these comments. So maybe we get some, so then, then maybe let's first look at the, the, the first poll and let's present the, the results of that poll, which would be visible here.

And oops, they have lost it. Here we go.

And, and it's interesting because specifically first, first answer is an interesting one of the audience. No one said, our problem is the leg of budget. This is something I wouldn't have expected, honestly, while, and there's little leg of proper expectation management, but then more or less are very close to, to each other. There is two technology focused, insufficient stakeholder management, insufficient requirements gathering. I think Andre, when we look at these, this quite well verifies the points we erased, didn't it, doesn't it?

Yeah, I think so. I think we highlighted the importance of gathering the requirements. We talking a lot about the, the piece, cause it would be all aware of how, how important that's not just we, but also the whole audience, but, but I'm really, but it's, it's really exciting to see that it's not the lack of budget. And if I'm going through our, our pro project in my mind, typically it's not the challenge that, that you would've solved it better if there would be just more, more money, but, but it's really about having the clear picture, what would be achieved at the end of the day.

And that's when you started and yeah. So I can understand, I can understand that. That is way how audience challenge The way by the way.

Very, a really great question from the audience. One, I think everyone of us has experience that is how do you, do you deal? Or how do you broker stakeholders that have tried to, to, to solve I am challenges and projects, but have failed over and over and don't want to try again. So you you're saying this when the board member says, oh, we tried this three times or the, the, some owners said, oh, we tried to do that part of identity management role management project, for instance, a very common example. I don't want to do it anymore.

So what, what is your guidance on, on how to overcome these, these concerns at the end? Because it are concerns. And usually they are driven by, we spent a lot of money.

We are, we feel tourist, our careers and other factors. So what do we do here?

Yeah, I think in these cases, it's, it's of course important understanding why it's survey and what can be done better. And how is it clear that this time it will be successful? Yeah. Also I think we, we covered the aspects of small steps. Iterations. Yeah. So maybe no, no one is, is willing. Yeah.

To, to give front the budget for the, for the, for the whole project, but maybe it is possible to get budget for the first steps and, and showing, showing the results show that this way will lead to success this time. Yeah.

Anyhow, not easy, not easy task. It is not easy. I think the points you raise are, are correct. So pragmatic makes small steps, quick wins, big wins demonstrators. And the other part from my perspective is trust building. So at the end, they will need to trust you as the, the advisor that the, your experience.

And, and when I look at how many projects I see consult has done, or so, or, or years of experience people like you or SME have, I, I think that is the trust part. And also the, the openness at the end, in, in the communication saying, these are the risks, this is why you feel re things. And I think it's re rethinking is also very important. Not only do the standard stuff always, but also say, okay, then step back and think about how can we do it differently? Why did you fail?

And, and so analyzing this, this all together, I think makes it, makes it work, but it, it's not an easy job to do. That's definitely for sure. So maybe let's look at the, the results of the second poll, which was about a blueprint in place or not. So we see them right now and it's a pretty much Thai situation. And it's interesting. I raised the same question a while ago in a, in another webinar and it was more or less exact the same, the same response.

So some have some don't have, I just can say, and that's, if we can stop explaining them, I just can say, we, we, it is important to spend the time for planning. If you build a house, you have an architect. If you do identity management, you need the architects and so on the designers as well, otherwise you will fail.

So, so maybe entre before we stop for today, is there one, one recommendation you would want to give the, the audience before we end? Yeah. One recommendation.

Typically, typically our customers enterprise project spend a lot of time on finding the right vendor. So it's very, very important, but the right system integrate as important. So not underestimating the impact that the, that the people who are supporting the project have, because if someone is working with the technology, the first time it's likely to fail, we are talking about complex software here, complex tools about complex processes, these enterprises, and without experience in that area, it's, it's very hard to be successful in the first, first try. Yeah.

I, I, I couldn't agree more. And, and that is, for instance, when we guide organizations through the choice of tools, we, we always say premium the system integrator of choice early, because it's, you need the right tool you need is the right system integrator, and you need the right fit between the two of them.

We, we even had projects where, where they said, okay, I like this at the end. I like this tool, but I want to do, because the other system integrator who came in with another winter first, interestingly, that system integrator was you at the end of the day, that won on the project.

So, so, but, but it is something which is very important because also the system integrators thing also ask, what are the, who are the people we would need to build work with for the next years? Maybe. Cause if you don't can't work well with them, it's challenging.

So we got, got one more question here. And, and I think that is one we, we should pick for, with a short answer. It is a honestly a quite complex question. So what is the best argument convincing the top management about investing in a new modern identity management? Is it compliance?

Is it, is it minimizing risk? My take is for most organizations today, it is enabling the digital business because it's, everything is about entities. It's not just the workforce, it's the, the customers, consumers, the partners, devices, things, services, et cetera.

So, and, and giving seamless access for, for everyone seamless yet secure access from every, for everyone and everything to every service is challenging. And you need a good enough technology to do so. It does is what works for most organizations sometimes. And we have seen it in banks for the past 15 years. Sometimes regulators are creative driver auditors. If they don't work, then, then, then, then look at how can you enable the business to perform better by take you take?

Yeah, I can completely agree. It's, it's really enablement, which is typically the, the driver for, for the, for the top top management. So for example, maybe have a look to the other it initiatives. Yeah. Going into the cloud without a very powerful identity management in place.

It's very, very hard to achieve collaboration by providing digital services with, with other other enterprises or to provide, provide digital service, to integrate with, with, with digital assistance out there without identity management will spend a lot of efforts in, in, in making just one use case somehow with identity management place. It's an accelerator for a lot of these initiatives. And I think that's, that's, that's a, which should con convince the top letter management.

Okay, perfect. So thank you to the audience. Thank you very much to you entre. So we're part of saying thank you for just, I believe very interesting, insightful conversation. I hope you also perceived this that way. So thank you and hope to have you soon back at one of our call events. Thank you. Yeah. Thank you much, Martin was again, pleasure talking together with your opinions. Yeah. For participating goodbye.