What’s in a deadline, really?

As I sit here in court, waiting patiently to fight a cell phone ticket that I am clearly guilty of, I got the opportunity to read over David Hansson’s recent post on deadlines. To recap, he stated that we should stop holding ourselves accountable to unrealistic deadlines, or better put, to deadlines that force us to sacrifice quality, testing or hours. This isn’t a new thought for any seasoned developer. While we dread the idea of slaving over late hours and patch-and-go design methodologies, we seem to constantly practice the former, and unfortunately the ladder.

While, I agree that we shouldn’t be pigeon-holing ourselves into tight deadlines, the truth is, most of the time, doing so will land you the contract, and refusing it will result in the client giving it to one of countless other developers who will gladly slave to meet that impossible deadline. So, how does one find a homeostasis where both the client and the developer are mutually happy with the quality of work and the amount of time it takes to build it?

For most development companies, three basic questions fuel the work we do, to a certain extent:

  • What do you need done?
  • How much can you can pay to get it done?
  • When do you need it done by?

Armed with these 3 answers, you can derive a general synopsis of the life-cycle of a project. For a certain type of client, the first two questions are givens: the client needs these features and they only have a certain amount budgeted to get it done. Clients generally come to you with specific demands that they typically have good reasons for (and obviously, we will intervene if our experience tells us the demands need tailoring) As for budget, that’s always a touchy subject: we are resolute in what our labor costs will be, but sometimes, clients won’t budge and you still want to help. As a result, time may be your ultimate leverage when you gain the knowledge of the different ways time can factor in to a project.

Why is your deadline?

Steve Walker and myself spend a great deal of time debating certain points of our industry in hopes of carving out a strategy we refer to as “Client-Driven Development.” The idea is to shift the paradigm of many of the assumed truths of developing software for clients. One of the facets that interests me is the concept of a deadline. To explain, here are a couple of examples.

The arbitrary deadline

Scenario: The last web company I worked for believed in the arbitrary deadline as a means to engage their employees. A new idea would be conceived by the CEO and its deadline was always “the last Friday of the month,” regardless of rational, time estimate to develop the feature, or what day of the month it currently is.

Result: The net result was a company divided by people that knew the deadline was bullshit so they lost passion for the project (and eventually the company) and people that worked feverishly to meet this deadlines because “he’s the boss.”

The open-ended deadline

Scenario: Many times, you will work with a client who “doesn’t have a deadline”. The reasons why they do not vary, but many times I feel the client thinks they are being convenient by being very open-ended.

Result: The result of offering an open-ended deadline can have two general consequences. The first is that the developer may afford the client the ability to either negotiate the features or the budget. The second is that the developer will hold you to their estimate, but the project will never get done. You all know about that project that you have right now that started over six months ago but either you haven’t finished it yet because there is no client pressure, or the client has finished providing the content or approvals, also because there is no client pressure.

Note: having an open deadline is like getting in shape without weighing yourself first: sure, you may tell yourself “the amount of weight doesn’t matter, just as long as I look good,” and you still might even loose the weight. However, knowing your starting point and agreeing on the end point is the catalyst for realistic motivation.

Event Inspired Deadline

Scenario: A very common situation is for a client to come to you and say they need a project launched by a certain date because of a certain upcoming event, where ‘event’ is paralleled by a significant date to the client’s demographic. Some examples are trade shows, monthly newsletters, cultural events (ex. launching a red version of a site by Valentine’s day), or in tandem with a new product release, to name a few.

Result: As a whole, I find I am more accepting of these deadlines because they have a black and white reason for their necessity. The issue developers have with these deadlines is that, often times, they are given without much time to develop. “We have a trade show in 2 days and we want the this new section to go live by then,” or even more painful “We have a trade show in 2 months and we want this new section to go live by then,” and then you don’t get the content for it until two days before the deadline.

Conclusion

My suggestion to you is not to try to treat the deadline game in a one-size-fits-all manner, because all clients and projects are different. It’s just not realistic to think that every client will agree to the one way you are going to address deadlines. I have found it much more effective to analyze what type of deadline the client has and see how I can use that as an advantage against the other main aspects of the project. Remember that while the three points of a project – features, budget, and time – may always form a triangle, there are different types of triangles based on how you handle each vertex.

Sidenote: For those curious, I got the ticket thrown out.

Joey Naylor: Dad, why is the American government the best government?
Nick Naylor: Because of our endless appeals system.

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Twitter

Comment | Trackback


Lecture

One Response to “What’s in a deadline, really?”

  1. Stephen Walker Says:

    February 8th, 2010 at 12:12 pm

    Great overview of deadlines.

    I would add that the further out the deadline, the harder it is to hit. The future is ultimately unpredictable so breaking up longer projects into milestones, hitting the unknowns first, helps to keep the project on track or at least give early feedback that something needs to be adjusted.

    Open ended deadlines are a real problem because, as DHH says, without constraints you can spend unlimited resources on something without producing what is actually required. Also, projects grow to fill the available time.

    There are also different types of developers. What type of deadline you have might effect what type of developer you put on a project. The types correlate to the “satisficer” and “maximizer” decision making strategies (obviously this is only one classification of a developer). If you have a tight deadline or event driven deadline, the satificer may be able to get the project done on time, where the maximizer may struggle trying to make optimal design decisions.

    Congrats on the ticket!

Leave a Reply