What’s the Issue with Change Control?
The old anecdote says: The change is only welcomed by babies. There is a lot of truth in it. We don’t like change on projects. But they happen. More than often. We dare to say if the project never experienced change it is not a project.
The researches over project cost leaking root cause conducted regularly in companies points to change as the second biggest reason for leakage after poor financial management. At the same time, it is hard Today to meet a single project manager who does not know how to manage change. The existence of change on projects is as large as ‘knowledge’ on how to manage change.
So, why change it is the second biggest reason for leaking costs in projects?
The knowledge is not enough. There are many other factors important to be successful in the execution of change management.
Below top 5 elements from our list.
‘The knowledge how to manage change is not enough. There are other important factors to be successful in execution of change management’
1. Clear Statement of Work
This is a fundamental factor, and this is where it starts. To be able to understand we have a change and start managing it we need to have a clear baseline. And this is a Statement of Work document which plays a major role here. Statement of Work, called in short SOW, deserves separate episode on its own, but we will briefly indicate its importance here.
Even we have a super project management 'file' with all necessary tracking information, SOW will play the fundamental role of baseline to which we measure change. Statement of Work is a legal document and part of the agreement between supplier and customer.
If we can acknowledge change based on SOW, we have a good starting point to manage change. Opposite if we cannot prove change using SOW – it is very hard to proceed.
2. Reviews for Scope, Schedule, RACI
I believe practically we can classify most changes into two categories. It is either scope or schedule. They are also interlinked.
For scope it is vital to regularly conduct scope reviews between supplier and customer. This is the only way to make change visible and acknowledge it to both sides without surprises. Let’s say we are after analysis of requirements (or rather detailing requirements) phase. This is a moment we need to confront the output of this phase against the originally planned scope.
Even if the difference in scope is not affecting our budgets to deliver, the customer wants to know that difference as soon as possible.
Scope change probably drive schedule change. But in this discussion we don’t explore each other’s impact.
Let's talk about Schedule change itself.
Schedule change is where the reason for change is coming from the customer side. If delay is coming from the supplier side – this is not a change – it is schedule overrun. We can try to convince the customer that schedule overrun is a change, but it is not easy if we don't have arguments.
Again, the same principle applies - review schedule with customer and RACI for each coming task. Yes 'coming'! Not past. This way all sides will know much better who’s cause is the reason for the change, when it comes.
Once Schedule change is acknowledged by sides it can be executed with all consequences.
3. Prediction, Communication
Managing the change is very much managing expectations in time. It takes the right communication.
For example if the other party (customer or supplier) must deliver something in the upcoming next 2 weeks. Talk about this on the next status meeting. It is probably more important to put this on “a table”, than talk about last week achievements. Remind the other party what is expected upfront. It will help both to avoid some unpleasant surprises and complaints.
Timing is everything.
We have seen this thousands of times. There is a clear case for change, and it is proven via SOW. All evidence is there. But we are waiting with communicating it. “This is not a good moment” we tend to say. We think we are risking customer's satisfaction.
If we wait too long to put the change on the table, it is getting outdated like fresh food.
It is almost given customer Project Manager will complain he was not told earlier. Often we can hear simple excuse “…If You would tell me early enough. I cannot do anything now...”.
And he/she is right. It puts the customer Project Manager into a bad perspective in front of its stakeholders.
5. Testing Change
Did we talk at the beginning if this is a real project the change on a project is given?
So, when it will come, we will have to execute. Executing change for the first time can be painful as both sides supplier and customer are testing process within own organizations.
If at the beginning of the project (or any later time) there is a small first change - don’t give it up or give it away. It is a perfect case to test the process for both parties.
Trust me the very next change (probably bigger) will be twice as easier to execute, if small one went through.
Executing successfully change is not a straight forward and easy activity. It needs a lot of experience and upfront smart preventive activities.
What if we can’t execute change because our Statement of Work is not clear enough to convince the other side of a change? Well some discussions may take a long time to conclude. Many times, trust and customer satisfaction will suffer.
- Get your SOW as clear as possible
- Review, Review, Review scope and time dependencies as project goes
- On status meetings talk more about the future than past
- If change happens execute the 'change management process' immediately. Don’t wait
- Test change on a project with a small one
Still, as in life, there may be some changes that are not executable.
This is where Risk Budget comes with some help. It does not solve issues, but to a certain degree it may help to manage projects on target.
Make sure You have a risk budget planned when estimating project financially.