In the intricate realm of Identity Governance and Administration (IGA), the path from selection to implementation can be a transformative journey – but not without its pitfalls. Drawing from our collective experience working with multiple IGA vendors, this blog post sheds light on the challenges organizations often stumble upon during the IGA selection and implementation process. By discussing the missteps and providing insights into effective strategies, we aim to guide you on a smoother path towards successful IGA integration.
I have seen a lot of IGA projects that were completely driven by IT. Most of them did not really work out well. IGA solutions are business platforms. They are built to give the business control over their identities and permissions. If the Business in not incorporated in the project, there will be many roadblocks that will be difficult to pass. It already starts with defining your business requirements. Without proper input from the business, you will fail to match the technical requirements of the platform with the real business needs of your company and the processes that you implement might not match with how the business wants to work or they might be based on processes that were used in the past but could have been improved.
Another issue that we often saw in these projects is the acceptance from the business. People are reluctant to changes and if there is no one from the business to enforce these changes it can be very difficult to change the way people work within an organization. This only becomes worse if the solution doesn’t match their needs because the business was not implied in the implementation.
There were a lot of companies were we only started talking to the prospect after they had already spent a lot of time and money into analysis with external companies. In many of these cases all this analysis was based on manual data collection which is a very cumbersome task and will never result in accurate and up to date information.
Business processes and role models were often designed based on old data and were not matched to any product at all. It is important to gather the right business requirements, but every platform has a different way on how to handle them. So don’t waste too much time on defining how you want things to be implemented before you choose a platform. Choose the platform first and then spend time on working out how you can solve your business problems in the most effective way within the platform you chose.
In every IGA project the first step is to connect your target systems to provide visibility into your identities and their permissions. This will automatically provide you with accurate and up to date information which is way more valuable to build out your processes and role models. Businesses are living organizations that change over time and so will your IGA platform.
Big bang projects in IGA always fail. I have never seen a project work well when the scope was too big. When speaking to prospects at identity events we often heard things like ” We chose an IGA platform a few years ago and it took us years to go live with it. And when we finally managed to go live with our solution, our business requirements had already changed so nobody wanted to adopt the solution.”
When you make sure that you choose a mature platform that can support your business needs on the longer term it isn’t necessary to plan and scope a full IGA project from the start. Your business will change and so will your business requirements and business processes. Start with the basics and simply connect the Identity sources and the most critical target systems first. Fix the joiner and leaver process first when you want to get the identity lifecycle process under control. This should be straightforward. Look at the mover process later.
Do a lot of small go-lives and make sure you get business value out of all of them. This will result in happy customers (your employees) because their live becomes easier and happy management because they will be able to reach the goals they had set up.
I remember a project we once won were I said to the implementation partner that I was happy that I was not the one who had to implement the project. We received an RFP from a prospect where they described how they were unhappy with their current platform and were looking for a new solution. Their current platform became an unmanageable monster because of all the customization they did. They wanted a new solution, preferable a cloud solution and they wanted to go with out-of-the-box functionality to make sure that they would not end up with a new monster again.
That all sounded great. Until I started going through all the questions in the RFP. I even remember a question that specifically stated that the new platform should be able to provide the exact same functionality as the current platform, but it should all be out of the box. If that solution would exist, it would have been built by that prospect and not by anyone else because every organization is different. No organization would have the exact same requirements.
Eventually we made it to the last round of the selection where we had to provide a demo that showed them how we could solve specific use cases around the business requirements they had. I configured a demo environment to solve their business requirements based on the best practices of that platform and without any customization. I ran them through every business case and asked them if this solved their problem and for all of them, they said yes. So, in the end we won the deal.
This is where the “fun” began. When they started worked together with the partner to implement the solution, they were no longer looking to just solve their business problems. They wanted to solve them in the exact way that they had solved them in their current platform which was completely customized. Some of these processes were implemented in a certain way because that was the only way technically possible. It was not efficient at all but there was no other choice years ago. These business problems could be solved in a way more efficient way with out-of-the-box capabilities in the new platform, but they did not want that anymore.
Choose a platform and go with it, not against it. You look for a platform to fix your business problems. Let people that know the platform explain you how you can do it the most efficient way instead of sticking to other ways for the wrong reasons.
This is one of the biggest issues I have seen in this market. Everyone seems to love building enormous spreadsheets full of technical requirements. Analysts and “advisory partners” only make this worse. I have not seen any prospect or customer that has send out a list where they would use all the features that they are asking for in the first 2 to 3 years of using an IGA platform.
Nobody needs a Roll Royce to go and get groceries at the local store next door. And you don’t need to buy a big family car today if you don’t want to get kids in the next 10 years. Look at what you need today and make sure that you choose a platform that is mature enough and can grow with you. Those IGA vendors will not disappear tomorrow, and their platform will have to evolve to stay in the market anyway.
The other part of the issue here is that nobody cares to ask how the feature works and if it can match your business requirement. It would not be the first project were they asked in the RFP if the platform could generate a unique identifier and then complain that the solution is not capable of fetching an ID out of a Legacy platform and make some crazy modifications on it to match their specific way of creating an UID.
So instead of focusing on technical features, challenge the vendor to show you how they solve the important business problems and be very specific on those. Don’t just let them show you a demo of how it will look for they business. Let them show what it takes to get there. Don’t question the basic technical features too much as they can all handle those. And don’t forget to focus on what you really need today and not within a couple of years.
At Rapidvalue, we’ve witnessed the synergy between effective IGA solutions and strategic business alignment. Our approach emphasizes collaborative scoping, technology adaptability, and strategic calibration, ensuring that your IGA journey is not only technically successful but also aligned with your organization’s core objectives.
Conclusion:
The IGA landscape is a delicate dance between technological prowess and strategic alignment. By highlighting the missteps that organizations often encounter, we hope to pave a smoother path for your IGA journey. Our experiences have taught us that the essence of IGA lies not only in technological capability but also in its harmony with business goals.
As you embark on your IGA journey, remember that recognizing the mistakes is as valuable as understanding the solutions, leading you towards an IGA integration that truly transforms your organization.
#Rapidvalue #IdentityGovernance #IGA #Cybersecurity #LessonsLearned #BusinessAlignment #IGAImplementation #TechnologyIntegration
Contact us today to embark on a journey towards robust identity governance and administration.