The Project Management Triangle must die!

By John Ferguson Smart and Jan Molak

"On time, in scope and in budget". This is the refrain of countless project managers on their LinkedIn profiles: it is the badge of the successful project manager, and they wear it with pride.

It is also a misguided and dangerous idea that invariably encourages a short-sighted and bureaucratic mind-set, detrimental to both project teams and the organisations they serve.

The project management triangle

This idea of "on time, in scope and in budget" is often modelled in the form of the "Project Management Triangle":

The "Project Management Triangle" describes the fragile balance between three constraints: time, scope, and cost. Conventional Project Management theory teaches that these constraints are tightly related: that if you change one constraint, you also need to change the other. For example if you want to add scope (i.e. more features), you need to add time (i.e. delay delivery) or cost (i.e. add more people). Or if you want to deliver faster, you need to reduce scope (i.e. build fewer features) or increase cost (i.e. add more people). Generations of Project Managers have been taught to believe that a good Project Manager astutely juggles these three constraints throughout the duration of the project to ensure that the project succeeds.

"Adding manpower to a late software project makes it later"
- Fred Brooks, "The Mythical Man-Month", 1975

Of course, in the context of software development at least, this reasoning is fatally flawed, to put it politely. While adding more workers to a factory floor may allow you to produce more widgets faster, adding more surgeons to a heart transplant operation will not make the operation take any less time. There are many, many books and articles written on this topic, dating from the 70s onwards, though evidence would suggest that they have all been largely ignored.

The aim of this article is not to discuss why the Project Management Triangle is wrong. The aim is to present a different, infinitely more useful, way of looking at IT project spending.

The Project Management Triangle is wrong because it asks the wrong questions. It starts with the flawed premise that scope, cost and time are the three factors that determine whether a project is successful. In fact, they are not. The key factors in deciding whether a software development project is a success are:

• Investment, not cost
• Return on Investment, not scope
• Cost of delay, not time

Let's look at what this means.

Investment not Cost

As software development professionals, we are trained to think of projects in terms of budget and costs. Indeed, in most large organisations, a project needs a budget, and the budget represents a fixed cost.

However developing software is not a cost. Rent is a cost. Electricity is a cost. Software development is an investment.

In fact, if the software doesn't deliver more value to your organisation than it costs to develop, why do you even bother developing it?

Ask not: what will this feature cost to build, ask: what will this feature do for my organisation

High level executives generally understand this concept just fine - you invest in a software project to produce value for the organisation. But it runs against the very grain of traditional project management.

Return on Investment, not Scope

Here's a dirty secret of software development: the Business doesn't care about the features you deliver.  They don't care how slick the features are, or what cutting-edge technologies they use. They only care about how these features can help the business generate more value.

Business doesn't care about the features you deliver. They only care about how these features can help the business generate more value.

Traditional project management approaches tend to try to fix the scope early on, and then ensure that the "contractually agreed" features are delivered. "Scope creep", those extra features that tend to slip into a project once you understand what you really need to do, are the bane of traditional project management.

But when you think of IT projects in terms of investment, rather than cost, you change your outlook on what features you should include. Indeed, why are you trying to fix scope, and avoid so-called "scope creep", before you understand what "the scope" really is? Fixing scope is simply a technique to control and limit costs. But if software development is an investment and not a cost, then what you really want is to include the features that will yield the highest return for your IT investment, and exclude the ones that won't. This set of "high-ROI" features will inevitably vary as your understanding grows or as circumstances change. And that's just fine, as long as you have some visibility on what you are investing, and what return you expect to get from your investment.

There is no such thing as "scope creep". There are only folk trying to articulate their growing understanding of the actual business needs.

Cost of Delay, not Time

The third constraint of traditional project management is time. Projects are often assigned arbitrary deadlines, and the Project Manager's role involves making sure the deliverables are delivered by this date.

Delivery of some features is time-sensitive, which makes some deadlines real - especially when external players are involved. However, in many cases "deadlines" are merely lines in the sand, arbitrarily drawn to constrain the cost.

A better approach is to think about what it would cost to not deliver a given feature by a certain date. In most cases, some features are more time-critical than others. For example, if you are building a video game tie-in with a popular movie, it might be mission-critical to get a basic version with the first level available by the movie release date, but other features, such as additional levels or characters, might be able to wait until after the movie has come out.

Don't ask: What do I do to deliver everything by the deadline; ask: what will it cost if Idon't deliver this feature by the deadline.

The Corrected Project Management Triangle

In our view, the Project Management Triangle suited to modern software development projects should really look like this:

There are many techniques that can help you plan projects in terms of investment and ROI. Some that are used with great success by companies of all sizes are XScale techniques such as Business Bingo and Release Refactoring (as discussed in this presentation).

We help organisations get more value sooner out of their IT teams - get in touch to learn more!

JOHN FERGUSON SMART is an international speaker, consultant, author and trainer well known in the Agile community for his many books, articles and presentations, particularly in areas such as BDD, TDD, test automation, software craftsmanship and team collaboration. John helps organisations and teams around the world deliver better software sooner through more effective collaboration and communication techniques, and through better technical practices. John is the author of the best-selling "BDD in Action", as well as "Jenkins: The Definitive Guide and "Java Power Tools", and also leads development on the innovative Serenity BDD test automation library.

JAN MOLAK is a full-stack developer and coach who spent last 12 years building and shipping software ranging from award-winning AAA video games and MMO RPGs through websites and webapps to search engines, complex event processing and financial systems. Jan's main focus is on helping organisations deliver valuable, high-quality software frequently and reliably through implementing effective engineering practices. A prolific contributor to the open-source community, Jan is the author of the Jenkins Build Monitor helping thousands of companies worldwide keep their builds green and the delivery process smooth.