Controlling change

I was between two minds about writing this post. After all, everyone knows that change control is important, don’t they? Then I remembered a couple of interesting cases where people did not seem to know that.

In one case, a junior programmer had developed a very good rapport with one of the customers, a desirable thing to be sure. However, this good relationship resulted in the customer’s going directly to the programmer whenever he wanted something changed. The programmer would then go to the secure room and make uncommented changes to the live code. That’s worth saying again.

He would make uncommented changes to the live code.

This pattern of behaviour was discovered when one day the live system stopped working. The resulting down time while the problem was fixed was costly to both the business and the solution provider.

I don’t know what happened to that particular customer and the programmer, but I imagine they got an earful from their respective managers.

Must... control... change...

In another case, the customer did no business analysis at all before providing system requirements, but used User Acceptance Testing as a mechanism for analysing the requirements. The result was the customer would often say: “No, that’s not what I want” even though it was what he had asked for. He would then tell the programmers to change it. They would immediately change the application based on the new requirement ( see the second bullet point below). What is more, they would make the change based on an e-mail or a note from a telephone call, but would not update any of the requirements documentation. Consequently, when a new service provider came along and read the system documentation, it did not describe the live system.

Changes to anything that has been signed off need to be controlled. Uncontrolled changes have consequences and those consequences cost money.

So what are the consequences?

• Risk of breaking a live system
• Unplanned cost for a solution provider on a fixed-price contract
• Unplanned cost for a customer on a time-and-materials contract
• Delays until project completion – delays that do not feature in the project plan
• System documentation out of step with live system (if a new solutions team comes on board, customer has to pay for the time taken to understand the live system)

Making sure change is managed is everyone’s responsibility. The implementation of change to a baselined product, whether it be a document or a live system, ought to be accompanied by an approved Change Request.

Takeaways

• Make sure you understand your project’s change control process
• Make sure you know who your project’s change manager is
• Managed change good
• Unmanaged change bad

Kind regards,

Declan Chellar