The iron triangle or the project industry and project management is the well known connection between Scope, Time and Budget. The famous iron triangle is
The three sides are connected to indicate that if you pull (as in load one side of the problem) the other two will feel the stress of that load. So if you increase the scope, the cost will go up and the schedule will get impacted, If you shrink the schedule, the scope has to give or the cost has to increase. if you squeeze the cost the schedule has to be impacted and/or the scope as well.
This basic principle has been taught in every software engineering 101 course. Of course as we become managers, we tend to test this theory and find out that it is very much true!
Then we hear about amazing projects that manage to pull on all the angles and still deliver on time, within budget and everything that the customer asked for and more! How is that possible? Songs are sung about the these supermen who jump in with their capes perfectly ironed and rescue the project damsel out of distress.
Seriously, there are definitely some great literature available that explain the magic that regular project managers can do. I highly recommend the following books
The Mythical Man Month - Fred Brooks : The “bible” for the triangle. The chapter no silver bullet is a moment of epiphany.
The Goal - Eliyahu M. Goldratt : The man who taught me theory of constraints and made me visualize the critical path in MS Project.
The Phoenix Project - Gene kim : A more modern taken on IT projects and definitely worth a read.
Soul of a new machine - Tracy Kidder: If you want to read about project and program management heroes, I highly recommend this one. I love the racy read on this one.
These are not “textbooks” in the classic sense but more practical in nature and the underlying principle in all these books is a clear reference to the iron triangle. Theory of constraints while not a software book, explains how constraints work and the famous constraints in software are scope, cost and schedule.
Like any good fairly tale, once the software project completes “they all went to live happily ever after” doesn’t happen in software projects. In fact a lot of fun happens once projects are in production. I am reminded of Warren Buffet’s famous quote. “Only when the tide goes out do you discover who’s been swimming naked.” Going to production is the software equivalent of when the tides goes out. The times comes when all the digital transformation gurus are abandoning ships fast, all the powerpoints gets disproved, and all the lines and boxes of visio comes alive and sometimes dies a fiery death on launch :-)
If I leave the extreme asides, the typical go live projects end up creating new and interesting “side-effects” to other teams and departments. For example a new launch results in a significant increase in tickets to the support team. An large feature release suddenly results in slowdown of old features. Customers complaining that the new release is far inferior to the old one. The “app appears sluggish” and so on. Basically as new releases hit production and over time there is a definite sense of entropy setting into the software. Fred brooks is attributed to this quote that sort of sums up the problem
“Systems program building is an entropy-decreasing process, hence inherently metastable. Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.”
A few years later, Ward Cunningham came up with the term technical debt(PDF). To explain this term, It is the shortcuts taken to get a software project to production. These shortcuts will affect the overall productivity of various other users of the support, both internal (support etc.,) and end users as well.
Now debt doesn’t occur only in Technology, There are so many other forms of debt.
- Feature Debt: A Feature debt is when certain parts of a software has not been completed. For example, weekly reports not built and customers are raising tickets to the support team to obtain the data. Support team in turns asks the development team to query the database and prepare a spreadsheet of data… and so on.
- Quality Debt: Having a large number of bugs is a clear indication of a quality debt. Rushing with limited testing to beat project deadlines are the natural cause of this problem.
- Process Debt: Using poor processes during development, resulting in confusion and communication lapses among teams. A good example of this problem is not having good configuration management processes resulting in poor releases, customer confusion on right versions of products etc.,
- User Experience Debt: Not having a user experience guidelines for the product resulting in differentiated user experience across product modules and release confusing end users about how different parts / versions of the product behaves.
So why do the best laid plans of men and mice go wrong? My theory is that the iron triangle is inviolable and so there is really no way to escape its influence. At the same time projects do deliver without ANY compromise on scope, schedule and cost. This is possible only if we incur debts over time. A little bit each time on the various types of the debts detailed above. For example,
- We cut corners in testing to ship sooner.
- we descope a report that is needed by the internal team (It is not a customer facing feature!).
- We skip well laid out processes to beat the deadline and so on.
Each in a small quantity that is not a large risk in itself but the nature of debt is that it accumulates over time. Fred Brooks summed the problem in an elegant way
“Soon or later the fixing ceases to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress.”
So a better way to look at the iron triangle is to add the time dimension to the view.
With each triangle representing a release of the software, over time the debts accumulate and we still achieve the magical release of on time, on budget and scope compromised software.
What can we do to recover from this debt trap that is happening here? Given that quantitative easing is not an option for mere mortals running software projects, we will actually attempt to repay the debt at a different point in time. So we will start adding refactoring as part of future releases. One or more of the tickets that gets included in the future releases would be related to repayment of Debt. This could be any of the debts outlined above not necessarily just technical debt. Thus we continue to deliver projects on time and on budget and at the same time play catch up to our debts.
By recognizing debts as first class citizens that form part of a particular sprint and release, we legitimize the need to both take shortcuts and also recover from any minor infractions for the long term.