It has happened to all of us. The schedule falls behind, despite the well-meaning efforts of everyone involved. People make mistakes. We make mistakes. Sometimes, stuff just happens. The question is what do we do about it?


We’ve got a few tools we can use when things fall behind. The most famous, and most overused, involves asking the developers to step up and code like madmen. It’s a reasonable approach to a short-term problem caused by circumstances outside of anyones’ control. The method only works, though, when the cause of the deviation is either resolvable or of very short duration. If the deviation continues for long enough our people burn out; if it comes from something other than isolated circumstances the short-fall continues to grow as the team tries to catch up.


Adding resources applies the same effect over a longer period of time. A new person or persons traipses in, hammers away at the work, and gets it done. The extra hours invested will, in theory, catch the team up and eventually put them ahead. Unfortunately a new resource involves months (not days) of integration time and might not work out. As much as we might like to think of people just as FTE numbers, everyone brings a personality and history to the table. They might have the skills to resolve our immediate trouble but their personality or temperament might cause more long-term issues than keeping them around is worth. More importantly, this approach only works if the short-fall occurred due to a circumstance or because a long, slow process of falling behind. That’s not even getting into the fundamental truths of Brooke’s law.


Both of the approaches above assume the schedule deviation occurred due to an isolated set of circumstances causing an otherwise well-planned project to fall behind. Unfortunately this is only the case in text books about earned value. In reality, most projects start off with a flawed set of assumptions and unclear requirements. We can throw hours and manpower at these flawed edifices until we all bleed, but success will remain elusive.


Addressing these kinds of schedule deviation requires a very different tack. Some would call it more aggressive; I’m personally inclined to call it more direct and effective. In these cases we have to continuously go back to the business requirements and refine them until we honestly understand what we want to do. This process will involve things no one likes to talk about anymore including but not limited to proof-of-concept builds, pilots, and vast amounts of throwaway code. At first these waste more time than they gain, but over the long haul we generally start to see a continuous process of catching up.

Alternately, we could adopt the equally unpopular approach of constraining function. Occasionally management will buy into the idea that we have to call a halt to all the changes in scope so we can close a project’s book somewhere close to on time. This approach, though, ignores the simple reality that as the project progresses we really do learn more about what the product needed to do. What we sometimes define as “scope creep” is often the process of refining our understanding of the client’s actual needs. Regardless, it does allow you to “catch up” by fixing a line in the sand and letting you eventually cross it.

What other ways to you use to catch up?.