Project Deadlines and Target Dates:
5 Guidelines for Avoiding Disaster
© Conrad Weisert, Information Disciplines, Inc., Chicago
1 October, 1999

NOTE: This document may be circulated or quoted from freely, as long as the copyright credit is included.

I got a call this week from a prospective client, asking if I'm available to prepare a project plan and then help manage an important project. During our conversation he mentioned that the project has "a June 1 deadline".

There was nothing particularly unusual about that, but there should be. In that one sentence the caller revealed a strong likelihood that:

To be sure I knew nothing about the nature of the project or how the June 1 date had been arrived at. But I understood the statement in the context of long experience with projects that were introduced in the same way.

If no project plan exists, how can we know a deadline? And is it really a deadline or is it a target date?

Here are a few guidelines on avoiding deadline-imposed project fiascos.

1. Distinguish between deadline and target date

Most "deadlines" are really target dates. The difference lies in what happens if the date is not met:

2. Derive target dates rationally

A target date is a result of a detailed project plan that makes visible the work that has to be done. The critical path through a network of tasks determines the earliest possible project completion date, assuming unlimited resources. The actual target date may be later, depending upon the project's priority and the availability of people and other resources.

If that derived target date is disappointing or unacceptable, then we have three choices:

  1. We can reduce the scope of the project.
  2. We can defer certain parts of it to a follow-on (release 2) project.
  3. We can accept the disappointing target date and strongly support the project team in meeting that target.

On the other hand there are two things we must never do:

  1. We must never pressure the project planner to massage the estimates to fit a predetermined completion date. (See "The Burden of Proof in Project Estimating".)
  2. We must never pressure the project team to work harder in order to meet what everyone views as an impossible commitment.

While either of those approaches may give the temporary illusion of a tough-minded no-nonsense, results-oriented manager, in the end they're a sure recipe for a painful project fiasco. (See Ed Yourdon's book Death March reviewed on this web site.)

That doesn't mean, of course, that an organization shouldn't ever go all out to achieve some extremely ambitious and marginally unrealistic goal. When the rewards justify it, there's nothing wrong with chartering a team to work on a "best efforts" basis. When a super-competent team has high esprit de corps and doesn't fear the consequences of failure, they may pull off the occasional miracle. Then:

3. Distinguish between urgency and priority

Effective immediately
will be given
(no exceptions)

That sign was posted in the computer room of a large corporation in the 1960's in a (presumably) humorous attempt to get the operators to work faster and more carefully. Of course, everyone knows that priority is relative. To raise the priority of one job or project is implicitly to lower the priorities of all the others.

Without abusing the concept of priority, however, we often want to designate a project's degree of importance. When the benefits of success are huge or the penalties for failure are dire, we designate the project as "urgent" or "critical". Such a designation may help the project to get a higher priority or to tap otherwise unavailable funds or manpower. Such a designation, however, can never compress the critical path or increase the number of hours in a day.

4. Avoid arbitrary, self-imposed target dates

Whether it's a target date or a true deadline, it has only two legitimate sources: the rational result of a project plan or some external event over which we have no control (e.g. Christmas). I'm sometimes surprised, however, to discover that a target date arose entirely arbitrarily out of some management edict unrelated to any real-world event.

In one case, we later found out that a manager two levels up had a goal on his own annual objectives list that turned into a project "deadline". In another, a Theory-X manager confided: "You have to keep the pressure on or they won't work hard." Needless to say, morale in those organizations couldn't get any lower, and the projects failed anyway.

5. Never reward meeting a deadline

A successful project is one that:

  1. meets agreed-upon objectives
  2. is completed by an agreed-upon target date
  3. is completed within an agreed-upon budget
  4. complies with applicable standards and constraints

In a high-pressure, super-urgent project, one of those criteria is a lot more visible and measurable than the other three. In a futile attempt to spur the project team, misguided management has been known to offer a bonus either to the project manager or to the whole project team for meeting the target date. What's the likely result?

Not surprisingly, such an incentive often leads to serious undermining of the other three criteria and reckless risk taking. Among the common harmful responses are these two:

Of course, successful project teams should be rewarded, but not in a way that gives incentives to shoddy quality and irresponsible risk taking.

1 A second meaning of deadline arises in legal language, but that doesn't concern project managers in organizations. We accept the United States Internal Revenue Service's designation of "filing deadlines".

Return to IDI Home Page