If you’ve been in a web or software development group you’ve probably experienced what is commonly referred to as crunch-time.  Crunch-time is when the deadline is quickly approaching for a project and everyone has to put in extra hours at night or weekends to get the project completed.

I’ve worked on numerous projects where the seems to happen and also numerous others where it wasn’t required.  So why is there a need for crunch time? It is simply poor time estimation , over ambitious goals, lack of resources, inflexible deadlines? Those are certainly factors.

Deadlines

Often development deadlines are set to coincide with marketing initiatives like  trade shows or media spends.  Changing these deadlines is often not feasible (e.g. We can’t push SXSWi back a week to meet a goal), expensive (changing when a promotion is going to run), or undesirable (missed opportunities).

Ambitious Goals

If you hear the executive-speak about a project that includes the terms: Aggressive, Ambitious, High-Risk or Accelerated the project is a good candidate for crunch time.  The reasons projects become high-risk are varied but, common examples include: large feature sets, bleeding edge technology choices, un-finalized requirements and fluffy goals.

Lack of Resources

Another common factor in crunch-time projects is lack of resources. This is especially common in our current tech climate where rock star development resources are scarce.  True it can  be difficult to find the right devs but, often the realization that additional  resources are needed come to late in the process.  Then the common adage is that late in the game new devs can not make an impact so it’s up to the current development staff to make up the difference with additional work hours.

Task Estimation

Most developers even leads are simply not great at determining level of effort on large projects.  Smaller projects and sprints are easier to estimate and dev groups can increase their estimating skills over time.  Trying to do this for large projects that will take many months is a different story.   It’s hard for many reasons including:  many unknowns in the system, many components and interactions, many developer skill levels, etc…   What is usually produced is a best guess estimate  effort required and then a buffer multiplier is used to produce the man hours required.

The Positive Side

One thing I can say positive about the crunch-times I’ve been involved with is that they can be tremendous team-building exercises.  There is something about working late into the night, focusing on getting the last few bugs outs, drinking a beer and general comrade help to build strong dev groups.  I have many close friends to this day that I’ve gone through crunch-times and death-marches with.  Although, I wouldn’t necessarily want to go through those events again they obviously have some merit.

What to do?

So can anything be done to reduce or eliminate crunch-time?  Certainly organizations should strive to improve their development processes and planning and that’s a good step.  Moving to scrum or other agile processes can certainly help also.  But, in the end I think there will usually be crunch-times for most large projects because there simply isn’t an economic force to reduce it especially in organizations that use few outside contractors.  It’s also become the status quo and is often expected to happen.

In the management positions I’ve held I always tried to avoid crunch-time whenever possible and that is probably a good rule to go by.  Use them only when absolutely necessary!  If you have too many death marches you are bound to loose your star developers and any team building you’ve accomplished.

What’s your experience?