The "Change Prevention Process" Anti-Pattern
|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.||
There are two reasons, often co-related, why IT organizations choose to work like this:
The impact of this approach falls into two categories:
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.
|This book presents a full-lifecycle, agile model driven development (AMDD) approach to software development. It is one of the few books which covers both object-oriented and data-oriented development in a comprehensive and coherent manner. Techniques the book covers include Agile Modeling (AM), Full Lifecycle Object-Oriented Testing (FLOOT), over 30 modeling techniques, agile database techniques, refactoring, and test driven development (TDD). If you want to gain the skills required to build mission-critical applications in an agile manner, this is the book for you.|
|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.|
We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer. A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.
This site owned by Ambysoft Inc.