It has been said that the only things that are certain in life are death and taxes. Unfortunately, they forgot to mention change within a project is also inevitable! Now we humans don’t like change – particularly when we have everything ‘nailed down’ – but we would be foolish to kick off a project without some agreed mechanism to manage change.
Changes can come from a variety of sources, but luckily these can be categorized as follows:
1. A Request For Change (RFC). This is a request from the customer or user. The change may affect the functionality, acceptance criteria, or the scope of the project. It will normally have some cost and/or time impact.
The change may affect a product currently under development or an already existing product.
2. Off Specification. This is a statement of non-conformance from the supply side of the project. That is, those creating the products or deliverables. The change may affect the functionality, acceptance criteria, or the scope of the project. It will normally have some cost and/or time impact.
The change will affect a product currently under development, and is a statement of a failure in some way of meeting the customer’s requirements.
3. A Query, Statement Of Concern, A Suggestion. These are catch-alls for what is left! Not strictly a change, but more of an Issue, that may result in a change.
This last category might be a ‘good idea’ that if implemented would result in an improvement – either from the customer or the supplier side of the project.
Dealing with an RFC, which by definition is from the customer side, suggests that if any costs are incurred, then the customer should pay for them.
An Off-Specification on the other hand is from the supply side, and any costs should be funded by them. Now the customer may take the view ‘I’ll take what you can give me”, in which case they concede (a concession!), and so no extra costs are needed from the supply side.
There is no doubt that changes cause problems (at a minimum, extra work and hassle!) for the project manager, but to state ‘we will not allow any changes’ is neither practical nor beneficial. Suppose you are driving down the main street of your local town looking for a place to park – when you suddenly see a free space up ahead (project end product). You signal and start to manoeuvre (implement the Plan).
Just then a child steps out a few yards in front of you…
Do you hear your head saying “nope! nothing’s stopping me from getting the project completed”, or do you take immediate action to avoid the child? Obvious isn’t it!
Welcome to Change Management Models and Change Management training!
Now just because we all agree changes CAN happen – doesn’t mean they SHOULD. All changes should be considered in terms of there ‘value’. The benefits of making a change should be weighed against such factors as the cost of the change, its impact to the Business Case, the change leading to more risks, etc.
In short, the consequences of the change should be in proportion to the change itself. Another point to consider is that large or many changes lead to large amounts of effort being expended. If these are not carried out under control this can lead to low morale within the project team.
Much of the emotion comes from when the change environment has been poorly set up within a project. The project manager ends up with their head in a vise – management on one side, customer on the other. Changes are forced upon the PM, and management complains. Bad News!
Here’s the Good News!
The simple answer is to organize the management of possible future changes involving management, customer, users, developers, etc, to cope with the effects of change and to agree on the impact. This is called Change Control.
At its heart are the following prerequisites:
- An agreed and signed-off Plan at the start of the project containing a ‘baseline’ of all deliverables or products. This may include other documents such as Requirements, Specification, Product Description (containing Quality Criteria for each product), Acceptance Criteria, and so forth.
- A hard copy or electronic means of raising any proposals for change.
- A central Log containing details, decision, impacts, and status for all changes
- Mechanisms for evaluating the impact of each change.
- A decision-making process for the appropriate authority for agreeing or otherwise, each change.
- A record of this agreement
- A method of monitoring the change through to its successful implementation.
Three further points worth making here are:
It is a good idea to include a priority filed for each Change, so that the originator has the opportunity to comment on the importance of a request. This is also useful so that once an impact has been carried out; the originator has a chance to comment again. For example, if the change was seen as a vital must-have by the originator, but the impact showed the change would cost a million dollars – they may wish to re-calibrate the priority.
The amount of changes expected within a project may be determined by factors such as:
agreement has yet to be made about the specification – but because of an aggressive time-frame, management agree to start work on the project immediately. It’s highly likely that changes will be high.
The end business environment of the customer is very dynamic, and by the time the project completes, there are likely to be many changes to respond to that business environment.
Finally, some thoughts about the management of such changes.
If the Sponsor (or Project Board) does not have the time, skills, or knowledge, they may delegate their responsibilities for change to a Change Authority to authorise any changes on their behalf. They may also set up a ‘Change Budget’ to fund any changes – this also allows the Project Manager to manage ‘real’ project cost, rather than hide changes in cost overruns.
Similarly, if the rate and impact of changes is expected to be high, a Change Budget can be set up. This is separate from the project budget, and allows better visibility and control of spending.