The evil of changes during development

PM Clinic: Week 24 discussion summary

Compiled: 4/15/2005

The Question:

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 client needs.

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 way:

1. Communication of the desire to change something
2. Understanding and documenting the change
3. Quantifying the value of the change
4. Designing the change
5. Assessing the impact of the change (features, schedule, resources, etc.)
6. 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).

Planned change:

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.

Contributors

Mark Colburn, Gareth Howell, Fasial Jawdat, Neil Enns, Scott Berkun (editor)

About PM-Clinic

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 rules.