Iron Triangle Kills in Boston…

… Skyline Unharmed

Short-sighted demands on software teams usually don’t kill people. Software development is often described with a construction analogy. The Big Dig construction project was under exactly that kind of pressure. On July 10th, 12 tons of tunnel ceiling collapsed and killed a motorist. On July 20th, Mitt Romney ordered the tunnel to be closed. Let the finger pointing begin.

Background

The Big Dig is a multi-year construction project to fix very expensive traffic problems in downtown Boston. The Massachusetts Turnpike Authority has a good background article. Traffic congestion was projected to cost $500 million per year to motorists by 2010 without making changes. Project costs – $14.6 billion (more than 30 year payback period) versus an initial estimate of $2.5 billion.

The 6-lane overpass was to be replaced with 8 to 10 lanes of tunnels underneath the city, protecting the skyline of Boston from large concrete structures. Unlike the “protect the view” argument of previous New Orleans adminstrators against a hurricane barrier, there are practical arguments to building tunnels. The MTA was never proposing to “do nothing.”

Project Timeline

• 1983 – Environmental impact report initiated.
• 1991 – Construction begins. Initial cost estimate $2.5 billion.
• 1995 – Ted Williams Tunnel opens (the one with the collapsed roof)
• 2000 – Project completion scheduled for 2004
• 2001 – Cost estimated at $14.1 billion (project 69% complete)
• 2005 – Cost estimated at $14.6 billion, 96% complete (same link)
• 2006 – All tunnels and bridges open to the public (until now)

According to this Associated Press article, the Turnpike Commission found no problems that “rose to the level of a public safety threat.”

Timothy Johnson, author, project manager, and owner of Delta Project Solutions, speculates in his article that the source of poor quality may have been pressure on the engineering/construction teams to work faster.

It doesn’t take a lot of effort to find stories of the governor’s office pressuring the project to move faster. There was political capital on the line. So… the project moved faster. Quality shortcuts were inevitably taken. And now Mitt Romney wants to know where the blame lies. Am I missing something on the cause-and-effect graph?

Corrobarating Evidence

The US Transportation Department released a scathing audit this week, charging Big Dig officials with misleading federal officials on Feb. 1 that the project would cost $10.8 billion, and divulging later the same day that it could cost an additional $1.4 billion.

“It stands as one of the most flagrant breaches of the integrity of the federal-state partnership in the history of the nearly 85-year-old federal-aid highway program,” the audit said.

Gov. Paul Cellucci (R) fired the head of the Big Dig, James Kerasiotes, just minutes after meeting with federal highway officials. But that does not solve the larger issue of how to complete projects of this magnitude on schedule and on budget.

Christian Science Monitor, April 2000

From the same article:

The Big Dig, he points out, is the worst example of cost overrun [Ernest Frankel, a professor emeritus at MIT’s school of engineering]’s ever seen. He and his colleagues warned Massachusetts officials that the project could not be done for the state’s initial estimate of $2.5 billion. Which raises a larger point: While government officials often claim – rightly – that added time and costs are necessary on big projects, critics say authorities too often low-ball construction schedules and estimates to gain funding and public support.

Why Quality Suffers

When project constraints put the squeeze on, there are four ways we can respond. The common expression of the Iron Triangle is that a project can be represented as a triangle with three legs – cost, time, scope. If you put pressure on the project without increasing one of the legs of the triangle, then quality suffers. In this project, it looks like the consequences of pressure were mortal.

1. Sacrifice quality to increase functionality
2. Increase cost to increase functionality
3. Increase time to increase functionality
4. Delay some functionality to deliver other functionality

How To Use Timeboxes For Scheduling Software Delivery

Apparently, the folks on the big dig were pressured to choose option #1, which is not a good idea. They also apparently made liberal use of options 2, 3, and 4. Perhaps there were competence problems, or process problems, but regardless, politics trumps people the same way that people trump process.

Conclusion

Don’t sacrifice quality to meet some arbitrary metrics. Without accounting for sunk costs, review the project from its current state to its projected end state. If the additional time and costs will still allow the project to meet the ROI targets, then keep working. If not, cancel the project. If you go with option 1, bad things can happen.