Mike Wyatt's Weblog

Project Managers as a Critical Success Factor or Identity Management Projects

My team and I have lived through projects that have run the gamut from extremely successful to unsuccessful. It is interesting that when companies purchase enterprise software and Identity Management solutions in particular, there is incredible focus placed on the ability to meet certain use cases, usually thought up when the Request for Proposal was written. In addition, there is great emphasis placed on "feature function" comparisons between the various finalist product offerings.Though there is usually some attention paid to the implementation approach and the governance model for the project, it is almost always a secondary to the question of product capabilities.

In addition, when a vendor provides an estimate of the level of effort to complete a project, either in terms of hours or dollars, customers do not like the initial proposal. "This is WAY too HIGH! Your competition is 1/2 the amount of your bid." Usually one of the first items to come under attach is the vendor's project manager. I cannot tell you the number of times I've heard the buyer for the customer say, "We have experienced project managers and we will manage our own project."

Unfortunately, in order to "get the deal done" vendors will make this concession. More often than not, when a project gets in trouble, the common issue is not technology (the bits) or even the vendor's technical team. It is usually the lack of strong project management, especially when customers are providing the project manager. Identity Management projects are complex and often political. The systems that an IDM solution touch, especially in the case of provisioning, often cut across functional boundaries, creating an interesting tension within the customer environment. Add to that the need to change to expectations of the customer stake holders regarding the inevitable limitations and nuances of the solution and you get tough situations needing strong project managers.

I'm not saying the customer should not have a project manager on the project; they should but that does not obviate the need for the vendor to also have a strong project manager. Where it works best are when the two project managers hold each other accountable. Without a vendor PM, when issues arise, the vendor's project or implementation team will always take the brunt of the criticism. It is simply human nature; customer project managers will be biased toward their company's point of view. Without a vendor PM, the project can go off track without the vendor having visibility, the implementation team may be tasked with unauthorized change requests, deliverables such as documentation and milestone signoff may lag, the implementation team may get pulled into meetings that negatively impact completion of deliverables, etc.

What about having the vendor's technical lead act as the PM? I've seen this approach fail more often than not. The lead architect needs to have a good relationship with the customer. Often times, if the customer asks if the product can do X, the technical will agree and move toward implementing X even if out of scope. It is not their core competency and I've seen a clear division of labor much more effective (though I've certainly seen consultants and architects that are fantastic project managers too!). At best you have great technical talent time slicing between technical implementation and project management, introducing overhead (and often stress) to the project team.

The best approach is to find the funding to cover the vendor project manager as part of the project and peer them with the customer project manager.

Posted at 07:15AM Dec 18, 2006 by Michael Wyatt in Identity Management  |