Despite the obvious advantages of approaches like Scrum, deadlines are a fact of life in the business world. There are what I consider “artificial deadlines” and “real” deadlines. If a sales person and a client agree, in a vacuum, that Feature X needs to be done by March 27th, that is probably an artificial deadline. Where did this date come from? Is it even possible for Feature X to be done at all, let alone in this time frame? “Real” deadlines involve some real-world event happening which is going to happen whether you’re ready to take advantage of it or not. Silverlight must be able to stream video before the Olympics. The industry trade show happens on this certain date. We will run out of operating cash on this date. These are real world events that present a risk or opportunity; they will come and go even if Feature X never happens. I know of no hard and fast rules for separating real deadlines from artificial ones, but there’s often a certain “taste” to the artificial ones.
Regardless of the real-ness of a deadline, committing to one should not be taken lightly. Even if there is no real business consequence for missing a date, it affects your credibility. Consultants who lose credibility have a hard time earning long term success. Employees who lose credibility get “tuned out” by their co workers over time. Products that lose credibility sit on the shelf/lot/floor. Companies who lose credibility have a hard time earning and keeping customers.
Nonetheless, sometimes a deadline that you’ve agreed to simply cannot be met for any number of reasons. This is often OK, but I try (not always successfully) to follow one simple rule I learned 9 years ago from a much more senior consultant:
You can only push a deadline out by an amount of time equal to {Deadline} minus {Today}.
For example: if the deadline is in a month I could conceivably push it out another month without looking like a moron. If the deadline is in a week I could ask for another week. If the deadline is 2 days I could ask for two more days, or partially deliver, or pull some heroic hours and get it done anyway.
This isn’t an arbitrary statement, we can see how this makes sense. Consider a situation where the deadline is 5 business days away and you ask for two more months. Did you leave the biggest risk or uncertainty for last? How intelligent was that? Did you do a poor job of discovering what needed to be done? Did you over-promise on how quickly you could deliver a solution? Did you agree to various scope changes without any concession on timeline?
To put it differently, we can propose a way to calculate the magnitude of the planning/managing/over-committing/qualifying mistake.
let maxPushbackDays = deadlineDate – today; // give us a number of days
let pushbackDaysRequested = someNumber; //How much more time are we actually asking for?
let mistakeQuotient = pushbackDaysRequested / maxPushbackDays; //Give us a quotient
Here’s some simple math that gives us an arbitrary number. If my maximum sensible amount of time I can postpone delivery is precisely equal to what I ask for, I get a “mistake quotient” of 1.0. If something is due in two days and I ask for two more business weeks, I get a much higher mistake quotient of 5.0. If something is due in 10 business days and I ask for 3 more days, I get a mistake quotient of .3. Missing a deadline is never good, but it may help to think about things in a quantitative manor in order to plan what you’re going to say and how you’re going to say it. At an MQ of .3 you might only need to say “If you look at it this way, it’s really not that bad, we’ve discovered this misconception early enough to correct scope and deadline now…” whereas at 5.0 you might need to have a very compelling story indeed.
Of course, with “real” deadlines it’s different. If the Olympics come and go and you didn’t take advantage of the opportunity, what then?
Back to basics: If you’re going to be late, it’s best to let it be known as soon as possible so there’s time to react.
Subscribe