Why Do IDM Projects Fail?

Recently we were asked to list the top pitfalls we at IDMWORKS have encountered in our experience over the last 10+ years as to what makes a project fail.   This list is NOT specific to Identity Management but IS specific to ALL projects.

1. Lack of Requirements – This is the number one reason we have seen for failed projects over the years.  If requirements are not agreed upon by the business and the technical teams, and signed off on, then the project will not produce what the customer wants.  First stage should be requirements, both operational (business) and systems requirements.  Additionally these requirements should become the test plan. 

2. Badly Written Requirements – A requirement MUST follow a protocol that requires:

a. Statement of Problem to be Corrected (Operational Requirement)

b. Method(s) to Correct (System Requirement(s)

c. Testable Operational Requirement (one per) to System Requirement(s)(one to many) – if it cannot be tested then it IS NOT a requirement

3. Poor Timeliness for Sign-Off – Each Phase and Associated Milestone or Deliverable needs to be reviewed and signed-off in a reasonable timeframe.  Project delays and thus budget creep occur when sign-off lags. 

4. Purchasing of Technology before Defining Requirements (or placing the cart before the horse) – Buying Tech first leads to Shelf-ware.  Buying tech post requirements definition leads to a fast implementation of said technology. 

5. Lack of Due Diligence – Correctly written and signed off on requirements can be used to create an RFP, a POC or a Demo Requirement that can be used to validate whether the technology the customer wished to procure can, in fact, fulfill the requirement. 

6. Lack of Operational Experience – Post implementation, if the customer cannot support the implementation due to lack of man-power or lack of training, the successful project can end up being the failed implementation.  There are many approaches to bolstering the operational side including: 

a. Documentation

b. Mentoring/Shadowing

c. Training

d. Recording Implementation Sessions

e. Utilizing Managed Services to Bolster Ops or for Tier 2/3 Support

7. Lack of Governance – If the organization utilizes an Access Control methodology such as Role Based, Attribute Based or Policy Based Access Control (RBAC, ABAC, PBAC) there is a requirement to allow for Governance meetings to keep Roles, Policies, etc. up to date.  If Governance is not planned for then the Roles, etc. become out of control typically within twelve months of implementation. 

8. Communication Deficiencies – This can be between Management and User Base, Project Management and Project Team, Engineering and Architecture, the Business and the Application Owners, etc.  If the communication of the costs, dates, timelines, deliverables, sign-off, etc. fails then so does your project. This includes participation in meetings, both teleconference and in-person.

9. Insufficient Change Control Process – In technology driven projects there needs to be a method to adjust to Change.  A Change Request process should be used to adjust dates and resources that are requested by the business, the technical team and customer in general with the understanding that there may be a cost impact and/or time impact. 

10. Scope Creep – See numbers 1 – 9 as to what causes scope creep.  Scope creep is acceptable as long as a change control process is in effect and change request mitigation.