The evil of changes during development
PM Clinic: Week 24 discussion summary
In every company I've worked for, there's been a breakdown between developers and
marketing about managing changes. Right now I'm in a small company that uses CVS and
Bugzilla to manage development. Before a project starts, we have a marketing requirements
doc and a Software requirements doc (SRD). The SRD has mockups done in Photoshop to
give the developers guidance as to look and feel. Marketing here isn't a strict role,
basically it's people that interface with clients on a day to day basis who understand
Everyone here wears several hats. Along the way, as in most companies, marketing/clients/executives
request a zillion changes... move this drop down, change this text, change these colors.
It's not feature creep - just little things that drive developers crazy because of how
many there are. To track them, marketing now enters them into the bug tracking system
which drives me and the developers nuts. Now development is asking that instead, *they*
write a document asking for this stuff and to stick the doc into CVS!!!
Any thoughts on the best way to deal with these myriad change requests? I suppose they
could be entered into Bugzilla as "enhancements" rather than "bugs" but the overhead
to enter a request, assign the request, make the change, update the entry, assign it
over to QA, test the change and close the entry just seems frustratingly high.
- "Design changed" to death
How to manage change:
The lingo for dealing with changes during development is change management. You can
find this topic in books on engineering or project management. Colburn defined it this
- Communication of the desire to change something
- Understanding and documenting the change
- Quantifying the value of the change
- Designing the change
- Assessing the impact of the change (features, schedule, resources, etc.)
- Accepting or rejecting the change
This can be a formal team process (Typically with some kind of meeting for #5 and #6)
or an informal one.
All changes of any kind have some cost - that's why they're called changes. The more
people impacted by a given decision the greater the odds of costs and the more complicated
figuring them out will be (think localization, documentation, usability, etc. They all
make decisions based before the change and may have to make their own changes in response
to your change).
Questions to ask about incoming changes:
- Is this a change that is in the scope of our current product?
- Given the goals for the project how important is this change?
- What percentage of users will be affected by this?
- What percentage of the product code will be affected by the change?
- Are there easily identified workarounds to the change in the product?
- Is this a competitive threat? (Do our competitors have this feature?)
- How important is this to the customer? The user? Marketing?
- Does this augment, conflict with, or replace a current feature?
The sooner you can make clear to everyone that these questions represent the minimal
checklist for even considering a change, the fewer you will have to deal with. You can
make a list like this, get team leaders to agree to uphold it, and preemptively send
it out to the team before change requests start to come in.
The change control board:
It's common for teams to set up special groups to manage change requests. Typically
the senior person for each role (test, programming, project management) are on the board
and they review all incoming change requests.
When these boards work well, they don't have to review many changes. They define a
policy for what kinds of changes should even be considered (see questions above) and
then review only those changes.
The change board should meet only as often as needed to manage the incoming changes
and make senior decisions on them. The length and frequency of change board meetings
indicates the state of the project: if meetings are 5 hours long and happen every day
then either the project is in trouble, or the level of change requests being considered
needs to be narrowed.
Defending the schedule:
Someone has to defend the schedule against change. If no one ever says no to the VP
or customer, even if the request is bad/stupid/self-destructive, then the VP or customer
will continue to make that kind of request. Someone has to remind the team of the commitments
they've made and make sure there are really good reasons for breaking those commitments.
Of course you may not have the power to defend the schedule, but you can still try.
Then if someone with more authority than you dictates change you will know that they
are doing so in spite of your strong recommendation not to. Should things not turn out
well later on, you objection may have been noted by enough people that a different course
of action will be recommended by others next time around.
(And be warned: saying no to all changes is almost as bad as saying yes to all changes.
Your position on change should be dictated by the project goals and an evaluation of
the change in question).
A well managed project can budget time in the schedule for late adjustments. They will
keep this in reserve until the project is complete enough that oversights will be visible
and can be understood before resources are committed to them.
However, typically software projects are managed at 100%, with all resources being
committed to features. This gives the project manager no reserve fuel to use later on
and must scrap together resources or cut features / quality.
Mark Colburn, Gareth Howell, Fasial Jawdat, Neil Enns, Scott Berkun (editor)
The pm-clinic is a friendly, wise, open forum for discussing how
to lead and manage teams of people. Each week a new situation is sent to the list and
we share advice, ideas and stories. Anyone can join as long as they follow the simple