Software engineers always seem to resist talking about dates. Estimating is hard, but it is also dangerous – sometimes you make an estimate and the next thing you know it’s a deadline that has consequences if missed! But you never committed to anything! What happened?
People are imprecise when they talk about dates, and interpret things to meet their needs. A while ago I learned1 about a model of four kinds of dates which can help avoid misinterpretations. I’ve used it for a long time and it’s helped clear up a bunch of date-related confusion.
The four kinds of dates
The four kinds of dates are estimates, targets, soft deadlines, and hard deadlines.
An estimate is an educated guess about how long something will take.
A target is a statement of desire that something should be done by a particular date.
A deadline is a commitment which, if missed, has consequences. Missing a soft deadline has internal impact, and the consequences are usually only felt within the organization. Missing a soft deadline might prevent another team from moving forward, or interfere with next quarter’s planning, or prevent reaching a monthly sales target.
Missing a hard deadline has significant, external, and usually financial impact: a contractual penalty being invoked, for instance, or going out of compliance and being unable to do business.
Most project date confusion in organizations happens when two parts of the organization – whether people, teams, or entire business units – are talking about “the date” without specifying the kind of date, and each means a different kind of date.
Estimates and targets are not commitments. An estimate is saying “We think it will take this long, but there is uncertainty about how long it will take”. A target is saying “We would like to be done by this date, but there is uncertainty about whether that’s possible.”
Soft and hard deadlines, on the other hand, are commitments. Sometimes they don’t feel like commitments because someone else has handed you a date, but somehow your organization is still committed to that date.
(Note that I don’t mention who made the commitment. When talking about dates what matters is understanding what kind of date the date is. If someone else is committing a team to a particular date without their involvement, that could be a problem, but it’s not this problem.)
Soft and hard deadlines are two points on either end of a spectrum, but separating internal and external consequences has been a useful distinction to make. I’m hesitant to describe soft deadlines as being more flexible. Deadlines can often be renegotiated, but they’re still deadlines. What matters is the impact of missing the deadline.
The value of being explicit
When I encounter date confusion I often explain this model and then asking them what kind of date is being discussed. Mind you, it doesn’t always clear up confusion in the way that makes things easier. It might turn out that what you thought was a target is really a soft deadline, or that what you understood as an estimate was used to commit to a hard deadline. But the first step to sorting out date confusion is for those involved to understand what everyone means.
Once you can spot the confusion you can start working towards shared understanding. As more and more people in your organization learn the model, the potential for misunderstandings will decrease as well.
I didn’t come up with this model. I don’t know where I learned it from. If you recognize it I’d love to credit whoever came up with it! I did learn that Steve McConnell distinguished between estimates, targets and commitments in Software Estimation but didn’t distinguish between hard and soft deadlines. ↩︎