Expert advice on fixed date projects
As part of this month’s focus on managing projects with fixed dates, I asked J. LeRoy Ward, PMP, PgMP, Executive Vice President Product Strategy & Management at ESI International for some advice.
What sort of projects have the delivery date fixed in advance?
Projects that have their delivery dates in advance can be found in every industry vertical and around the world. Key ones are projects that are required by law, such as new tax codes that take effect on at the beginning to the tax year, a court order, a regulation, or other governmental or judicial edict.
Many construction projects have fixed delivery dates if the project is being done in an area where the weather prohibits work before or after a certain date or “season.” Think, Sweden, Antarctica, the Middle East or other places with extreme weather conditions which simply prohibit construction during certain seasons.
Many projects that launch new products will also have fixed dates to take advantage of seasonal activities, buying habits, the phase out of an old product for a new one to avoid overlap. Consider the announcement of iPad. Very carefully timed to coincide with a range of marketing and production moments in time.
Fixed delivery dates are found in any project whose end date is critical to revenue generation, service to a client, or maintaining operations. For example, many telecom projects have fixed end dates. In the case where the telecom “switch” (the computer than runs the phone and data system for a large building or group of buildings) is being swapped out for a new switch, this is often done over the weekend. Outsourcing operations or functions are another good example here. When a company moves to outsource services such as payroll, there is a critical date when everything must be tested and ready to “go live” to ensure continuity of operations.
Quite frankly, most organisations, governmental and non- governmental alike, mandate that projects be done by a date certain. So, these days, project managers are faced with such demands and edicts on all projects.
What are the challenges of managing projects where the delivery date is fixed in advance?
The main challenge is resource availability and allocation in order to get the job done by the fixed end date. When a project’s end date is fixed in advance, the project needs to be planned “backwards.” In other words, the project manager takes the end date and develops a plan of action working backward in time to a start date. It is hoped that the start date is after the date the analysis is done. If the start date, based on the plan, falls earlier than the date on which the plan is constructed this means that the project is already late.
In this case, the project team needs to formulate a plan that will actually cause the project to be completed when required. In short, the project manager needs to compress the schedule to meet the end date if it is physically possible to do so.
In classic PM terms, schedule compression is achieved through two approaches:
- Fast-tracking, where project activities are done in parallel or with overlap to the greatest extent practicable; and,
- Crashing, where additional resources are allocated to those activities on the critical path, thus reducing time.
In many instances, the network diagram developed by the project team represents how the project should be done, based on best practice, experience, or desires of the team, rather than how it “must” be done due to physical constraints. For example, it is obvious that you cannot build floor two of a building before floor one is built, but you don’t always have to have the design of a building complete before you start its construction. It is rumoured that Burj Khalifa in Dubai had not completed its design until it was almost complete thus keeping people in suspense to the end as to how tall it actually was going to be.
In reality, and in very tough circumstances, an experienced project manager will employ both fast tracking and crashing simultaneously. Each approach has disadvantages: fast tracking increases risk because of doing more work concurrently rather than sequentially; crashing, on the other hand tends to increase cost.
Additionally, on certain types of projects, crashing can actually lengthen a schedule because adding more people increases the number of communication channels in a non-linear manner. This is expressed by the formula (N2 – N) /2, where N is the number of people. When adding more people a project manager must put into place a well thought out division of labour. Fred Brooks, father of OS 360 at IBM put it best when he said “adding people to a late software project will only make it later.”
What are your tips for getting these projects right?
The key to success lies in the project manager’s ability to negotiate for the key resources that are going to be required to meet the schedule and making sure they are available when needed. Additionally, project managers need to practice “micro management” more than they otherwise would, or would want to, to make sure they know what the team is doing on a daily basis. Keeping a close eye on progress and problems is of paramount importance in order to meet the completion date.
How can you convince management to extend the timescale, especially when the date is arbitrary?
The best way to do this is by showing management how much more it will cost to do it by a date certain, as opposed to how much it will cost if planned based on available resources. The question to management is this: Is the time saved worth the cost? With money in seemingly short supply these days, an analysis like this can have a great impact.
You can also show the level of risk introduced by completing on the date that may not exist, or exist to a much lesser extent, if done according to a more realistic plan. Taken together, costs and risks can make a powerful argument for doing things rationally.
J. LeRoy Ward, PMP, PgMP, Executive Vice President, Product Strategy & Management, ESI International, brings more than 33 years of expertise in project and programme management to the refinement of ESI’s portfolio of learning programmes. He works closely with ESI clients worldwide to guide the assessment, implementation and reinforcement of knowledge and skills that provide for the effective measurement and successful adoption of learning programme objectives.
Related posts:
- Fixed date projects: more advice from the experts Last week we saw that PRINCE2 doesn’t really have much advice to offer the project manager stuck with delivering to a fixed date. I also...
- Fixed date projects are like weddings Some projects are already time-bound when you receive them, and while this way of planning is not the most controlled way to manage a project,...
- Inside PRINCE2: Fixed date projects Planning is an essential part of what project managers do, so you would expect there to be some mention of how to deal with fixed...
Subscribe via RSS
![[Valid RSS]](valid-rss.png "Validate my RSS feed")
18 people have left a comment on this post
As long as you can assess status reasonably well, simpler is better.
Here’s something I’ve done in the past that worked well though…a snippet from critical chain PM. (This was in a waterfall environment) Cut task estimates in half and move the extra time to the end. Usually the overall buffer can be reduced because you will target student syndrome and Parkinson’s law specifically here. The team needs to understand fully that they only have a 50/50 chance of finishing tasks on time and that it’s OK if they go over. It’s actually expected half the time. But, you as the PM start paying attention after they start eating into the buffer. At 60-70% you can get in there and aggressively help as needed.
There needs to be a culture shift to make this work though…people are conditioned to think of these as deadlines and so they will add extra buffer because they know you’ll chop half of the time away from them. Everyone needs to be on board.
Josh Nankivel
pmStudent.com
As mentioned fixed dates. You can only fly to Mars in a 3 week window every 3 1/2 years – be there or store the spacecraft at your cost for 3 1/2 more years.
Shutdown / Turnarounds on paper mills, power plants are similar. For the 30 days of effort, there may be a years worth of planning.
Chase Bank cut over on a Sunday for all the Washington Mutual accounts (10’s of millions) after the acquisition.
The notion of a fixed “done” date means actually “planning” the work and working the plan, with credible probabilistic margins for cost, scehdule, and techncial performance.
Any time someone says – we can’t possibly work within a fixed date, budget, or technical performance – I show them pictures hanging on the wall of Hubble, Phoenix, the last Mars lander, Rocky Flats ($11B worth of nuclear weapons plant removal), or I-25 light rail and interstate rebuild, massive software deliveries, etc. etc. etc.
What they really mean is – “I can’t figure out how to manage the project in the way the customer wants.”
A word from the field. In the last year of Rocky Flats – we had a “plan of the day.” The status was simple “did you complete yesterday what was on the “plan of the day?”
The POD was built the prior week – on Thursday. Prior to that the Plan of the Week (POW) was used.
As projects near the end the tolerance for risk approaches zero. The variability should be reducing as well. Early in the project the tolerance for risk is higher as is the variability. The ratio those two rarely changes.
No single point estimate can be correct. The variance for all estimates is needed before we can have a credible discussion of the impact of that estimate.
There are several presentations at
http://www.slideshare.net/galleman
on the topic of programmatic risk. Cost and Schedule estimating is the raw material for managing in the presence of risk.
With a single point estimate – say 48 days to build the gadget. Not knowing the variance on that estimate means you have a 50/50 change of making the date driven by that duration.
Cutting that estimate in half means you have a 0% chance of making it.
The outcome of the modeling processes described in the SlideShare materials, is it determine the confidence level of “completing on or before” a target date. Now this confidence is driven by the “credibilty” of two numbers:
1. The MOST LIKLEY duration – this is the duration that is “most likely” to appear if there are multiple estimates captured, or the actual work is done multiple times (not something that can be done in one-off development, but is possible is “re-use” projects.
2. The upper and lower bounds of the MOST LIKELY estimate. These are (depending on the approach) the 0% and 100% limits, or better the 10% and 90% limits. In English this means the activities will complete 90% of the time “on or before some date,” or 90% will take this duration or less. Same for the 10%. You can see the 0% and 100% are long tail estimates and not very credible.
Allowing anyone – management or not – to cut any estimate in the absence of the statistical analysis of the impact is suicide – or at best a self inflicted wound.
Projects that do this and project managers and their teams that allows this to happen in the absence of equivalent changes in scope and/or staffing need to look for work elsewhere.
Just an opinion of a grey beard Program Manager.
I hate to disappoint, but those slides are not theory. They are processes mandated by good project management principles – take another look at the Immutable Principles of Project. Violate one of those principles and your project is in jeopardy on day one.
Only in the informal IT world does it seem it is allowed to “swizzle” the numbers while the program is underway, or start work using someone else’s money with a less than credible cost and schedule estimate, or simply “behave badly” when calling the project “managed.”
There is no excuse – other than laziness and ineptitude – for not making every attempt possible to produce a credible estimate for the project, revise those estimates as the project progresses, and hold those making the estimates and those asking for the estimates accountable for their decisions.
It’s these ad hoc approaches to project management that are the source of most of the IT project failures when you read things like the Standish Report or the Capers Jones materials.
This is not science, this is core project management. The actions of projects you seem to be describing violate all the principles of good project management. To suggest otherwise is to ignore both those principles and the consequences of ignoring.
Here in the US that’s called a self inflicted wound.
8 Trackback(s)