Hey, don't worry, change is OK, it just needs to be acknowledged, recorded, assessed and properly communicated so that something can be done about it.
"We can't report we're behind programme, make sure the 'end date' doesn't move"
"We can't show we're slipping, reduce that duration to make it fit"
"Don't reschedule it, just show the 'jagged line' or 'drop line' "
These are some of the statements from managers that I've experienced in my early days on typical building projects - mostly under JCT contract, but sometimes even under NEC. Why? Why do you think that's a good idea? Why would you want to do this?
Typical answers to this are things like; "the client and directors won't like it and we'll probably pull it back over the next month," or "Our people and the client don't understand programmes..."
This is both frustrating and total rubbish - if the programme is not understood, then take the good data from it and put it into a format that people will understand. This is the basic tenet of communication:
It's the responsibility of the person delivering the message to ensure that the person receiving it has understood the message.
Mitigation in programmes is fine and should be routinely done - it is a Project Team's responsibility to do so in fact. However, there is a difference between true mitigation and chopping out vital logic in a programme just to show something finishing on time in an act of blind faith.
There seems to be this fear and archaic habit or practice of hiding the movement of forecast key milestone dates as a project goes on, as if the programme can never change and it's 'set in stone' (another ridiculous phrase). Then at some point, the project can take no more and pops out like a coiled spring. Stacking up a programme means more resources that you don't have. All of a sudden when this is realised, in a monthly update the project has a 3 month delay when only the month prior, it was reporting on programme and then everyone loses their minds.
The project gets 'pawed' over by high level directors who want answers as to why the project that was looking like it should be a commercial success, is now a potential commercial nightmare. External parties are asked to come in to review the programme and try and unravel the mess because the project team was too under resourced to deal with it then, let alone now.
The client wants answers too - how can you tell me we're on programme one month, then so far in delay the next? What happened? Why are you trying to tell me it's my fault now?
So why does it happen? Why are people so afraid to report 'bad' news / programme slippage? I believe it happens for a few reasons.
-1. Thoughtless Best Endeavours / Fear / Culture / Dumb Pride
-2. Processes for monitoring progress and dealing with change not in place and a lack of understanding of the Contract and Scope
-3. Not enough resource to deal with change
Best Endeavours are dangerous when there's no thought involved. Of course, everyone wants to report good news and keep people happy, but it is much better to deliver facts (even if the news is bad) with a well thought out mitigation plan, than say everything is OK when it's not. In some cases it's clear that Fear of bosses coming down on you for every little slip on programme means it's easier to hide a seemingly small problem at the start. However, forcing programmes to fit contract dates without understanding the commercial implications of this causes so many problems anyway, but is amplified when it becomes apparent that it cannot be achieved for all stakeholders involved. Projects are dynamic and programmes will always evolve, so there needs to be a system that allows consistency and transparency in how the project progress is measured. The most basic yardstick is a current accepted baseline shown together with where the live programme moves to when progress or change is applied. Higher level management need to understand and appreciate that too in a lot of cases as company culture and action comes from the top.
Not having processes in place for Project Control and dealing with change and a lack of understanding of the Contract and Scope is a big issue. How can you be compensated commercially when change occurs if you're unaware of the scope of what you should be doing? Then even if you do know, how can you agree change when you don't understand or go through the proper process to measure it's impact? Time always costs and therefore, the accepted programme (to borrow an NEC term) is the best tool that you have to assess the impacts of change. If you've been squeezing parts of the programme to fit because you think it's the news people want to hear, understand that you're effectively accelerating the programme and acceleration = cost, cost that you won't ever get back if you fudge the programme.
Then there is the most typical problem: not enough resource to deal with change. In a lot of cases, there is not even enough resource to adequately record progress on a project, let alone deal with change processes as the contract requires. What seems to happen all too often to a contractor's prelims when they tender for a project is something like this (generalising):
Project or Estimating team puts the prelim book together and allocates the staff they think they need to run the job. This goes up to be presented at regional or board level for sign off who promptly strip the prelim book of resource to be more 'competitive.' So, what was a full time planner and QS becomes a visiting planner (usually 1 day a week) and a part time QS. The Site Managers are expected to then update programmes and record change whilst also doing their other day to day jobs.
This is a false economy since the Project or Site Managers get overwhelmed and don't have the time, let alone the skills, to carry out the roles of a Planner and QS when the project really starts to move. Reporting becomes worse and worse as more packages arrive on site to manage and the programme gets left since Managers only have the time to deal with the day to day.
This is something that needs to be addressed by clients and their advisers also as if the project isn't adequately resourced with key roles, they should revise their budget to allow the inclusion of appropriate resource or expect a bumpy ride with poor project delivery.
These pitfalls can be avoided if proper processes are put in place and the programme is actually used as a tool to manage the project. Get the right level of resource involved and get them into the programme so all can trust what it's forecasting. Then naturally with the right level of resource and enthusiasm, the programme can always be current and communicated in a way that everyone can understand.
Remember, Forcing the Programme to Fit is always a terrible Idea...