Why IAM-Projects fail

7+1 reasons and more to expect

There are several caveats to be aware of up front when starting a major IAM project. These useful hints are driven by experience from projects that went wrong due to some common misconceptions:

1. Sub-optimal assignment of responsibilities

corporate organisation needs a Business Owner

Complexity factors

• Identity Management is a management task.
• Identity Management means organising the enterprise.
• HR could be the natural owner - but often refuses.
• IT has the implementation capabilities but is not mandated to change the organisation.
• On the business side methodological and technical knowledge is lacking.

Possible countermeasures

• Shift the responsibility to the business side.
• Create a new cross functional function (group) for the doing.

2. Cross-company character

IAM-Projects touch multiple corporate functions

Complexity factors

• Identity-Management Processes are typically cross-company.
• There are multiple stakeholders from different corporate levels involved in a project.
• You need to expect a 3 to 5 times higher communication complexity compared to "normal" IT-projects.
• IAM-Projects show characteristics of typical Change Management Processes.

Possible countermeasures

• Strengthen the project management.
• Add an extra reserve for communication.
• Insist on a power sponsor for your project.

3. Differing Process maturity

There are no islands of order in an ocean of chaos.

Complexity factors

• At higher levels of maturity of the management processes (e.g. according to CMMi) the introduction of IAM- processes, -rules, -roles, -policies becomes easier.
• You can't implement mature IAM-processes in a low maturity process environment.
• E.g. the top-down definition of roles needs defined processes.

Possible countermeasures

• Only launch IAM-projects corresponding to the maturity level of the environment.
• Occasionally just say "no"!

4. Wrong Project scope

An implementation project cannot reorganise the corporation.

Complexity factors

• Implementation project will have a hard job when having to reorganise the corporation first.
• Process- and Role-Definitions require their own definition projects before or in parallel to the Implementation.

Possible countermeasures

• Define separate projects for the Definition of Processes and Roles before or in parallel to the Implementation.

5. Adverse effects of the market consolidation

acquired components don't necessarily combine to Suites

Complexity factors

• Mergers & Acquisitions often lead to less compatible product collections.
• The software of acquired companies is often not supported sufficiently.
• It may take a long while, until components fit together as promised.

Possible countermeasures

• Only a Pilot installation under real world conditions leads to the necessary evidence for a product selection.

6. Non-availability of domain knowledge specialists

persons with business domain knowledge are rare creatures

Complexity factors

• The availability of specialists with domain knowledge often turns out to be the bottle neck in role- und process definitions.
• Their involvement is essential for the requirements definition and the QA.
• Waiting times (for specialists) are driving the overall effort.
• While in projects they tend to disappear.

Possible countermeasures

• Assign the project responsibility to the business departments.
• Think of splitting projects into business definition and an implementation part.

7. Too deep vertical integration

don't try to reinvent the wheel

Complexity factors

• Only a fraction of the overall IAM-Processes is really enterprise specific.
• The adoption of processes and / or Roles from generic Models may speed up projects.
• Not always it is a good idea to start with a blank sheet of paper.

Possible countermeasures

• Ask your integration partner or consultant for consolidated models containing his experience.
• Participate in Standardisation initiatives (like GenericIAM.org).

8. Technical risks - they still exist

Technology often is more of marketing than reality

Complexity factors

• IAM-SW-Suites are complex and often not easy to handle.
• Without implementation experience in exactly the required environment risk of failure is high.
• "Minor" changes of the version number sometimes cover oft complete new developments.
• The support Matrix of environment components vs. versions often is only sparsely populated.
• Forced replacement of infrastructure components leads to higher effort.

Possible countermeasures

• Always test selected software in a pilot run before deployment.
• Only choose integration partners with true product experience.