How to Deliver Software Projects on Time

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, download NDepend and give it a try.

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).

The Realities of Deadlines

These days, agile software development has supplanted the big, up-front planning approach in many segments of the software industry.  Agile shops tend to take a pragmatic view of software development, recognizing the existence of something called “the cone of uncertainty.”

That’s an evocative term, but it really just communicates the idea that predicting a project’s completion date gets easier and more reliable with each passing week of the project.  Indeed, the agile concept of “story points” draws inspiration from this notion — after a few sprints, the team can look back empirically on what it accomplishes in two week intervals and use that data to project what it will accomplish going forward.

Superficially, you might think the message is to get out of the business altogether of agreeing to deadlines until well into the project — that you should simply say, “I don’t know yet.”  If you can get away with doing this, that’s great, but that’s not really the most powerful part of the lesson of these fixed-length, agile sprints.  Rather the powerful concept is the idea of fixing a deadline and letting scope vary.  That is the core premise of an agile sprint.  Every 2 weeks there is a delivery.  Sometimes the team is right about what it can deliver and sometimes it isn’t, but it gets more predictable over time.

In many cases, calendar deadlines are simply a reality.  If your organization participates in an annual trade show, and the company needs something to showcase, you don’t have the luxury of saying, “gosh, looks like 52 weeks turned into 60 weeks — oh, well, let’s get ’em next year.”  Having a set date of demonstration, keeping up with competitors, and other business realities often make deadlines non-negotiable.

The trick to hitting deadlines is cutting scope.

Wait, What?  Isn’t that Cheating?

Earlier in the post, I said that being on time meant delivering the agreed upon scope by the agreed upon date.  And, while that is generally accepted canon, the reality is often that you need to cheat, in a manner of speaking.  You need to find ways to cut scope that are acceptable (or even unnoticed) by the business.

For example, consider the aforementioned trade show.  The business wants to have something splashy to show in a demo, but they’re not going to be hawking software CDs on the spot.  You could thus cut scope on functionality related to the delivery pipeline and focus on the features that would most visibly delight people attending the demo.  Not all scope is created equal.

If you ask the business what it needs, it will tell you that it needs all the things.  The trick to delivering on time tends to be a very subjective matter of expectation management.  You deliver on time by understanding what the business needs and why, and finding a way to deliver capabilities — a concern that transcends software.  If you can get by with an IFTTT script and some duct tape and all parties are satisfied, then you call that a win and keep cranking past the stopgap.

How to Make This Work and Deliver On Time

To pull off these creative scope pivots requires two main things.  For starters, you will need to develop a deep understanding of how your business makes money and how your software helps your customers.  Simply accepting requirements documents, user stories or feature checklists is not enough for you to pull this off.  To understand how to get creative with scope means understanding needs at a much more profound level.

The second thing you need in order to perform these scope cuts is a clean, flexible, modular codebase (assuming that the quasi-tongue in cheek “IFTTT and duct tape” solution having nothing to do with code is not an option).  If your codebase is a rats’ nest of global state, complex types, and snarled dependencies, attempts to pivot on scope will serve fruitless because your code will be change resistant.  It needs to be easy for you to add new components, remove existing ones, and reconfigure as needed.

Delivering software on time is never easy when the scope and timelines in question are significant.  But you can give yourself excellent odds if you keep your code clean, understand what core needs are being addressed, and make sure you always have several contingency plans.