So your user requirements are well defined then. The customer desires have been captured. The list of features agreed. The design has been finalised. the specification signed off by all. Let the project begin!
Wait, what’s this – a request for a change? A new requirement? An alternative design? New features? We have a well defined plan, so we had better implement a strict change control procedure.
We’d better understand the impact of this proposed (and unwanted) change. The effect on the costs and the budget and the forecast profit, on the project schedule, on the scarce project resources, the effect of the change on project risk. We’d better get agreement with all of the project stakeholders. Can you please fill this form in and come to the next change control meeting in 3 weeks time? Finally your change is agreed, we just need to wait for the ‘Execs’ to sign it off, should be the end of next week……..
On the one hand a strict change control discourages change, and that keeps you to your original project plan. However, on the other hand, think about the effect on the subsequent projects. You are making change difficult, people will find a way to circumvent that.
Reluctant to Specify Exact Requirements
Maybe this is why people are reluctant to accurately specify their requirements? If they can make the user requirements as loose as possible, if they can be as vague and non-committal about the project details, well, then it won’t be a change at all – it’ll be adding more detail to the project plan. This means that you can’t accuratly plan your next project at all!
Interesting that one of the AGILE project management manifesto items is “to welcome change” as it leads to customer’s competitive advantage. Perhaps it’s time to re-evaluate your change control procedures, and encourage change rather than make it difficult.
If you’ve enjoyed this blog post, then please share it using the icons below. Thank you!