An approach on deadlines
What is a deadline?
A deadline is the date expected to complete a task –a explicit constraint (time).
Before reading Basecamp's thoughts about constraints in Getting real I saw them as something negative or to worry about, but then I realized they are a tip to focus on what actually matters.
Deadlines usually orbit the idea of maximizing the outcome from the resources available in a usually short period of time. However, they are only one of the attributes that define a task. And those attributes are heavily correlated; you can't tweak one without affecting the others. I like to relay on the SMART criteria to define a task and its attributes. According to it, a task must be:
- Specific. Unambiguously define the task at hand.
- Measurable. Quantify improvement.
- Assignable. Who will do it.
- Realistic. Given available resources.
- Time-related. When can it be achieved.
How to set a deadline?
There are three common ways to set a deadline.
Do the maths
The spec (what is going to be done) can take more or less time to develop; how long will we measure the results; take into consideration the assignee's skills; and be realistic about all the criterias.
The balanced agreement
Usually stakeholders are not tech experts and tend to ask too much. If the assignee (or her team) realizes the task objectives are not realistic some rebalance must be done: lighten the spec; put off the deadline; change the assignee from a junior to a senior.
The hard deadline
The deadline is set by the stakeholder. They will be met depending on the stakeholder's experience and knowledge on the work needed to complete the task. I've worked for people who set hard deadlines but knowing the task was realistic (I admit that with some overtime involved) and for people who didn't know it was not. In this later case, the team often warned of the impossible undertaking the deadline meant and suggested a balanced agreement. Again, sometimes the stakeholder agreed, sometimes not. When the the stakeholder doesn't care, the only actual outcome of the task/project is stress and frustration; of course the deadline is eventually put off.
Are deadlines effective?
That's a funny question when you remember that a deadline is just part of a group of criteria. You can measure the effectiveness of tasks; deadlines can be met.
I think deadlines should be taken seriously but with a grain of salt, used as a mere reference in order to organize several tasks and resources.
The problem comes from stakeholders who have the bias of thinking of the deadline as the objective itself; something like "we need to launch no matter what". OK, but at what cost? That's why, again, deadlines are eventually put off –because the task doesn't meet the minimum standard of quality.
How can we improve this?
First of all, there's a problem of semantics. Language can shape the way we think. We should start thinking in 'estimate dates' which imply uncertainty, flexibility and 'open to surprises'; and ditch the word 'deadline' itself from our vocabulary for what it implies.
Stakeholders need to dump the hard deadline way and accept that 'estimate dates' are just that, estimates. They can flow in time. They need to accept the given 'estimate date' if thet agree to the specified requirements, the expected measureable ocutcomes, trust their assignees and know it is realistic given the context. If not, they need to reach an agreement with the team.
Small tasks are always easier to measure than big ones; so split tasks as much as you can.
Remember to add uncertain time for interruptions and urgent tasks to the estimates.
And, if money is not an issue, you can follow the way John Carmack sets launch dates: "Done when it's done."