Anatomy of a change request

Steve McConnell sets up the dream perfectly: With stable requirements, a project can proceed from architecture to design to coding to testing in a way that’s orderly, predictable, and calm.1

Of course anyone who has worked on anything knows this is exactly that, a dream. (He agrees) Changes are inevitable. They happen for a variety of reasons, and almost always2 results in a better end product. You know they are going to happen, so you you need to plan for them from the start. You should have a change procedure clearly outline with the client, and account for them in the initial budget. Here’s why:

A project change that takes 8 hours for a developer to implement, can easily require 16 man hours from a project budget, and cause a 5 day disruption in the production schedule.

Whoa! What? That’s right. Changes aren’t limited to the time a developer spends implementing, it can affect a big chunk of the production. Budget needs to be set aside for handling requests, because even if the change never gets implemented, there is a cost associated with it. Before you can budget for it, you need to understand it. Lets look at the anatomy of a change request.

1. A problem is flagged.

Change requests always begin with a problem being identified. Problems vary greatly, from “User flow is confusing” to “We forgot about X, which our funding requires.” These can originate from the client or internally.

2. Communication

Once a problem has been flagged, all stake holders need to be updated on the situation. This happens through emails, phone calls, and meetings (internal and external). If a developer is currently build what has been flagged, they may need to stop and wait for a solution.

3. Exploration

Once everyone agrees that the problem is legitimate, and a solution needs to be found, options need to be explored. This can be anything from a meeting to user-flow diagrams and wireframes, there might be prototyping and multiple explorations. The bigger the change, the longer this will take.

4. Spec out the solution

Once a solution has been found it needs to be spec’d out for everyone. This should be in the form of a document that a client can sign off on and the developer can use to build from. It should clearly out line the problem, solution, and affect on the project cost/schedule.

5. Approval

Approvals typically have turn around time to them where everything is in limbo. Nothing can be done between the time the spec is sent out till approval. Typically there is a fair bit communication that happens here as everyone makes sure they understand the changes. This step will have one of 3 outcomes:

  1. Approval, production can continue
  2. Proposal is rejected, modify or go back to step 2.
  3. Client decides the change is out of scope/budget. Continue with the original plan, flag for future change.

6. Implementation

The process doesn’t end with approval, the team now must make the change. This means undoing any of the original implementation that has changed, and then building what’s new.

7. Test

Testing! Every change needs to undergo rigorous testing. Is it a web based application? You need to test in all supported browsers/versions.

8. Bug fixing

Changes introduce new bugs. When you fix a bug you have 20-50% chance of introducing a new one.3 For every bug fix you’ll need to retest all the browsers.

Even if the change doesn’t go through, there is a cost attached to it. You need to stop productivity and spend man hours before you can even decide if there is going to be a change. If there is, you might add additional cost to the project, if not it falls into just part of the production process.

This will happen to some degree on every project, so you need to account for it. Both in your time line and budget.

1 Steve McConnell, Code Complete - Second Edition, page 39
2 I’ve worked on projects where changes happen for the wrong reasons. Internal disputes, lack of experience, “absolute” orders from higher up, have all caused changes for the the wrong reasons leaving the end user to suffer. Sometimes you have to bite the bullet, but you don’t have to work with the client again.
3 Stat from The Mythical Man-Month, page 122, 1995 print


development, Project managment, Change request

You can contact me on Twitter.


Browse All >