Project Crashing in Project Management | Velopi
Whether you have a certificate in project management or not, it is probably true to state that you cannot consider yourself a project manager until you have dealt with at least one project that has drifted away from its baseline schedule. This is a regular occurrence. Every project has an element of uncertainty and schedules often depend on the weather, supplies arriving on time and people getting work they have never attempted before done in the time they have estimated. But, thanks to PMP® training, you have some techniques to get things back on track.
You can fast-track the schedule. This is the process of executing certain activities in parallel than were planned to run in sequence. Usually this involves starting something before its predecessor activities have completed. There is a risk attached to this approach – some rework might be required if the predecessors do something unexpected towards the end. For the PMP® in charge, this process is akin to juggling: we’re blocked here, what can we do instead?
Time is one of the Triple Constraints. To control the schedule aspect of a project, you can compromise on the other factors. The obvious one is to shed scope – our project is running late, so we will not get everything planned onto the release. In some circumstances this is acceptable, but the PMP® must consider this in advance and organize the work so features are independent of each other and their relative priorities are understood. Another possibility is to cut corners with quality. This is not recommended. Steps to improve quality – more upfront research and design efforts – might not look important when the project is running late, but they do save in testing and rectification down the line. The cost of fixing an error increases all the way down the development path. When you regard time as a cost, you can see that designing in quality upfront, will save time in the later stages.
If time is crucial – there is a hard deadline to meet for instance - then you might consider throwing more resources at it. On PMP® courses, this is called “crashing” – an unfortunate term for a step that might prevent a project from hitting the buffers. However, crashing is not a panacea. PMPs® often bemoan budget constraints, but having a surplus of resources can be as bad as too few.
Back in the early 1970’s, an IBM employee named Fred Brooks wrote a book called The Mythical Man Month. If he were writing it today, he would probably have had to use the gender-neutral title – The Mythical Staff Month. But for all its antiquity, the Mythical Man Month contains a lot of useful caveats.
For instance, he argues that the schedule for a large project should not be based on the scheduling experiences with a small project (casting doubts on the “analogous estimating” technique recommended in our PMP® courses). This would be equivalent to estimating that someone can run the 1,500m in two and a half minutes, because s/he can do the 100m in 10 seconds.
But the major concept in The Mythical Man Month is the view that adding more staff to a struggling project will only make it later. The problem relates to communication. If we add a new person to the team, someone will have to take time off other project-related tasks to bring the newcomer up to speed. Then we have to include that person in discussions. If you recall your PMP® certification days, you will remember the formula for communication channels is N (N – 1) / 2. However, the PMP® courses do not mention the formula for the increase in communications channels when a new person is added, maybe because it reduces to the single variable N. So for every new person put on the project, you add as many communication channels as there were original members on the team. So the bigger the team, the greater the consequences of adding more people are, in terms of communication overhead.
So be careful when adding staff to a project. Unless your project has discrete tasks that can be done without interfering with other work, adding new people can lead to everyone falling over each other. A good example would be a house construction project. Suppose we are behind schedule because of bad weather at the start of the project. Then getting a gang of plasterers in and assigning each one a room to plaster makes a lot of sense – the whole of the interior can be plastered in a day. However, the same trick might not work so well with plumbers. Assigning one person to the kitchen and one each to the bathrooms around the house might look good on paper, but in practice all these people will need to connect with the boiler and the attic tank. Then some plumbers will want the water cut off so they can make connections, while others want the water on to test their work. While poor communications here can lead to humorous outcomes – unexpected showers for unwary plumbers - the same cannot be said for lack of communication between electricians, where mistakes can be fatal.
For more information on controlling a schedule, please consider one of our project management certification courses. We hold our project management courses online in our virtual classroom. Find out more by contacting us directly.