The Iron Triangle is not a dinner bell calling you to an all-you-can-eat smorgasbord. It never has been. Yet, it seems that most IT managers believe if they can just ring that triangle loud enough and long enough, they can get an arbitrary amount of scope completed on a fixed schedule with fixed resources. That won't change overnight. The belief in fixed Scope, Schedule, and Resources is a myth; myths are part of culture; cultural change is slow; and myths are among the last vestiges of an old culture to fade away.
The myth of the Iron Triangle is a holdover from an information technology culture whose time has passed. Myths die hard. They live on long after their origins have been forgotten. Even though the majority of IT project managers today understand the value proposition and embrace the fundamental ideas of contemporary software development methods, whenever a conflict arises among Scope, Schedule, and Resources they seek comfort in the familiar: Either embark on a Death March, or delay deployment, or both.
In the old days, people felt they were flawed human beings if they couldn't deliver fixed Scope on a fixed Schedule with fixed Resources. Isn't it axiomatic that an adequate, worthy, deserving human being can do that? What's wrong with you, if you can't? As industry analysts learned through years and years of surveys and studies, most software development projects run well over schedule — I think I read somewhere projects have averaged about double their original schedule — and a goodly portion of software features are never used — something like 45% to 65%, depending on whom you ask. The exact numbers aren't as interesting as the general situation.
It's unsurprising, really. It's the natural result of insisting on completing 100% of Scope no matter how long it takes. It's the "no matter how long it takes" bit that kills you, you know. As time passes and you continue not delivering anything, your customer's needs objectively change, and your customers subjectively learn more about what their needs really are. By the time you deliver the perfect solution, it matches the original guess about what the customer's needs were, but it doesn't match the real, up-to-date needs.
Nevertheless, project managers over the years steadfastly insisted their teams do just that. It was a Death March, a delayed deployment, or both, and it happened time after time. That meant schedule slippage and, consistent with the mythology of the culture, slippage of any side of the Iron Triangle meant the managers and their teams were flawed as human beings. There was much rending of flesh, self-flagellation, and bleeding from the eyes in atonement.
Those poor benighted souls were not flawed, except insofar as they believed in a flawed myth. Surveys of C-level executives and business managers in recent years have asked what they considered to be the most important business drivers for software projects. Their responses consistently name time to market as the single most important factor. It's a story told by many in many ways: "Perfection is the enemy of the Good," "Good enough today is better than perfect tommorrow," and so forth. And the Iron Triangle? Well, clearly the side that (usually) has to remain fixed isn't Scope after all, but Schedule.
Okay, then, let's adjust Resources instead of Schedule. Then we can deliver all the Scope in time to satisfy our customer. Have you ever heard your manager ask, "How many more people do you need to meet the date?" Well, hang on a second. Can nine women produce a baby in one month? Maybe it depends on how much overtime the women are willing to put in, but my guess is: Not usually. Of course, software isn't a baby. Babies are substantialy cuter than software, although both can be a smelly mess to change. Nevertheless, Fred Brooks taught us what happens when we add manpower to a late software project. He taught us many, many years ago. It isn't news (or shouldn't be, anyway).
So, if Schedule is sacrosanct and adding Resources is counterproductive, what's left? (I'll give you three guesses.)
Many managers today understand the value proposition of leading-edge thinking as embodied in Lean and Agile development methods, and many apply those principles on the job in real IT projects. Even so, when confronted with a conflict among Scope, Schedule, and Resources, many of the same managers retreat to the comfort of the old, familiar myth that the Iron Triangle can be appeased. Often, their resistance to pragmatic alternatives is visceral and emotionally-charged.
I was recently struck in the face by an Angry Pie when I remarked that the agile approach to managing the Iron Triangle usually means Schedule is fixed while Scope is variable. A manager who understands agile thinking and applies agile methods on his own projects retorted that the statement was completely wrong. He went so far as to say he was personally offended by the idea. Why the strong reaction? I suspect it's because the idea runs counter to the mythology that managers have been conditioned to believe throughout their professional lives. When you suggest varying Scope, it sounds to them as if you're saying "No" to the customer's business requirements. That's not really the case. If anything, it represents a more realistic "Yes" than any previous approach.
The all-or-nothing approach to Scope usually has the same result as an all-or-nothing approach to anything else in life: We end up with nothing. The more-effective approach is to deliver something useful in time to make a difference, and then refine it as time allows. Resistance is futile: Managers can't change this reality by yelling at it.
Fortunately, there is a practical approach to managing variable Scope. All around the world, teams are using that approach right now, even as their traditionally-minded colleagues are bleeding copiously from the eyes in atonement for slipping Schedule. The basic idea is to identify the baseline of functionality the business really needs to have in place by the hard date. We want to deliver at least that functionality into production by the hard date. After that, we can continue to develop the remaining functionality.
Obviously, this approach requires a genuine commitment to the four valueslisted in the Agile Manifesto, and in particular this one: Customer collaboration over contract negotiation. When Scope is predefined by a Requirements Specification (or similarly-titled document), it's a contract that doesn't allow for flexibility. Every requirement appears to be equally important, and we have no basis to identifying the minimum necessary functionality for an initial release. When Scope is managed collaboratively between the customer and the team, we have a realistic basis for flexibility.
There are a couple of techniques for handling variable Scope on a fixed Schedule, and agile teams usually combine the two techniques based on the realities of each situation. One technique is to identify the features that are critical to the business operation and deliver those first. Then, with the most critical features in production, the team continues to deliver the remaining features incrementally. The other technique is to deliver all the features of the application, but elaborated only to a minimal level. With that baseline functionality in place, the team continues to fill in the remaining details in the features incrementally. Some people call the latter technique a "walking skeleton," a "bronze-silver-gold" approach, a "dirt road, asphalt road, freeway" model, "minimum, good, and better," or some such thing.
This example is a project I worked on for a financial services company several years ago. The goal was to sell loans for luxury purchases such as recreational boats. Customers in a showroom would fall in love with a boat, apply for a loan, and wait two days for a yes-or-no answer on the loan application. By the time two days had elapsed, the customers had time to sleep on it and come to their senses. The business opportunity was that if we could turn around the loan application while the customer was still standing in the showroom, mesmerized by the shiny new boat, we could close more business.
There was a time constraint on the initiative. We started in February, and the peak sales season was the spring of the year. Two other lenders were interested in tapping this market segment, as well. Therefore, we had strong business drivers to get a solution into place within a couple of months. That meant we didn't have time to elaborate all the desired features fully.
In collaboration with the Product Owner, we identified the key features necessary to get the loan applications turned around quickly. We were able to deliver those features in time to meet the business goals, although the back end of the whole thing was rather messy. Over time, we cleaned up the back-end interfaces, added more automation behind the scenes, fixed a few annoying but non-critical defects, and improved usability.
The initial release with minimal features enabled the company to be first in the market segment and to enjoy substantial revenue enhancement. Had we taken a traditional view of the Iron Triangle, we would have delivered the perfect solution far too late to be of any value.
This example is a recent project for a cable television company. The goal was to support the order and set-up process for cable customers to convert to digital reception, as mandated by law no later than February, 2009. In this case, we could not choose a subset of features for early delivery because the entire business process must be supported end-to-end in order to convert a customer. We took the approach of building a "walking skeleton" of the solution that included all features, but elaborated each feature only to the minimum level of functionality absolutely necessary to support the business process. In subsequent releases, we fleshed out the skeleton, adding functionality and back-end niceties.
The initial release with all features supported at a bare-bones level of functionality enabled the company to meet its time constraints in converting customers to digital reception. Had we taken a traditional view of the Iron Triangle, we would have delivered the perfect solution far too late to be of any value.
It's high time we broke free of outdated assumptions about what can and cannot change, and about what "business value" really means in a particular context. In most cases it isn't necessary to build every feature to the gold standard before delivering anything at all. Customers can make use of a subset of features or a basic implementation of features initially, especially when the alternative is to lose market share or revenue.