How About We Do Nothing?
Change control, or lack of it, is the death of many a well-conceived project or system. Making the wrong change decisions, or failing to understand their collective impact, can eat your budget and benefits faster than ants on a doughnut! So the traditional starting point in all change control has always been "do nothing."
However, in a contemporary Agile development environment, change may be embraced rapidly as the project progresses. Change is viewed as a good thing. Some may be led to think that change control is no longer important because we're viewing change is good.
This couldn't be further from the truth. Indeed, rapid change makes it even more important that we have a trace of who raised an issue and why decisions were made. It also remains the starting point that we "do nothing," so this must be our point of comparison when assessing change. We need a template that facilitates that comparison and records the decisions.
As you probably already understand, if you've been running projects for any amount of time, it happens to be the project manager who will always gets the blame, regardless of the origin of the ants. As the project manager, you must take firm control here. So if you’re a project manager, in any environment, this change control template may be for you.
A Basic Change Control Template
A change form needs to be simple but it really must capture some fundamentals. The template found at the link below is a good starting point for a more sophisticated approach, but captures all of the critical information for any given change. If you like, you can set this form up with a simple macro to fill a table on a second page of the spreadsheet. That’s something I won’t do here because macros send fear into the hearts of many readers.
The form uses the Excel data validation function to give you options for some questions in a number of boxes.
You can download the template here: Excel Change Control Template
Using the Form
To use the form, you need to choose the nature of the proposed change and its area of impact. I’ve set this form up with categories that will be useful in most ICT development areas, but if that's not you, the options can be changed to suit your circumstances by simply changing the contents of the validation section, to the right of the main screen.
Next, you should describe the change as clearly as you can with a good reasoning for why the change is needed. That might read something like: The web component language should be changed from Visual Basic to Java as this is the standard used by the web team and it will save a lot of development and maintenance.
You should record who raised the request, who recorded it and then you need Impact, Urgency and Status analysis. This helps sorting of your area’s priorities.
In practice, the initial assessment by the person raising the request is almost always adjusted later by the people assessing the request, but this template keeps that part simple by ignoring the problem! You could build that in if you like with a second set of boxes giving assessor name and assessor ratings.
The Change Control Authority is the person (or group) that has the authority to approve a change of this type and magnitude. Many organizations have rules about change levels based on impact. Don’t forget when determining this to make sure you think about potential impacts on other related systems and projects – ignoring that is a common career-fatal mistake.
Of course, once a change action is agreed, you as a project manager, need to pay some attention to the finalization of the action. So I’ve allowed a space to record the action and to track the status.
A Handy Hint
Here’s a hint that I’ve found works really well in managing issues and change.
Score your change requests on the basis of their Impact, Status and Urgency from 0 to 10, and then multiply the scores. So then a Critical Impact, Unactioned Status and Immediate Requirement will get a score of 1000 and one with no urgency or impact will score 0. Try to set your scores so you can draw lines at 250 and 500. Anything above 500 gets shown to Executive in weekly or monthly reports, anything above 250 is on the local/team "hit list" and the rest gets managed by individuals at a lower level.
That’s a simple enough idea that works very well in practice and Executives love it!
If you manage changes well, you can add enormous value to your projects and your own career will blossom. On the other hand, uncontrolled scope creep will destroy a project and a career faster than just about any other failing. Or in other words:
Change is a like a Ferrari, you should love it – but only when you’re driving it, not when it’s running you down!