“Catching Up” is a Vicious Cycle

If you’ve been involved in providing IT solutions, and especially been on the development team for a software project, you’ve probably experienced something very much like the following narrative:

Some executive, or their delegate, the dreaded “Project Manager” has shown up at your desk holding the latest project status report. That report, with its horrible stop light color scheme shows that your project is yellow trending toward red, or even worse, is already in the red. Specifications were laid down by the business, estimates were made, requirements were gathered in excruciating detail, milestones were set, and the project was chartered to execute the vision. “THE Plan” is perfect.

Because the project is failing on its milestones, and deviating from “THE Plan” the project is troubled, and by definition, out of control. The project team must be loafing around or it must be missing critical skills if they cannot deliver what was promised on the schedule that was promised.

To get back to work and avoid any further schedule slippage, you have to give your inquisitor an answer that demonstrates that you have been appropriately cowed; that you will go faster and allow them to regain control of your “runaway” project. So you blurt out:

“Sure we’re behind, but we have a handle on the problem, and we’ll catch up in the next [phase / sprint / iteration].”

I know, I’ve been guilty of it too. It makes you sick to your stomach to lie. First to yourself, and second to the business. Tasks have taken longer than expected, performance was unacceptable and need re-work, you lost time trying to track down a memory leak, a patch to a third-party library changed the API and requires a bunch of new coding to re-integrate. It’s a lie because you have no basis to assume that future iterations will go any better than past iterations. In all reality, they’ll likely go even worse.

Side Bar:
When in your extensive history working on IT projects have you ever “gone faster” and “caught up” when a project was behind? It was probably the exception, and not the rule, right? I would guess that it probably required several all-nighters and binges of caffeine and pizza. Why do we work like this?

That lie. That’s the first step into hell; the first step down the “project velocity death spiral.” We’ve all seen how this plays out, so many times:

The team has a bad iteration or two. The schedule starts to slip. Management pressures the team to “go faster” to “catch up.” The team works quickly, and though there is the appearance of dedication, heroic efforts are sloppy. For a time, they “complete” many features but delay, or fail to catch entirely, many bugs. The team devolves into poor habits like copy/paste coding and loses focus on solid architecture. Testing, if it was on the schedule to begin with, has fallen off due to lack of time. The schedule slips further. Breakages happen in UAT and features are rejected by customers. Management swoops in to “get quality under control.” The project team slows down to improve quality. However, the project schedule is now in worse shape than before the “catch up” effort, and the loop is closed.

Even if you don’t get yourself into this demoralizing situation, it is still disheartening to ponder that even in projects that have “succeeded” based on schedule, budget, and scope metrics, can be a failure when measured against the only metric that matters: did you deliver the business value that users needed and wanted. Wasn’t that the impetus for starting the project in the first place… delivering functionality to aid users in creating or enhancing business value?

So how do we stop the death spiral? How do we change the conversation around the metrics used to evaluate success? I have found answers in the communities around software development, specifically Agile, Lean, and DevOps. Stay tuned for future posts on how I think these ideas have insight to add to the conversation around projects and business value.

What are your experiences with the death spiral? Do you have a war story that helps further clarify the issue? Please share in the comments section below.