Types of dates

Just a brief note on the types of dates I have to deal with in software estimation.

Start date: Actually not as simple as it sounds. If you estimate something will take ten days, which ten days? I have seen a lot of arguing about when projects actually start.

Earliest date by which it can't be proven that it won't be done: DeMarco claims this is the easiest date to estimate, and the one most commonly used in scheduling. Frightening stuff.

Estimated completion date: Could be the product of some kind of parametric/statisical estimation, or engineered guess, etc. I think the pyschological effects of the estimated date are often underestimated. If the date seems unreasonably short or long, the behavior of the team will be affected. Often it is a huge mistake to express this as a single day, when the correct way of expressing the statistical truth is a probability range. Whenever I am asked for a 100% date, "when will we be guaranteed to get this set of scope delivered?", I just try to say something funny. The 100% date is meaningless, when so many projects are not completed.

Target or Goal Date: Usually a meaningless date created by management to inspire hard work, particularly if the previously mentioned estimated date is not good enough. Or, the date by which they will get whatever is done at that point in time. If you are going to attempt that strategy, you should begin doing timeboxed development from the start, so people know what to expect.

Date by which the project will be cancelled: Should be approximately equal to the day before the last date on which the project will still be able to have return on future investment- more ROFI than a replacement would (even if net ROI would be negative.) I like to ask the stakeholders for this one- and how many times have I heard that a crucial project that we are being asked to evaluate "can't be cancelled"? That kind of thinking is the kind of thinking that gets crucial projects cancelled!

Feature complete: The date by which the software has all of the features, but none of them actually work yet.

Actual completion date: Seldom reached. In development, is one ever really done? Even shrink-wrapped and shipped software usually has a patch or two ready to go before the first product hits the shelf.

This is why I prefer fixed increment, timeboxed development. It is so much easier to deal with scope slippages than time slippages. Scope estimation is the only way to go for the kind of projects I deal with.