A Recipe for Execution in Crunch Time

by · Published · Updated

Print PDF eBook

For many small software teams with loose (or non-existent) project management, “crunch time” usually leads to the unraveling of the project to some degree and inevitable crisis management.

In most of these cases, crunch time is the result of:

  1. Poor initial scoping – putting too much work into too little time or insufficient resource load
  2. Poor project methodology – poor tracking of estimates to reality, no mechanism of measuring progress
  3. Bad luck (or good luck?) – team is spread too thin due to unforeseen circumstances like a critical bug or landing a big contract with a new customer
  4. Poor communication and setting of customer expectations – if your team can’t deliver, always communicate reality (assuming you know it) as early as possible so that there is no surprise and all parties can make sound, rational decisions.

So what do you do once you find yourself in crunch time, up against a deadline?  My recipe is simple:

  1. Find the gap – get the stakeholders together and identify the functional gap that remains.  The BA’s, the SME’s, the developers, the testers, maybe the customer — get everyone together in room (or conference call) and identify the work that remains.  There must be agreement so that nothing is left un-considered.
  2. Estimate the gap – once the gap is identified, the next job is to estimate how much work remains in the functional gap.  Again, all stakeholders should be involved as testing and documentation must also be factored into the remaining work.
  3. Prioritize the remaining work – whether the gap estimate is less than the remaining time or greater than the remaining time, it is important to prioritize the remaining work so that the most important functional gaps are addressed first, just in case other unforeseen circumstances arise.
  4. De-scope or move timelines – if more work remains than the time available, there are really only two options: de-scope some functionality or move the timeline.  It is rarely the case that you can solve issues in crunch time by adding more resources.  Even if there is less work than time available, it often makes sense to create some breathing room by de-scoping
  5. Communicate – once reality has been clearly mapped out, communicate with the client to manage expectations and make sure all parties agree that it makes sense to move some less important features off into a future release.  Focus the conversation and communications on quality and ensure that the customer understands that the decisions are for the sake of software quality and the end users.

Fred Brooks summarized this decades ago in The Mythical Man-Month:

More software projects have gone awry for lack of calendar time than for all other causes combined.  Why is this cause of disaster so common?

First, our techniques for estimating are poorly developed.  More seriously, they reflect unvoiced assumption which is quite untrue, i.e., that all will go well.

Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.

Third, because we are uncertain of our estimates, software managers often lack the courteous stubbornness of Antoine’s chef.

Fourth, schedule progress is poorly monitored.  Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.

Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower.  Like dousing a fire with gasoline, this makes matters worse, much worse.

Brooks’ reference to “Antoine’s chef” is a reference to a quote:

Good cooking takes time.  If you are made to wait, it is to serve you better, and to please you.

– Menu of Restaurant Antoine, New Orleans

He adds, later:

Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion.  An omelette promised in two minutes, may appear to be progressing nicely.  But when it has not set in two minutes, the customer has two choices — wait or eat it raw.  Software customers have had the same choices.

The cook has another choice; he can turn up the heat.  The result is often an omelette nothing can save — burned in one part, raw in another.

Brooks provides other thoughts on this topic, of course, but my take is to realize that the “omelette” will be delayed and communicate the reality to the customer and let her make the call: does she still want it if it will be late?  Can we bring out other parts of the meal before the omelette?  Or will she sacrifice the “done-ness” to get it on schedule?

But of course, job one is to recognize that it will be late and then identify how late; nothing can progress until those two activities are accomplished.

You may also like...