Estimating Realistic Project Deadlines

Over at Thinking Faster, Jeffrey Phillips shared an article from The Economist about projects taking longer than expected and going overbudget as a result.  Jeffrey states that this is a result of "Sunny Side" thinking.  In other words, planning as if everything goes according to plan with no obstacles or setbacks.  Many project managers can be myopic in this area and not see the potential pot holes in the road ahead of their projects.  Being aware of these stumbling blocks and developing a system to accurately project deadlines can bring projects in on time and under budget.

From time to time, we all find ourselves responsible for projects at home as well as at the office.  David Allen defines a project as something that has more than one next action that needs to be done to achieve an outcome.  Items such as developing and publishing the department newsletter, developing a budget for the department, and painting the house fall into this category.

To begin developing an accurate time line for the project, one must consider all the next action steps required for its completion.  This can be done on the Project Task List that is advocated in the book To Do, Doing, Done! by G. Lynne Snead and Joyce Wycoff.  The large blank section of the form is for mind-mapping the project to get all the next actions visible.  When the mind-map is complete, the next actions are then placed in order by due date.  It also has a column to indicate the responsible party for the action for accountability and follow-up. 

Plan B

When developing this project plan, it is important to begin to think about the obstacles and possible delays that one may expect during the project, and build those into the mini-deadlines that are attached to each next action.  In fact, the creation of contingency plans for addressing those obstacles should automatically be developed.  One might never have to use them, but if an obstacle is hit, there is no time lost in switching to plan B.

A Project Duration Formula

Combine the awareness of obstacles and their need to have buffer time built into the project time line with a good project duration estimation formula and you'll begin to be more accurate in your ability to meet those project deadlines.  Snead and Wycoff provide a simple way to calculate a realistic duration for the project or for the individual next actions within it:

Te=(To+4Tm+Tp)/6

Key:

• Te = Realistic time estimate
• To = Most optimistic time estimate (the Sunny Side estimate with no setbacks)
• Tp = Most pessimistic time estimate (with every obstacle happening)
• Tm = Most probable time estimate (this makes you think realistically; some setbacks happen, others don't)

Let's say we have a project of developing a departmental newsletter.  The variables break down as follows:

• Tm = 14 days
• To = 10 days
• Tp = 30 days

The calculation would be:

Te = (10+(4X14)+30)/6

The best estimated duration for the project would be 16 days.

By applying both strategies of building in buffer time for obstacles and using a good project duration formula, consistency in estimating deadlines will develop.  Being known as someone whose projects come in on time and under budget is always a career helper and improves one's perceived competence.  Besides, it also makes us more confident in our abilities and that confidence helps to improve our performance, which boosts our confidence, which, again, elevates our performance.  As one can see, there is such a thing as an upward spiral.

Sources

• Thinking Faster:  Looking at the Sunny Side

Resources

• Download PROJECT TASK MAP.doc (57.5K)

Comments

[Charles Martin]

In my experience at one software company I worked for, the deadline was defined first by what was promised to the customer, then everything was scheduled accordingly (regardless of potential potholes in the road). I honestly don't remember once making a deadline (but being blamed for it missing due to being the last person to touch the project in spite of the 10 others before me who took too long as well).

Thus it becomes important to know when a project should be scrapped, delayed or modified. Scrapped because the deadline exceeds a barrier that cannot be missed no matter what (i.e., making the last shipment of goods before a trade embargo goes into effect); delayed because timing may be more favorable at a later date (such as having a particular movie ready in time for Christmas being postponed to late Spring to catch the early Summer crowds... which has happened); modified to throw out parts of the project that may be done at a later time or were not really necessary to the core project's completion (for example, leaving out the wireless access point and proxy server for a new company's network as it can be added at a later date, but is not crucial to overall network connectivity by opening day).

Rarely, though, are any of these accepted. The usual method for meeting the deadline is increasing the workload on those working on the project. That is always the easiest decision to make with the greatest negative impact on morale. Yet it happens over and over. We should be more open to making one of the other choices so that quality is not impaired (and morale is not crushed).

[Bert]

Charles--

The formula, rather than determining an exact finishing date, actually determines project duration. I can take an assigned deadline and use this formula to determine the project's duration to forecast whether the deadline is realistic. After doing what I advocate in this post, I've often gone back and renegotiated a deadline based on my data. This is possible because many assigned deadlines are actually soft ones, which are assigned days to weeks prior to the client's deadline. Soft deadlines are but one way for supervisors to account for obstacles that they think subordinates may overlook or not take seriously. They are usually days to weeks prior to the client's deadlines. Unfortunately, they increase the workload on those working on the project for no good reason as collaborative planning or competent supervisory follow-up can accomlish the same thing. It is a shame that those working on the project often don't have a say in a deadline unless someone approaches management to renegotiate...if, as you say, there are no non-negotiable barriers.

[Hashim]

the more people involves, the more unpredicatable a project becomes, and that makes it hard to even give estimates to calculate

[Jennifer]

I work at a PR/Adv firm and we are always trying to find the best way to size down a project. What I've found is that no matter how many nifty charts we produce, it always comes down to the individual person. I work under someone who has no concept of time management and therefore often extends deadlines at her whim. Its very annoying and hard to manage. Is there a chart for that? ;)

[foobario]

As an electrical engineer I find that I need to modify your formula:

Te = (To + 4Tm + Tp) * (Nm! / 6)

Where Nm! = the factorial of the number of midlevel managers involved.

[danny]

Jennifer there is no chart for anyone working in PR/Advertising, because charts "don't deal with real humans". As a more workable alternative, I recommend increasing your ego.

[Bert]

As foobario has noted, although I feel his modification to the formula is not necessary, the additional number of people involved in a project would cause me to increase my estimate of time in each of the three variables. It's a fact that when you deal with people, more time is required. Temporally challenged team members and supervisors who are involved in the project require even more time to be added into the calculation.

[Jemal]

The fact that the formula above is able to masquerade as science is truly amazing. Let's read what it actually says:

Take your estimate, give it a heavy weighting, and then diverge by the difference of your best and worst case estimates, thereby giving you almost exactly what your estimate was in the first place.

That's science? Take your guess and pad it a little? Feh.

More here: http://www.tanglebones.com/articles/2004/10/07/project-management

[Charles Martin]

Bert, in reference to Jemal's downplay of this method, do you have any examples of where you have used this formula and how the resulting estimate compared to your original (heavy-weighted) estimate and the actual completion date? It would seem that the only way of proving the use of this method would be to show how well it "corrects" our own estimate versus reality.

[Bert]

Charles --

I use this formula (often in my head if the project is simple) and find myself in the ball park.

A specific example will not satisfy Jemal. According to his blog, he leans heavily on hunches rather than systems that others have used and found to be effective. When he discussed this formula on his blog, another commenter called him on "picking out those numbers to get the result you want."

There is an old saying that says, "Never wrestle with a pig. The pig likes it and all you get is dirty." His comment doesn't rate an example, as he would simply say that I was minpulating the data to arrive at a pre-determined result. Charles, if you'd like to hear about a project, send me an email and I'll share.