Forcing projects to meet fixed go live dates
It seems to be a universal law that your plan will give an end date 1 month later than your customer wants. This happened to me very recently. My team and I spent months in design and produced a detailed but realistic project plan. We communicated the plan to the client and explained the dependencies. The response from the client was:
"I understand that you cannot put 10 men to get a baby in 1 month ... reasonable argument..
But [date] is too late... so we need to find out - what else that can be done [...]
I know we can be more creative in pulling at least 3/4 weeks ahead."
I am not sure why the client was so convinced that it would be possible to reduce the average pregnancy by 3 to 4 weeks by being creative. However, bizarre though it is, this analogy provides a useful argument against crashing a realistic but acheivable plan. Premature babies have to be put in incubators and cared for round the clock and consequently their first few weeks are nerve wracking and stressful for everyone concerned. Even if it is possible to squeeze a few weeks off a plan, Is it wise?
All projects produce change and with change comes uncertainty. To achieve a sense of success following a go live event you need to establish:
- a calm atmosphere,
- identify and celebrate quick wins and
- sooth nerves.
IT projects that are rushed, go into the world with bugs, and niggling issues that increase the anxiety and stress of the users. Instead of feeling a sense of achievement and positivity users are left with bad memories and ongoing concerns for the future.
A project is more than it's go live date. In fact can we really argue that achvement of a delivery date is ever the real measure of project success? When your client questions whether you can't just find a few extra weeks, ask them how the success of the project will be measured in 2 or 5 years time. I guarantee the go live date don't won't be a measure of success. Next ask whether the reduction in timescale is worth putting the achievement of those long term goals at risk. If nothing else this will make your client stop and think.
If they still insist you will have to try to meet the dates by crashing and/or fast tracking the plan. Don't be tempted shorten the estimates arbitrarily, project managers are often put under great pressure to cut days, the assumption being that there must be some 'fat' in the estimates, bear in mind this quote from Dennis Lock:
“never must the project manager allow himself to be persuaded or coerced into trying to expedite a plan simply by ‘marking down’ estimates without any justification [....] Such optimistic plans can gain a temporary advantage by serving to pacify higher management or by deceiving a trusting customer into placing an order. Unfortunately the truth is bound to emerge sooner or later, bringing consequent discredit on the company." (Lock 1996: 128)
Crashing and fast-tracking plans
Project Managers may consider many ways to resolve scheduling issues. These options will fall under one of two approaches: crashing or fast tracking
To crash a plan resources are added to activities to shorten their durations. Crashing only works for activities that are on the Critical Path and are effort driven. Fast tracking involves checking the project logic and deciding whether the finish to start dependencies are essential or whether tasks can be overlapped.
Crashing typically increases project costs as additional resources are used while fast tracking increases the risk of rework as activities are started before their predeccesors are completed (PMI 2011: 32).
There are many ways to resolve scheduling issues and more detail is given in the MS Project User Guide provided with the ms project templates.
Further reading and bibliography
Lock, D. (1996) Project Management
Sixth Edition, Aldershot, England and Brookfield, Vt: Gower Publishing Limited
Lock, D. (2007) Project Management
Nineth Edition, Aldershot, England and Brookfield, Vt: Gower Publishing Limited
Project Management Institute, Practice Standard for Scheduling – Second Edition
, 2011, Project Management Institute, Pennsylvania