A lesson I learned many years ago from a very experienced project manager related to managing the changes in a project.

The project was nearing completion but was over budget and over time.  I was not managing the project.  It was being managed by a colleague from the same company I was working with at the time.  He was asked to attend a board meeting to discuss the project.  He suspected it was an ambush.  The CEO was going to try and put the blame on the project manager and possibly fire him.

The project manager seemed unconcerned.  He told me that it was all under control and no action would be taken against him by the board.  I did not understand his proposed defence but he was adamant that he could convince the board of the quality of his project management.  He was one of the best project managers I had ever encountered so asked what my role would be.

“Witness.”

The meeting unfolded as expected.  The CEO spent some time outlining the cost and time overruns.  He detailed how the board had approved the appointment of the project manager but the project had now run out of control.  As CEO he pointed out he had many responsibilities and had not had the time to become intimately involved in every detail.  He had sought reassurance from the steering committee that in spite of what had seemed warning signs, all was well.  They had assured him it was.  Finally he had heeded those warning signs, stepped in and found the situation worse than expected.  The budget to complete the project was some 50% over, and it was running several months late.  Our company should be called to account and made to share the cost of the failing project.

There was one board member who knew the project manager well from a previous engagement.  He had in fact recommended this person lead the project.  During the tirade by the CEO, the board member was looking curiously at the project manager as if to say

“Aren’t you going to defend your actions?  Surely this cannot be true.”

I must admit I was feeling uncomfortable but the project manager looked calm and relaxed.  Finally he was asked to respond.  The response went something like this.

“You guys run a tough company.  It is hard to get recognition for a success.  Yes we are 50% over the original budget and yes we are three months over the original schedule.  If you look at the papers I have here you will see that every variation has been estimated in time and cost, and approved by the Steering Committee and CEO.  In fact if you add them all up, you will see we have added 60% to the original budget in terms of cost, and four months to the schedule.  I am actually under the revised budget, and ahead on delivery.

I also have a file of rejected variations that would have put the project another 50% over budget.  Every change is costed, evaluated, considered by the steering committee and approved or rejected.  Nothing that will impact the original scope is undertaken without approval.”

He sat down.  To say there was silence would be an understatement.  It was beyond silence.  It lasted about a minute.  The only sound was the wheels turning in the head of the CEO as he tried vainly to find a way to dig himself out of the hole.

Finally the friendly board member spoke.  He said to the CEO.

“So how is it you were not aware of the cumulative impact of the changes?”

Much stuttering and stammering followed.  In the end the project manager was congratulated by the board for the process and control he brought to the project.  The CEO was reprimanded for wasting the time of the board, and not being across details he should have known.

The lesson I took away from this was that every variation needs to be quantified and submitted for approval.  More importantly there needs to be a strict process in place for this to happen.  It is always easy for the project manager to say yes.  Nobody will thank you for saying yes when the fan takes on a brownish hue.

Neville Turbit is principal of Project Perfect.  Project Perfect sell Project Management Software as well as consult on projects and undertake Microsoft Access Development