Deadlines and Commitments
While some projects absolutely must be high quality, and others might be physically constrained by size, there is one dimension that is clearly the most prominent point of discussion on projects of all shapes and sizes: When must it be finished?
Deadlines are the lifeblood (or scourge, depending on your perspective) of project commitments. The cost of the project is often blurred, intentionally or not, the overall risk is rarely analyzed. While most people will suggest that quality is most important to them, almost nobody defines it in a measurable form. Even scope is fuzzy (or ever-growing) on most projects.
A date on the calendar, though, is the clearest, most precisely defined constraint on almost every project.
Regardless of it’s credibility. Regardless if it is the most important consideration.
There are some projects where a delivery date really does make sense. Y2K is a great example of this, even if the fallout from not quite completing everything we had hoped was not nearly as disastrous as many of the pundits were suggesting. If we are building a system to deal with particular legislation such as tax laws, or racing to meet a scheduled wedding or conference, or trying to catch our cruise ship before it departs, we had better be on time, or the ship will be setting sail without us. We have a real deadline.
Often though, projects will have a date that is an agreement between parties, and not much more. This may be based on some understanding of the work to be done, and may or may not include the understanding that some things might slip and jeopardize that date. If that date arrives and the project is not completed, a few things could happen. A new date might be set based on current expectations, and the clock starts again. There might be some sort of penalty associated with the delay, while in some sectors there is often an expectation that these dates often slip, and “that’s just the way it is”.
So these things aren’t quite deadlines, they’re more like commitments. Commitments with a wide range of committedness, which is not often discussed beforehand.
Other terms for commitments that help clarify how real they are: target, hope, intent, wild-assed guess, constraint, mandate, agreed-upon convenience, or the date that I hit on the dart board with my eyes closed.
Unfortunately, with the date front-and-center on most projects, that becomes the basis of deciding whether or not we were successful, the stick by which we are measured. When we start our project by defining the end date, we often develop our schedules by fitting everything we can think of into that bag of days, regardless of how well it fits. On many projects, as the date approaches there is a sickening feeling that there is no way the date will be met. Eventually, we give in and set a new date, and the dance starts all over again.
If we do this several times, we are actually using successive approximation, and eventually we’ll be pretty close to our target. We’ll conveniently forget that it’s our fifth attempt at targeting, and that our latest date is easily twice as far out as our original one. We’ll also fail to see that all this time pressure has forced us to cut corners and make mistakes, causing much of the slippage that we end up with. Then we’ll congratulate ourselves for being such good estimators.
There are also times when we are given a date, and we manage to stick with that date. On many projects, even if it has been stated that something else is most critical (such as cost or quality), the date is the constraint that is most discussed, and is often “cast in stone”. Working to that date above all other forms of constraint means that those others may suffer unless there is careful, ongoing coordination by the whole team (and stakeholders) to ensure the balance is most effective.
I was working on a project recently where it was suggested that quality was the most important element, but not expressed in any measurable way. The delivery date was firm, despite there being clear malleability based on similar projects in the past. Given a choice of working to that date or debating the relative merits of the different constraints in search of an extension, I chose the former. What was delivered was the best possible quality that could be delivered within that time constraint, a far cry from the best possible quality overall.
When talking about time constraints, be careful what you ask for.
A few years ago, I put out an entry about why I write, and I have had opportunity to revisit that over the past year. You may have noticed that this blog is not quite as weekly as it once was: while a weekly constraint was important up front to get me comfortable with writing, it was sometimes difficult to maintain. What started as a weekly ‘Sunday morning exercise’ became ‘get one out sometime during each week’. Eventually it was ‘average 52 of these things a year’, and even that fell off the rails earlier this year as I was just too busy writing other things to get blog entries in.
On reflecting, I think that the deadlines and commitments I had set for myself are no longer necessary, particularly if they were the primary constraint for the work. Instead, I’ll blog when I think I have something interesting or important to say, schedule be damned. As it turns out, I’m knocking off my third in about a week, but I’m sure there will be months ahead where the muse does not strike. All fine with me – I have learned in the past year to reconcile the different constraints that may affect us, and be honest about prioritizing them in a useful manner.
How have the deadlines and commitments you have worked to in the past affected your work? Are there any you are working on right now that might be more constructively discussed in the context of other important drivers, such as quality? – JB