“You’ve got to be very careful if you don’t know where you’re going, because you might not get there.” – Yogi Berra

I doubt that Yogi Berra knows much about Identity Management, but his advice is appropriate. I believe that careful requirements definition may be the single most important thing we can do to implement Identity Management systems that really deliver value.

Poorly defined requirements may yield:

1. A system that doesn’t meet your business objectives. A colleague of mine calls Identity projects that don’t deliver real business value “Science Projects.” If business requirements are not carefully defined and if the technical design is not linked to each business requirement, the Identity Management system may have been fun to build, but won’t be worth much to the enterprise. And you probably won’t get the chance to deliver Phase 2.
2. Difficult technical challenges. Too often, requirements are defined beyond the scope of what can economically be delivered. For example, if you allow access control requirements to be included in the scope of a provisioning project, without using an access control product, extensive custom development may be required to force the proverbial square peg into a round hole.
3. Schedule and budget expansion. If careful requirements definition is delayed, the implementation team may find themselves sitting on their hands while requirements and design are debated. This inefficiency usually results in busted budgets and painful delays.
4. Poor stakeholder satisfaction. If the system doesn’t meet stakeholder requirements and expectations, stakeholders will be disappointed (or worse). Understanding and documenting requirements of each stakeholder early in the process is the best defense against such dissatisfaction.

The recommended approach?

1. Demand a formal requirements definition process. As a high school math teacher, my Dad used to say, “If you don’t have time to do it right the first time, when will you every have time to do it again?” Requirements definition is like that. Many resist the time and effort to define requirements right the first time – either skipping the exercise or failing to drive to the level of detail that is necessary. We must have the professional discipline to demand formality in this process, knowing that the investment up front will pay off handsomely as the project proceeds.
2. Define requirements from your selected Identity Management product point of view, not from a custom point of view. This is a subtle, but important distinction. If you have spent a lot time, energy and budget on selecting an Identity Management product to deploy, make a concerted effort to leverage the strengths (and ideosyncracies) of that product. Defining requirements outside the framework of the product that may be difficult and expensive to implement and support. If you choose to frame your requirements within the scope of what the product can offer, you will deliver value more quickly and end up with a system that is much simpler to support.
3. Conduct formal requirements acceptance. Each Identity Management project has many stakeholders with a vested interest in the successful outcome of the project. The requirements that affect each area of interest should be formally accepted by an authorized representive of that area. Either do it early or do it later. Later is always more expensive.

One of the most famous quotations attributed to Yogi Berra is, “It ain’t over till it’s over.” Through good requirements definition, we will define success – so we can know when a project is over. That may be the best reason for defining requirements, after all.

Technorati Tags: Identity,
Digital Identity,
Identity Management,
Project Management