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 a project never experienced change it is not a project.

The research over project cost leaking root causes, conducted regularly in companies I worked, points that a change is a 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’ of how to manage change.

So, why change it is the second biggest reason for leaking cost in projects?

Knowledge is not enough. There are other many factors important to be successful in the execution of change management.

Below top 5 elements from my list.

The knowledge of 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 do have a change and then 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 a separate episode on its own, but we will briefly indicate its importance here.

Even we have a super project file with all necessary tracking information, SOW will play a fundamental role of baseline to which we measure the change.

If we can acknowledge change based on SOW, we have a good starting point to manage that change. Opposite if we cannot prove using SOW, we have a change – it is very hard to proceed.

 

2. Reviews for Scope, Schedule, RACI

I believe practically we can classify all changes into two categories. It is either scope - requirements or schedule. They are also interlinked.

For scope, it is vital to regularly review it by Supplier and Customer. This is the only way to make change visible and acknowledge it to both sides without surprises. Let’s say in the projects we are after the 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 difference in scope is not affecting our budgets to deliver Customer wants to know that difference as soon as possible.

Scope change probably drives schedule change. But in this discussion, we do not explore each other’s impact.

Let us talk about the Schedule change itself.

The schedule change is where the reason for the change is coming from the customer side. If this is coming from the supplier side – this is not a change – it is schedule overrun. But is not easy to say to the Customer:  Because of you, Dear Customer, we have a delay.

Again, the same principle applies - review schedule with customer and RACI for each coming task. Yes coming! Nor past.  

This way all sides will know much better who is in charge for the change, when it comes.

3. Prediction, Communication

Managing the change is very much managing expectations in time. It takes the right communication.

As example if the other party (Customer or Supplier) must deliver something as part of the project activities in the upcoming next 2 weeks. Talk about this at the next status meeting. It is probably more important to put this on “a table”, than talk about last week's achievements. Remind the other party what is expected upfront. It will help both to avoid some unpleasant surprises and complaints.

4. Timing

Timing is everything.

We have seen these 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 satisfaction and at least the discussion.

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 the 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 in bad perspective in front of his 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 comes, we will have to execute. Executing change for the first time can be painful as both sides Supplier and Customer are testing process within their own organizations.

If at beginning of the project (or any later time) there is a small first change - do not 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 a small change went through the full acceptance process.

Conclusion

Executing successful change is not straight forward easy activity.  Needs a lot of experience and upfront preventive smart activities.

What if we cannot execute change because our Statement of Work is not clear enough to convince the other side on change? Well, some discussions may take a long time to conclude. Many times, trust and customer satisfaction suffer.

To summarize:

• Get your SOW as clear as possible.
• Review, Review, Review.
• On status, meetings talk more about future than past.
• If a change happens execute management immediately. Don't wait.
• Test change on a project with a small one.

 

But still, there some changes, which 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 a project on target.

Make sure you have a risk budget planned when estimating the project financially.

 

Note and Disclaimer: The author of this Blog post is Marek Rudnicki. He is the guest author of PMI.hu. The writing reflects the author's own professional opinion, findings, and conclusions, which do not necessarily agree with the position of PMI Budapest, Hungarian Chapter, and cannot be considered as an official recommendation, resolution, or opinion of PMI Budapest. The copyright and publication rights of the writing belong to the original author.