Projects are aimed at delivering a defined result against a defined budget and on a defined moment in time, the “go live date”. The time factor in projects controls many things, first of all costs but also the delivery of the benefits of the project. When projects encounter problems that the project team has a hard time to overcome, then potential delays in the go live date quickly emerge. This varies from a vague hunch or rumor discussed at the coffee machine to a formal agenda item in a steerco. The question arises if and when the project management and steerco will allow for a revised go live date and a revised plan? Often people tend to stick to the original plan rather than face reality – why is this?

The first reason lies in the belief that it is “wise” to keep the pressure on the project team. Do not let go of the planned go live date until the very last moment. All that time everybody will be focused on making the “unachievable” go live date and thus we will get the most out of the team.

Secondly, some organizations have a culture in which “not failing” is more important than “succeeding”. This brings decision makers in the fairy tale of “The Emperor’s new clothes”: everybody knows we are not going to make the original plan but nobody dares to report it formally. Red traffic light reports have turned green by the time they rise from the project work floor to the level of the steerco. Although in smaller projects this way of working may be somewhat acceptable, in larger programs (think >100 staff involved, budget > 10M Euro) this way of managing projects has many downsides.

First of all, in larger programs there are often multiple dependencies between projects. Any delay in one project can trigger a cascade of delays with other dependent projects. Being blind to this effect prevents any counter measures to limit the impact of a delay in one project. Secondly, as people are still working towards the original go live date, they will find ways to cope with the situation of insufficient available time. This can result in pushing people to or over the maximum what they can take in terms of work hours, taking short cuts (e.g. not testing critical functionalities) and taking risks beyond what is acceptable. Whether or not the steerco allows to reduce the scope of the go live, in effect the project team (both ICT and Users) will descope bit by bit to make the go live date. “Non-critical functionality” will be deferred to the “Aftercare Phase” which in effect means the project will run on for another 2 or 3 months after the go live. In multi-year programs this simply means that the next phase of the program will be faced with the delay since the people that were needed to start the next phase are still busy with the “Aftercare” of the previous phase.

Should the steerco, after sticking to the original go live date, and thus “keeping the pressure on”, decide to change the go live date at last minute, then the question is “what has been gained?” or rather “what has been lost?”. First of all, it is doubtful that in the time left until the new go live date the project team can make up for the short cuts that have been taken. For example: re-doing a test-cycle, but now properly, often takes the same time needed for it as originally planned. Secondly, teams that have gone through a period of stress and long hours will need to motivate themselves to continue working on that tension level during the extra time.

And thirdly, the users in the business, who need to cope with project work next to their regular job anyhow, may lose faith and interest in their IT department and the associated program. Finally, as a leader of the program, you may ask what kind of reward you will expect from higher management for hiding the facts and coming with a delay message at the
very last moment and thus jeopardizing the program.

In conclusion: we are not advocating to let go of a plan and go live date on the first sign of any issue in a project. Projects are full of issues and risks by nature. It is the task of the project manager to manage these together with the project team. However, we do advocate realism: face the facts and take decisions based on these facts. When reality has come to a point where people need to recalibrate their plans, then this should take place, how unpleasant that may be. It will deliver more value in the longer run of the program.