December 14, 2006 - Scope Creep Part 6

Theoretically, if you are tracking your scope while comparing the project direction against the defining documents it should be obvious when something changes. That isn’t always the case.

Identifying Changes. Sometimes it is easy. The Business or Sponsor stops you in the hallway and says, “I think this is a change to the scope, but can we do….” Other times it hinges on a miscommunication caused by ambiguous wording. So how do you know when a change happens? To help us identify change, we will look at 6 types of changes: Initiated, Stuff Happened, See I Told You, Missed That, Miscalculated and Not What We Agreed.

Initiated Changes are the simple ones. The end user comes to the status meeting and says they have a new requirement. Everyone knows it is a change and we move on.

Stuff Happened Changes pop up when something unforeseen knocks you off schedule. Depending on the type of relationship, the “stuff” might be seen as a candidate for change or not. A natural disaster might be written into a construction contract but probably not into an IT agreement. A power outage takes down the system during implementation delaying it by a day. Whose responsibility is it? Who eats the cost? Can the date be moved? Once you establish that something changed you can begin to get answers to those questions.

See I Told You Changes are when Risks become Issues. If you missed the discussion on Risks you may want to jump back in time (November 14, 2006) and catch up. Even though you work hard to identify and mitigate risks, sometimes they become issues and a change request is required to deal with them.

Missed That Changes involve requirements that didn’t make it onto the books. One project I was managing hit a snag just before implementation. There were pre-existing data problems that were not considered during the analysis phase. As a result several work around solutions were needed to make the system function properly.

Miscalculated Changes are those budget problems where either the funding or the timeframe was grossly under estimated. Before quickly issuing a change request to fix the problem perform a thorough analysis and get it right the second time. This helps you avoid having to go back to management multiple times. Sometimes you end up eating the extra cost, especially if it was a fixed bid project.

Not What We Agreed Changes are probably the trickiest to deal with. When one party doesn’t fulfill their end of the bargain it is sometimes called a “non-compliance” change. If in the Statement of Work there was an agreement that the system would be available for testing on a given week and it is not functioning, a change request should be issued to reset the test date and potentially fund the additional time the team sat idol.

Hopefully these examples will help you identify potential changes on your project.