Change

We aim to keep all our offices ISO 9000 certified. This means updating the procedures to reflect our increasing tendency to run software development projects under an Agile process. It's fallen to me to update our existing "Change Control" procedure which of its kind is very good, but does build up from the assumption that to have a change to control is an exceptional (although expected) event.

I keep wanting to turn that inside out and say—deal with every requirement this way, make this the default, make the threshold of cost/schedule/risk impact for triggering change control be 0.0 in all cases, have the Change Control Board meet every week, have them assess the impact of every item and decide whether or not to schedule it, have no other way to schedule any activity than via the change log. And bingo! Your project would pretty much be agile.

In fact, I might just do that.

1 comment:

Dave said...

You should do that. On some old projects we used to joke that change request number 1 is always "create solution". In agile terms you could have a whole row of CRs "create release candidate 1", "-2", "-3", and so on.