Many software development teams follow a requirements change management process whose main goal is
to prevent what is known as "feature creep" or "scope creep". The goal is to prevent new requirements being added to the
project, or existing requirements expanded upon. This effectively
is a change prevention process, not a change management process, which
results in your business stakeholders getting what they specified but
not what they actually need.
There are two reasons, often co-related, why IT organizations choose to work
The impact of this approach falls into two categories:
agile approach to change management where you
change instead of trying to prevent it. With this approach you treat
requirements as a prioritized stack: each development iteration/cycle (typically
2-4 weeks in length) you pull the number of requirements off the top of the
stack that you can implement during that period. The rest of the stack is
allowed to vary, with requirements being added, removed, or reworked as
Figure 1. An agile approach to requirements
Business risk is minimized because they can fund the team for as long as
they like. Want to invest $1 million on the initiative and do so in ten
months? Then organize it into 10, 4-week iterations where you spend
$100,000 each iteration (ok, it's not quite that easy, but you get the idea).
The risk is that you might not get everything that you want, but at least you'll
get the most important features implemented for your investment.
Furthermore, you can always choose to spend more or less money as appropriate.
The risk to the IT department is also minimized: the business is now in control
over what gets built, for how much, and for how long.
The primary drawback to this approach is that it requires
stakeholders to be actively involved with the team. To be fair,
regardless of your approach to development if your stakeholders aren't actively
involved then your effort is in serious jeopardy, but with this approach you're
unable to hide this problem for long.