Someone asked me recently, almost in passing, about the keys to delivering software projects on time. In this particular instance, it was actually a question of how to deliver .NET projects on time, but I see nothing particularly unique to any one tech stack or ecosystem. In any case, the question piqued my interest, since I’m more frequently called in as a consultant to address issues of quality and capability than slipped deadlines.
To understand how to deliver projects on time (or, conversely, the mechanics of failing to deliver on time) requires a quick bit of term deconstruction. The concept of “on time” consists of two concerns of software parlance: scope and delivery date. Specifically, for something to be “on time” there has to be an expectation of what will be delivered and when it will be delivered.
How We Get This Wrong
Given that timeliness of delivery is such an apparently simple concept, we sure do find a lot of ways to get it wrong. I’m sure that no one reading has to think long and hard to recall a software project that failed to deliver on time. Slipped deadlines abound in our line of work.
The so-called “waterfall” approach to software delivery has increasingly fallen out of favor of late. This is a methodology that attempts simultaneously to solve all unknowns through extensive up-front planning and estimation. “The project will be delivered in exactly 19 months, for 9.4 million dollars, with all of the scope outlined in the requirements documents, and with a minimum standard of quality set forth in the contract.” This approach runs afoul of a concept sometimes called “the iron triangle of software development,” which holds that the more you fix one concern (scope, cost, delivery date), the more the others will wind up varying — kind of a Heisenburg’s Uncertainty Principle of software. The waterfall approach of just planning harder and harder until you get all of them right thus becomes something of a fool’s errand.
Let’s consider the concept of “on time” then, in a vacuum. This features only two concerns: scope and delivery date. Cost (and quality, if we add that to the mix as a possible variant and have an “iron rectangle”) fails to enter into the discussion. This tends to lead organizations with deep pockets to respond to lateness in a predictable way — by throwing resources at it. This approach runs afoul of yet another aphorism in software known as “Brooks’ Law:” adding manpower to a late software project makes it later.
If we accept both Brooks’ Law and the Iron Triangle as established wisdom, our prospects for hitting long-range dates with any reliability start to seem fairly bleak. We must do one of two things, with neither one being particularly attractive. Either we have to plan to dramatically over-spend from day 1 (instead of when the project is already late) or we must pad our delivery date estimate to such an extent that we can realistically hit it (really, just surreptitiously altering delivery instead of cost, but without seeming to).