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 TechRepublic members relate (with some dour humor) in this discussion thread.

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

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.

Also read on TechRepublic