More About Deadlines | October 20, 2007
My deadlines post a few days ago seemed to spark a bit of a discussion, so I thought I’d write a quick follow-up. There were two main reasons why I wrote the original post. Firstly, I really dislike pronouncements from influential bloggers that are said as fact. Especially when the issues are a little more nuanced and require discussion. Secondly, I’ve always had a mild interest in Taosism, and get a little irritated by articles stating the Tao of “this-n-that” in a very prescriptive and un-taoist way. In fact, I think the latter was the main driving force behind the article.
From the tone of the previous paragraph, you could infer that I’ve “got issues” with Mr Rutledge. However I really like Andy and agree with the vast majority of his arguments. In fact I’m stoked that he’ll be attending SXSW for the first time this year, and look forward to sharing a pint and having a chat. My main criticisms are purely philosophical.
I believe that deadlines are an extremely important tool in any project. They help set expectations and provide a goal everybody can strive towards. In a perfect world no deadline would be missed and every project would be delivered on time. The waterfall style of project management attempts to replicate this perfect world by tightly controlling every step of the process. However experience shows us that projects morph over time and what was true at the start of a project, may not be true 6 months down the line. The rigidity of the “waterfall” process binds our hands and doesn’t provide the flexibility modern design projects need.
This is why agile and iterative models are gaining favour in our industry. Rather than having tightly scripted and immovable deadlines, each part of the process informs the next. Come up with a cool new feature or a better way to do something? Rather than leave this out to reach an arbitrary deadline, simply add an extra sprint. It may affect the project deadline, but the project will be better for it.
I thought I’d talk about a few, real world examples where deadlines work, and a few examples where missing deadlines has actually been a positive thing.
At Clearleft we used to spend ages working on the initial design concept, before showing it to our clients. However the time and effort we invested meant that we became very attached to the design and it proved more difficult to change tack. We realised that the majority of this time was spent obsessing over the details, so came up with the idea of a “one-day design concept”. This self imposed deadline allows us to focus on the heart of the concept without worrying about the details. It also creates a sense of urgency in which creativity can flourish.
The same is true of many other deadlines, from book reports to conference presentations. As the deadline nears, you being to refocus your attention away from less urgent issues and towards the task at hand. You may have known about the deadline for months, but the impending deadline provided you with a level of clarity that you wouldn’t have otherwise had. I’m sure we’ve all experienced that rush of creativity the night before a fixed deadline. As such, deadlines can be a powerful tool.
The problem is not to confuse the utility of a deadline with the deadline itself. Or to put it another way, rules are meant to be broken–just as long as the value in breaking the rule is significantly greater than the consequences. I’ll give you an example. We had a long meeting the other day, so in order to focus attention and avoid spinning off into irrelevant discussions, each section had a tightly controlled time limit. We stuck to these deadlines vigourously throughout the day, until we hit a particularly tricky discussion point. We could have stuck to the timetable and brushed the issue under the carpet. Instead we realised the importance of getting the issue resolved far outweighed the extra time that was required, so finished half an hour late.
You may be thinking that self imposed time deadlines are a lot different from project deadlines, but in most cases they’re not. They are just on a larger scale. We were working on a project recently and halfway through the wireframing process, we came up with a fantastically innovative idea. Implementing this idea required significantly reworking the wireframes, and creating visuals to explain the concept. The extra time meant we’d miss the wireframe deadline and push the project back a week. However the value in missing the deadline far outweighed the potential consequences, so we went ahead and made the changes.
Deadlines can be an extremely useful tool, but we need to remember that in most cases it’s the project that drives the deadlines, and not the deadlines driving the project.
Posted at October 20, 2007 12:39 PM