Fight scope creep with this change request trick

Ken Hardin identifies one weapon in the never-ending battle with crazy IT project scopes.

Scope creep usually comes in second on a list of why IT projects fail, behind the dreaded IT/business alignment issues (which is a euphemism for senior management doesn't know what it's doing). You can take a swing at helping out on the alignment problem, but there are only so many reports you can send up the food chain to be ignored.

 

 

However, project managers are a company's front line against scope creep. It's a tenuous position, since no matter how locked down the business and functional requirements for a project may be, the scope is probably going to change a bit. It's seemingly unavoidable, as in this discussion.

Defining scope change

First off, my definition of scope change is an alternation in a project's requirements that creates modification in the effort, cost, or schedule of a project. So, "let's make that blue instead of red" is not a scope change request.

Some sites define scope change as simply a matter of cost and schedule, but I include effort in my personal lexicon because IT shops, particularly internal development, are often asked to squeeze several hours into a project without it making its way onto a costs analysis. This can impede not only your project but other ongoing projects as well, so some measurement and push back on changes in effort level must be evaluated -- even if it is not going to end up with a dollar sign beside it on a spreadsheet.

And some sites also define a scope change request as coming uniquely from the client. I like to think that good ideas can come from anywhere as a project advances, so if it comes from a coder, so be it. And (at least in my dream world), scope changes can actually save effort and money -- oddly enough, these suggestions tend to come from coders.

Remember, scope change only becomes the dreaded scope creep when it goes unchecked, and its impact is not logged and monitored. This happens in all environments, but I have found that it is most prevalent in smaller businesses or in Agile dev shops, where business managers are in much closer contact with the development team. It's just too easy to walk down the hall and say, "Hey, I just thought of three more fields for that data entry form. Can you add them for me?" Boom, scope creep.

Having spent most of my career in small and medium enterprises (SMEs) that were Agile even before Agile was cool, I have been both the source of and leaky dam against scope creep, and I can tell you it certainly can seem like a losing battle. But the same organizational flatness that creates the problem also supports the tactic I have developed to help combat it, at least to some degree.

Sharing my scope creep trick

The general wisdom for avoiding scope creep goes something like this:

1. Require the scope change requester to complete a form, or otherwise formally describe the change.
2. Log the form (like you do everything else).
3. Determine the impact of the requested change.
4. Review the change with the client / business owner / project team, and approve or reject the request.
5. Update project documents and notify the team of any changes.

My trick is to basically move step 3 up as a component of step 1, and include a short questionnaire about the impact of the suggested change right there on the initial request form. I also ask for the change to be mapped -- quantifiably, if possible -- to one of the key metrics / business goals laid out in the project's business requirements.

The business metric aspect of this approach is key, because this shifts at least some of the burden of justifying the change onto the business analyst (which might also be the project manager, based on the project's scale) or the business manager / client. It will still be up to the project manager / IT to determine the effort level required to make the change. Let me be clear -- this tactic is not necessarily going to eliminate a lot of work for the project manager, but at least this approach forces a client to evaluate the benefits of a change before they are able to formally request it. Once a change request gets in the log, it tends to get approved -- that's just the nature of all projects.

Mapping the change request to an established business goal for the project is perhaps the most import benefit here. I have worked on simple projects that have bloated into what really should have been three separate initiatives, just because another manager heard that some changes were coming in the user database and they wanted a piece of that action. Nobody stopped to say, "That's really not what we are doing here."

So, that is one weapon in the never-ending battle with crazy scopes. Next time, I will discuss why project managers must form close alliances with business analysts to make sure initial scopes / requirements don't get crazy all on their own, even before creep can set in.