Why IAM Projects Fail? Part II

I woke this morning and received an email from SailPoint. It is the leader in identity governance (IGA) market as named by Gartner for Q2, 2016.

By the way, the underlying engine of SailPoint is Waveset from Sun Microsystems. My team is still supporting a customer not yet migrated out from Waveset. We have a long history implementing products from Sun Microsystems.

I'm fairly surprised Dell One Identity solutions are in the Leaders quadrant. It's not picking traction in this Asia South region. My team is trained in this product as well. Still waiting for deal-on. Ha!


But then, so what if a product is in the top quadrant? Will it warrant implementation success?

I said before and I am repeating now:

In the market, there is really not much difference between the various IDM/IDG products. I can safely say their features are almost 85-90% similar. It's the implementors & customers' key stakeholders ("People") that makes the difference between a successful and failure IAM project.


The magic quadrant is usually used by top-decision makers to cover their backside. Simply put.


I talked about the Pain Points previously. 

Again (coincidentally?), the biggest pain is People. 

• No ownership/main-driver (no full-time PM) 
• Not trained
• Not really know what they really need (Keep changing requirement) 
• Not enough support from application teams 
• No well thought-of test plans & not following test plans

If I may, I would like to add on 2 points which I recently observed.

• Design Documents were signed-off with no intention of following through (this is happening especially frequent in this region & usually causes huge delay)
• Test plans were not vetted and tests were carried out without support from internal team

These were caused by poor leadership. When a system is not well tested, especially the edge cases, things will break during operational time. And it's common. To blame the product, the implementers and the testers is easy. But do remember, when you point a finger at others, at least 3 other fingers are pointing back to yourself.


On point 2 - "Not trained", this could also mean the implementor is not well-trained as well. Oh really? Yes, it does happen. And it happened to us recently!

But being a responsible implementer, do we want it to happen? No. And do we want to redeem ourselves if given a chance? Definitely.

I still remember many years back when I was tasked by Sun Microsystems to debug a Sun Access Manager (the grandfather of OpenAM btw) issue for a teleco in Vietnam. I was given 22 days. In the end, it took me 4 long months! I was new to Sun Access Manager then. I was exploring. I'm not stupid by the way. When you are new to a product, you need time and patient.

Most importantly, my customer believed in me. He did not doubt me. He did not complain to Sun Microsystems behind my back. I felt bad at the delay but he was understanding. With help from support & product team, the issue was finally resolved. Usually, that's what the support & product team requires, an eye onsite to provide accurate feedback to them.


I keep repeating this story to my team these days, especially now when the morale is low.

In computing, there is no such thing called "not-fixable". Any bug can be fixed, it's just a matter of time. But of course, customers need to give you chance.

Otherwise,

To my team-mates: I handpicked you and I trained you, so I believe in you.


.