“Chance favors the prepared mind.” – Louis Pasteur

My post on Identity Management Implementation Risks seems to have struck a chord with a few people.

Shekhar Jha asked for specific real-world examples. James McGovern posted a comment on Ash’s blog that he wished that I had videotaped the presentation for people to watch. Michael thought the term “resource” was de-humanizing. In yesterday’s Identity Management Newsletter, Dave Kearns wrote about my list of deadly risks. (This specific newsletter will show up on the Network World website in a few days; it always lags the email version.)

It is heartening to see people realize that Identity Management is more than just technology. These projects touch a lot of systems, require business transformation and impact a broad range of stakeholders. But aren’t Identity projects just like other IT projects?

Consider this equation:

Identity Management Business Complexity
(cross-functional business impact, many stakeholders, high visibility)
+ Identity Management System Complexity
(many integration touch points, many moving parts)
= Identity Management Project Complexity

Proper planning is an important key to managing the inherit complexity of Identity Management projects.

So, let’s consider the first risk – Poor Pre-Project Preparation (how’s that for alliteration?)

Lack of preparation for an Identity Management project can:

1. Set false expectations in the mind of stakeholders. Lack of good communications early in the cycle will have many people expecting more than can be achieved in a short time.
2. Force the implementation team to spin their wheels when they should be doing work. If the project is not well planned, key decisions will still need to be made, even if they disrupt the orderly flow of implementation work.
3. Cause implementation engineers to define business requirements. This hurts. Identity projects must deliver business value in order to be effective. But if business and technical requirements are not well documented and understood, and if the design is not linked tightly to those requirements, the folks on the front line with fingers on the keyboards, may be force to make bad assumptions or wait around until correct requirements definitions are provided.
4. Result in additional time and expense. The inefficiencies described above will be revealed in terms of over-budget and delayed schedule. Note that these budget busters are usually not technical issues, but business and planning issues.
5. Undermine confidence in the project. Business units need to see business value quickly. Delays and increased costs due to poor planning will drain away confidence and support

So, what should be done? Here are some key areas where plannning must occur:

1. Project sponsorship, governance and organization. Who is really the project champion? Who really holds the purse strings? How can we assemble and work with the right set of stakeholders that will help this project succeed? How can we organize and marshall available resources to assure success?
2. Requirements (Identity Management software + infrastructure). We must really know what defines success for our project. Too often, requirements are ill defined or poorly documented. Time spend carefully defining requirements, not just for software functionality but for the hardware and networking infrastructure in which it is to operate, will be paid back many times over.
3. Extended project resources. A technical project team is often inclined to think of itself as the center of the universe. However, the success of an Identity project depends on many people beyond the technical team: systems administrators, data owners, subject matter experts, testers, system users, trainers, business unit representatives.
4. Communications. Because of the so many people, in many roles in an enterprise are involved with Identity Management projects, it is vital that a strong communications plan be implemented up front. People need to know what is going on. Much has to be decided and approved. We must be prepared to communicate and communicate well.
5. Change Control. Despite our best efforts to define requirements and plan projects, things will change. Modifications will need to be negotiated, documented and managed. Planning for and agreeing upon a change control process up front will smooth this bumpy road.

An example? Let me give a glimpse of two. I know a project manager who spends half time on each of two identity projects. In the first, before he took over, all these rules of preparation were violated – fuzzy requirements, weak governance, shoddy change control, poor communications. We are still patching things up after 14 months.

The second? We arm-wrestled the customer into funding a requirements/architecture project up front so we both knew what was to be delivered. A change control process was defined and agreed to in the Statement of Work. The deliverables from extended project participants were defined in advance. Now, does the project have its hiccups? Yes. But it is under control. It will be a success. Planning really pays off.

Tags: Identity
Digital Identity
Identity Management
Project Management