Why IAM Projects fail?
Failure can be a strong word and one that can often send people to see to a psychiatrist in a flood of tears. In a professional context, we like to refer to it as a “something we learn from”. If that is the case why do most IAM Projects fail to meet their original goals, despite vendors, consultants, implementation providers and organisations all having lots of “learning experiences” over the decades that IAM has been around.
Like a psychiatrist we will examine the issues and see if there is a common underlying problem and one that can at least explain away most of the problems. Tissues ready, this could get emotional.
Exec Sponsorship
An old favourite this one and often trumpeted by consultants and vendors. The claim is that without buy-ins or commitments from executives (CISOs, CTOs or IT Directors) IAM projects are doomed for failure. Whilst its certainly true that some IAM projects are scrapped or scaled back because of project overruns or being too expensive before you start, generally this over playing the importance of IAM.
Before you stop reading (or storm out of the therapy room) let’s explain that statement. Executives are typically focused on bigger goals such as Zero Trust, Cloud Migration, IT Cost reduction, Regulatory Compliance, Improved Cyber Security etc. Notice how none of these explicitly mention IAM. Yes, IAM plays a fundamental part in all of these, but execs are going to be concerned about the success of the overall program and not necessarily the individual success of your implementation of the IGA tool to improve the JML (Joiners Movers Leavers Process).
The only exception to this has been Privilege Access Management (PAM) in the past. From about 2015 to 2020 PAM was always high up on the list of CISOs projects. This was mainly fuelled by the Insider Threat scare particularly around the time of Edward Snowden.
So why the fuss on exec sponsorship. This is a common sales technique amongst nearly all of the numerous sales processes. For example, MEDDICC (or MEDDPICC). The E stands for Economic Buyer and the C for Champion. Making a sale is much easier if one of those is the exec sponsor. Therefore, marketing and sales departments are trying to raise the profile of IAM projects.
Leaving the vendors bias aside, exec buy in is important. Without that projects are liable to be cancelled when other initiatives are brought in or when, and most likely, money for projects is squeezed.
Program Goals
IAM projects are often deemed a failure because they haven’t met the original aims of the project. There are simply two reasons for this. Its either the aims of the project were unrealistic, or the implementation did not meet the meet the original goals.
Program goals are often unrealistic when little consideration is given to the capability of the technology. The desire of the vendors to make a sale (as with anything in the commercial world we live in) will often mean they will downplay the complexity to meet a particular piece of functionality. This is not to say they will lie, far from it, but the solution can often be unwieldy. That solution then becomes the proverbial pain the backside to install and manage and will likely cause issues elsewhere.
The advice is to make sure that all requirements are easily implementable. If they are not, investigate whether the amount of customisation required is suitable and appropriate for the requirement. Decide if the requirements are mandatory or just nice to have.
As in life, sometimes we can’t get everything we want.
Delivery Timescales
Obviously, it is easy to blame the delivery of the project when it is not successful. However, that just builds up resentment between organisations, technology vendor and service suppliers with many a finger being pointed at each other. It goes without saying this never helps.
There are numerous quotes about planning but a good one from the US Army is “Prior Planning Prevents Piss Poor Performance”. Planning is obviously the key and therefore temptation must be avoided to dive straight in. There is always pressure to deliver something quickly or at least show return of value or return of investment as soon as. This is undeniable but meeting that milestone date will be acceptable to everyone even if it is a few weeks later than everyone desires.
In other words, the solution is to take time to plan and stick to it.
Technology
The technology provided by the vendors typically are incredibly powerful and flexible especially since in recent times with more and more vendors offering consolidated platforms.
That functionality can be alluring and generate a feeling of lust and desire to have all of those wonderful features.
Therefore, the temptation is to do too much, change the requirements slightly to make use of a feature. As soon as that temptation is succumbed to, things will start to unravel.
The advice is to save the eye-catching stuff until later in the project.
Often though it’s not the latest widget that causes the problem, it could be that the chosen technology was simply wrong to start with. The marketing and sales pitches from vendors are very professional, but they are biased to their needs not yours. They want your business and continued business, and let’s be honest it’s all about money. It’s a blunt truth, but one that has to be acknowledged. They are unlikely to say no they can’t do something and will show how much better than they are compared to the competitors.
Therefore, great care must be taken. The advice is to determine your requirements in as much detail as possible and choose based off those requirements. It may be time consuming but look around the market and speak to as many as possible. There are many, many vendors in IAM (more than car manufacturers) but choose a healthy amount to get a good cross section.
Psychotherapist speak here, stay strong and don’t be swayed and choose what is best for your requirements.
Costs
Entirely obvious this one, any business has a limit to amount they will spend on a project. There is no guarantee that even once a budget has been approved, businesses do change. That is outside the control of the project, and to a point not much can be done about it.
However, the project personnel do have some control over costs.
One of the main issues is the reliance on external parties to implement a solution. A traditional IAM solution was always considerably expensive to install and configure with a rough ratio of five to one for services compared to licenses costs. The rise of Software as a Service (SaaS) has greatly reduced that ratio.
There is always a danger that the amount of services required has been under-estimated by a potential services provider. That is always a danger and can be easily judged by getting several quotes. Any outliers should be ignored or at least certainly looked at very closely.
Assuming there is a consensus of the time required, the most likely cause of any overrun thereafter will be changing of requirements. That can be avoided with sufficient planning and preparation before implementation begins.
One other common complaint, and especially from consultants is a lack of support given by a customer. Slow responses and slow support can reduce the efficiency of the consultants doing the implementation.
A final to consider is the running costs of a project. Even with the considerable energy costs blighting modern society, the bulk of costs will be internal staff to maintain the solution. Automation and an effective architecture should reduce the manual processes and therefore the amount of staff.
Consideration has to be given to running costs early in the project as these then can be carried into any requirements and design work.
User Experience
Even if project staff and execs are happy with the project, what ultimately decides the success of any project is user adoption. For something like IAM user adoption is forced upon users (consider Single Sign On) force it onto users but the amount of support calls will give a good indication as to how any change is received. (A little caution should be given to this though as people tend to not like change!!)
Ultimately most users are lazy and look for the path of least resistance, so any changes should look to improve the user experience. Security changes such as MFA, may not be liked (users may not like to take an extra ten seconds to provide an additional form of authentication). Time should be taken in advance to explain why.
The biggest reason for the failure as far as considering users is that the solution does not cover enough users. A project has to consider many different user personas who have require experiences or different needs. Many a project only considers a limited number of user personas and then fails to handle all of the different use cases. For example an assumption is always made that all of an organisation’s users will exist in the HR system. Not always true, especially if you consider third party suppliers, temporary workers or even gig workers. Another example is with MFA, an assumption is that every user will have a mobile phone to authenticate themselves. For many a reason that may not be true.
With the latter example of not being able to use MFA, imagine the consequence if a large percentage of users who have to revert back to just using a password and ultimately one of them is exposed during a cyberattack.
In the modern world of inclusion and considering the needs of every user is vitally important and should be built-in to the project during the planning stages. Don’t leave it during the implementation phase as retro fit could be an expensive business and then the failure will fall into one of the previous categories.
Ultimately the voice of the user base will decide if what has been delivered has been a success.
The Diagnosis and Recommendations
If any one of these issues has caused an emotional outburst, relax keep calm and rest assured you are not alone. Remedial therapy for any existing mistakes my take a few sessions with a skilled expert but it is take a few steps for avoid such errors in the future.
The recommendation is quite simple, all these areas need to be considered to guarantee a successful IAM program. This may seem like a lot of check boxes that need to be ticket, however the time taken to do these as part of planning and implementation will result in considerable savings in time and more importantly money.
The biggest piece of advice is that prevention is better than cure. Most failures can be avoided by spending time at the start of the project preparing requirements, finding the right technology, and planning the implementation. Sticking to those requirements and avoiding temptations to perform unnecessary changes will result in little or no cost overruns. That will always keep the executives and accountants happy.
Delivering a successful project will give a good user experience and a high chance of adoption. In the end everyone is happy.
Disclaimer
Forgive the imperfections as the only artificial intelligence used in this blog was to spell check.
