Way back in January, I began blogging about “Seven Identity Management Implementation Risks.” Alas, I addressed only five of the Risks before being distracted otherwise. Perhaps that is one of the Risks of reading my blog – coping with my fits and starts.
But here it is – sixth in a series – Scope Creep.
Yesterday, I conducted what we in Sun call a Post Project Review, a conference call to assess went right or what went wrong with a project. It is a valuable exercise focused on progressively improving our ability to implement Identity Mangement systems. This was a successful implementation project. The system went live last week; our customer is happy; the project met its objectives. But when I asked the team, “What surprised you most on this project?” the first response was, “The number of additional requirements that were added to the project.”
Our customer had hired a skilled analyst from a major consulting firm to write the requirements document. They thought they were prepared. But when the project started and we began to review those requirements in depth and prepare a system design, it became apparent that many requirements had been missed or were poorly defined. Oops! So, right up front, early in the project, many more requirements had to be defined and others clarified. A major change order had to be processed, almost before the project commenced.
Scope Creep can be deadly to a project. If our team had not been extremely disciplined in executing a change management process, the project would have been doomed to failure even before it began.
What are the effects to of Scope Creep? It will:
- Extend your project schedule. Your project will take longer, not only because of the extra direct effort to provide additional functionality, but because the project will stall while new requirements are being defined.
- Increase your project cost. More time = more cost. If not carefully controlled, all the new “minor” scope changes can add up to a “major” budget hit.
- Delay perceived system value. Stakeholders expect and deserve business value from an Identity system quickly. Any unexpected scope additions can delay the realization of the valuestakeholders were promised. This can undermine confidence in the system even before it is delivered.
So, what should be done? I recommend the following:
- Define requirements well. The first Identity Risk is Poor Requirements Definition. Do yourself a big favor and carefully define requirements up front. Then double- and triple-check your work. Make sure that you really understand and have documented what you want to have delivered.
- Push back on all changes. Every project that I have experienced has had changes. The trick is to make sure that they don’t just “creep” in. Challenge every suggested change, not to be obstinate, but to make sure that each change is justified. We need to be intellectually honest about what the project impact (both positive and negative) will be.
- Enforce a change management process. The change process must be be formal, not just a gentlemen’s agreement among buddies. This will force a process of examining each proposed change to determine why it is necessary and what schedule/budget impacts will be felt. This holds true for both fixed-price and time-and-materials projects. Some people falsely believe they can be more lax in managing changes on a T&M project. But budgets are budgets, schedules are schedules, expectations are expectations, regardless of the financial model. Change management is always needed.
- Your customer must formally accept all changes. It is not enough for an implementation team to record changes and hope that the project stakeholders understand. Force the issue by having the stakeholders formally approve changes. In the project I referenced above, fifteen different stakeholders had to approve the design document that reflected the many added requirements that emerged at the beginning of the project. This not only made it easier to secure financial approval for the corresponding change order for these additions, it really smoothed the way for an additional change order later in the project to cover requirements addtions that emerged at User Acceptance Test time.
- Document everything. The change order process should cover this, but the principle is that unless a change is documented, it may kill your budget and schedule without you knowing what hit you. Project members do change over time. Even though you think you have a great memory, that too will fade over time. Documenting all changes provides that consistent, thorough record of how changes affect your project over time.
I shared an example of a project that was successful because scope creep was meticulously managed. I have also experienced the horror of projects where scope creep literally consumed the effort and led to failure. The first example is a whole lot more fun.
Technorati Tags: Identity,
Digital Identity,
Identity Management,
Identity Risks,
Project Management
I recently met Rakesh Radhakrishnan, a Senior Client Solutions Architect for Sun Microsystems’ Telecommunications vertical. He directed me to his blog, Identity Centric Architecture, where he has posted links to a series of nine papers he co-authored from March 2004 through May 2006 on the topic of Identity Enabled Networks. These papers focus on one central theme – that leveraging Identity Services as reusable/replaceable Architectural Building Blocks is essential to enabling Service Oriented Architectures in a broad array of communications industry applications. Good stuff!
Bob Horn is the Director of US Sales for the newly formed Sun Microsystems Software Practice, which spans the entire Sun software stack. I blogged about Bob 
I finally got the monkey off my back and finished the 