The "Change Prevention Process" Anti-Pattern

Scott W. Ambler + Associates
Home | Articles | Books | IT Surveys | Podcasts | Contact Us | Announcements | Site Map
Recently reviewed Many software development project 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.

Motivation

There are two reasons, often co-related, why IT organizations choose to work like this:

  1. Cultural. Many organizations still follow a (near) serial development lifecycle where changes to the requirements are considered to be a bad thing which is best avoided. Typically, they take a big requirements up front (BRUF) approach where a detailed requirements specification is written, reviewed, and accepted early in the project. This requirements specification is baselined and then changes to it are "managed". To be fair, the serial approach is often so inflexible that a changed requirement can be incredibly expensive to deal with properly, so preventing change in these situations makes sense.
  2. Business constraints. It is also common to see business management insist on fixed price and/or fixed schedule for the IT project, often in an attempt to minimize their risk. Unfortunately, they don't understand the impact of this decision and they are in fact increasing project risk instead of decreasing it. IT management realizes that any change to the requirements will affect the both the schedule and cost so they are desperate to avoid any such changes.

Impact

The impact of this approach falls into two categories:

  1. Wastage. As I show in the BRUF article the primary problem is that significant wastage, on the order of 2/3, occurs on software development projects as a direct result of an inflexible approach to requirements change management. This occurs for several reasons. First, because stakeholders have learned that change will be prevented once the requirements specification is accepted, they are motivated to "make up" potential requirements during the requirements gathering phase in the hopes that they correctly guess what they're going to need. Second, requirements do in fact change over time, either due to changes in the business environment of because of a changed understanding of the domain.
  2. Poor business support. Similarly, when change is prevented the direct implication is that the business doesn't get the software that it actually needs, but instead it merely gets the software that it specified at the beginning of the project (when the least information was available to them to make decisions). Not only is money being wasted on implementing features which aren't required, it's not being spent on features which are required but unfortunately were missed during the requirements specification effort.

Solution

Take an agile approach to change management where you embrace 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 necessary.

Figure 1. An agile approach to requirements management.


Business risk is minimized because they can fund the project for as long as they like. Want to invest $1 million on the project 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 project. To be fair, regardless of your approach to development if your stakeholders aren't actively involved then you project is in serious jeopardy, but with this approach you're unable to hide this problem for long.


Suggested Reading

Disciplined Agile Delivery This book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise describes the Disciplined Agile Delivery (DAD) process decision framework. The DAD framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and provides the foundation for scaling agile. This book is particularly important for anyone who wants to understand how agile works from end-to-end within an enterprise setting. Data professionals will find it interesting because it shows how agile modeling and agile database techniques fit into the overall solution delivery process. Enterprise professionals will find it interesting beause it explicitly promotes the idea that disciplined agile teams should be enterprise aware and therefore work closely with enterprise teams. Existing agile developers will find it interesting because it shows how to extend Scrum-based and Kanban-based strategies to provide a coherent, end-to-end streamlined delivery process.
Managing Agile Projects Are you being asked to manage a project with unclear requirements, high levels of change, and/or a team using Extreme Programming or other Agile Methods? If you are a project manager or team leader who is interested in learning the secrets of successfully controlling and delivering agile projects, then this is the book for you. From learning how agile projects are different from traditional projects, to detailed guidance on a number of agile management techniques and how to introduce them onto your own projects, we have the insider secrets from some of the industry experts – the visionaries who developed the agile methodologies in the first place. Managing Agile Projects is edited by Kevin Aguanno, a noted speaker and educator on agile project management, and includes contributions from many noted figures in the agile movement.


Disciplined Agile Delivery: The Foundation for Scaling Agile Agile Modeling: Practices for Scaling Agile Agile Data: Practices for Scaling Agile EnterpriseUP: Agility at Scale AgileUP: Towards Disciplined Agile DeliveryAmbysoft Inc. Software Development Practices Advisor Scott Ambler + Associates Follow @scottwambler on Twitter!


Copyright 2006-2014 Scott W. Ambler

This site owned by Ambysoft Inc.