A target date... Focus on WHAT then WHEN

A target date isn't when it is going to happen, it is when you want it to happen.

Often confused, a Target Date for an important milestone is a deadline at which time one expects to achieve a result, however a Target Date may not be when the milestone is actually going to finish.

Example of a target (inverted triangle) and its associated project milestone (blue diamond)

"We must release the product on 31 August, in order to..."But just because this is when we want it, does not mean that, by default, this is when it will be done regardless of the number of times we "hold hands and chant the date!"

The difference between the expected finish (i.e. target) and the estimated finish (i.e. the real schedule) is called the "gap." Many times this gap is not known or is not acknowledged (if known) in order to avoid dealing with the reality of not finishing on time."We have an aggressive schedule and I expect we will rise to the challenge and succeed, blah, blah, blah...and so on."

The project end date should be generated from the critical path to the last milestone, which is derived from durations and precedence relationships between tasks that lead to the milestone. While the target date, on the other hand, is a fixed point in time -- or deadline on which something is due. Failure to recognize the gap between deadline and reality is one reason for project failure, in that expectations are incorrectly set from day one.

One root cause of this problem is mixing up the "when"with the "what"parts of planning. By this I mean confusingwork content with work timing. For example, teams deal with when they want something and then define what they want/can deliver at that time.

Rather, the best practice approach is different; define whatis needed based on project objectives and doneness criteria, articulate this in a work-breakdown-structure, define how long each task should take, and then build a work flow of task dependencies. Then we deal with whenit will be delivered.

When teams address the "when" question first, they tend to compromise the "what" or how they are going to achieve it. You end up with a schedule that "fits" the time frame and will always be late. Focus on defining WHAT and then WHEN; you will identify the gap early, when there is time to close it.

Best practices work the other way around from the common view; WHAT, then WHEN, and then deal with the GAP. Conversely, we often see teams deal with WHEN, the WHAT is confused or unclear, and the GAP is never addressed...until the project slips in the future, when it is a surprise.