Iron Triangle in project management shows in graphical form how all projects have certain constraints — normally these are cost, time and scope (thus the name “triple constraints”) with quality as a central theme. For a project to be successful, these three factors need to be balanced. There are other variations of Iron Triangle based on project type where constraints might be different based on industry type, but the concept remains the same. If you break Iron Triangle by making a change to one constraint, other two needs to be adjusted accordingly otherwise quality will suffer.
Measuring Project Success
The three constraints in Iron Triangle also serves as measurement scale of project’s success or failure.
Whether the project was completed on time estimated during the planning phase. This is the best guess based on the number/availability of resources, experience of resources involved, complexity of the project, dependencies, obstacles etc.
Whether the project was completed within the allocated budget. In software development, the cost is mainly a manpower cost which can be measured in persons/month.
Whether all the planned features were implemented or not.
This is one factor that can be hard to decide on as Quality as it can be defined in several ways. ISO/IEC 25010 standard defines quality using eight attributes shown in the following diagram:
It’s hard to boil down all these attributes to a single number so most of the time, a project owner will pick few of these attributes to measure quality.
Breaking the Iron Triangle
In a typical project, major stakeholders representing different groups of an organization have different and often conflicting priorities. The marketing group is interested in more features, financial group has more interest in keeping the cost in check, support group wants more stable and reliable product and senior management wants to deliver the product on schedule. It is critical for project’s success that a balance is set among three constraints defined by Iron Triangle when planning the project and is maintained through project’s life-cycle.
Once the project has started, changing any of the triple constraints will lead to breaking the Iron Triangle and can have a significant impact on the project that includes but not limited to following:
Project is canceled
According to the most recent Chaos Report, 18% of projects are canceled before they deliver a final product. Some of these projects might get canceled because of business decisions but the data from other research shows that 82% of the projects fail due to bad scope management.
Delivery is delayed or runs over budget
According to Chaos Report, 52% of the projects are either delivered late or run over the allocated. The average across all companies is 189% of the original cost estimate. The average cost overrun is 178% for large companies, 182% for medium companies, and 214% for small companies. The average overrun is 222% of the original time estimate. For large companies, the average is 230%; for medium companies, the average is 202%; and for small companies, the average is 239%.
In addition to bad scope management, bad estimation of both time and budget contributes to these issues. Teams fail to consider external factors, dependencies, obstacles. Another primary and very common reason for this is change in scope once the project has been started.
Delivers project is of bad quality
When stakeholders change the scope of the project by adding more features to the scope and force the development teams to deliver within planned scheduled using planned resources, teams end up taking shortcuts which result in poor quality software. These shortcuts could includes
- Skipping proper testing or not developing automated testing. Testing normally takes about 30%-50% of project development in both time and resources.
- Using 3rd party solution/library/service to cut down development time which can lead to challenges down the road.
- Non-optimized code that can impact performance and reliability of software.
These shortcuts lead to something that is known as “Technical Debt” in software development. A technical debt to a certain amount is normally acceptable in startups and early stage of project but a large amount of technical debt can lead to failure of the project.
Project is under delivered
The development teams fail to deliver all the required functionality of software as defined in scope. As per the report, more than a quarter were completed with only 25% to 49% of originally-specified features and functions. On average, only 61% of originally specified features and functions were available on these projects. Large companies have the worst record with only 42% of the features and functions in the end product. For medium companies, the percentage is 65%. And for small companies, the percentage is 74%.
Respect the Iron Triangle = Successful Project
To deliver a successful project, project owner/manager and stakeholders need to understand and respect the Iron Triangle. Stakeholders and management need to realize that if you change one of the vertexes and force the team to deliver the project without changing other two constraints, quality of software will be compromised. You can, however, think Iron Triangle as a stretchable triangle. If you modify one of the vertexes, you can modify other two as well to maintain the quality of deliverable.
To avoid breaking of the triangle, here are few recommendations that teams can adopt.
Adopt a product development methodology
Chaos report shows that larger the project, higher the chances that it will fail. At the same time, research shows that adopting a formal project management and development methodologies for larger projects improve the chances of success.
Here is the chart showing breakdown of projects by their size and their success rates.
In software development, research shows that organizations that adopted the Agile method of development as compared to Waterfall had the higher success rate.
Agile method improves direct communications between stakeholders and delivery team, extensive collaboration and transparency thus increasing the chances of success.
Using the SCRUM method project can be broken down in sprints where a precise scope is defined for each sprint (normally 2 weeks or 4 weeks period). A feedback loop is used to decide what should be the scope of sprint based on priorities defined by stakeholders. Stakeholders and development team determines what can be realistically accomplished during the sprint given the resources. Once the sprint starts, stakeholders must step aside and let the development team do their work. No changes requests can be made by stakeholders when the sprint is in progress. This helps to keep Iron triangle intact over the duration of sprint and thus improving the chances of project success while providing flexibility to change the scope of the overall project during its life-cycle.
Complex and large projects can be broken down into multiple projects with ownership divided among multiple teams. In Service Oriented Architecture (SOA), this can be accomplished easily.
One of the findings of Chaos Report is that projects that have organization leadership and user involvement have higher chances of success. In fact, “Executive Sponsorship” is the highest racking factor when it comes to success of project. C-level sponsor can make sure that project is aligned with organization’s mission and strategy, provide ongoing direction and also help to get support from other senior executive.