Most students of Project Management are familiar with a decision making tool known as the Project Management Triangle. It is also known as the Iron Triangle, or the Triple Constraint. The concept provides a mechanism for the product owners to make decisions.
In a nutshell, the concept states that you may control two of the three project factors (Time, Cost, and Scope/Quality), but the third factor is mostly out of your control. Therefore you can:
- Have the project fast and within scope (all features desired), but then it may exceed the desired cost,
- Have the project fast and within cost, but then you may not get all the features in scope,
- Have the project within cost and within scope, but then you may not get it on time
The Project Management Triangle is used by project managers in many industries, but in software development another factor often needs to be considered when making project decisions and that factor is uncertainty.
Uncertainty
Uncertainty doesn’t fit neatly in the Project Management Triangle. Nor can you simply change the triangle into a square by adding uncertainty because uncertainty is not affected consistently with changes in the other three factors. A decision that increases uncertainty may increase the time, increase the cost, decrease the quality, or even do all three. Conversely, a decision that increases uncertainty could have the opposite affect on any or all of the sides of the triangle.
Side Note: Quality as Part of Scope
I believe that scope includes the aspect of quality. There are two types of software quality. One is the richness of features as seen by the users of the software. The other is the robustness, integrity, and ease of maintenance of the code, deployed solution and ecosystem the solution runs in. Scope can be easily equated with the quality visible to the users of the software. But the quality of the ecosystem and maintainability of the source code is not so easily identified by users of the software. Even so, for purposes of this article, I think that both types of quality can be included within scope.
The problem with the introduction of uncertainty is that, by definition, the decision makers don’t know if the detrimental effects will come to pass; only that detrimental effects are more likely to happen when uncertainty is introduced. Therefore decision makers must decide if the change that is intended to reduce cost, reduce time, or increase quality, is worth the uncertainty that comes with it.
Proactively Reducing Uncertainty
Some decisions reduce uncertainty. In fact, project managers sometimes deal with risks by creating a new project to explore the uncertainty and eliminate the risk it entails. I hesitate to call out benefits of the waterfall methodology of development, but risk reduction might be a step more easily adopted in waterfall, as opposed to agile, because waterfall is more likely to identify and consider the risks at the start. This allows for developing a prototype to test the use of a new tool, component, or framework, in order to understand it better and reduce the uncertainties. For Example, NASA reduces risks to its human astronauts by first launching unmanned rockets instead space.
Acknowledging Uncertainty
In the world of software development, we often must choose the solution to a problem from a menu of options. Some options increase quality but at the cost of time. Others decrease time but at the risk of quality. And some increase uncertainty, particularly when the option introduces a new technology, tool, or process.
When a project has a tight deadline, a team should be less willing to risk an option that introduces new technologies, and thus uncertainty. Also, when a project has high visibility or life-endangering impact, a team should be less willing to risk an option that introduces new technologies, and thus uncertainty.
Here are some examples:
- A team discovers a defect during product development. The team can choose a quick fix, which is to log an error message to a local text file, or choose a more robust fix, which is to log the message to a cloud-based service. The robust fix is more desirable but might cause failures for some clients that implement the product in unexpected environments. Is the team willing to accept the risk of the robust fix, or should they implement the quick fix and take more time to test and prove the robust fix before providing it in a future release?
- A team chooses a technology they have not used before. They choose to use .Net Core instead of the .Net Framework. They accept that there are uncertainties, which means risks, to successfully developing with the technology as well as deploying it and supporting it. They develop successfully but when they deploy they discover .Net Core is not supported on the server they deploy to. They realize they need to upgrade the OS on the servers in order to support their application, but the IT team won’t be able to perform the OS upgrade for several more months. This may be acceptable, but if the team had a tight deadline for the project then perhaps this project was not a good candidate due to the uncertainties that came with the new framework.
- A team chooses a stronger encryption technology for the next release of their software. When the software update deploys to some desktops it fails and the end users are unable to use the product. The failure occurs because the encryption algorithm, a new technology thus containing uncertainties, is not supported by Windows Vista, an operating system that some customers still use. You can probably guess how I came up with some of these examples. 🙂
- A team chooses to skip significant testing of the software in order to release on time, within budget, while providing the scope desired. Most all members of software development teams can tell you that inadequate testing increases the risk that the software will encounter problems in production use.
In the course of my career we have often opted for one solution over another not because one solution would reduce cost, reduce development time, or improve quality. Instead, the solution we chose was the one with the least risk. This was usually the choice when our release deadline was near and we did not want to introduce uncertainties.
Mitigating Risks
A technique we use to reduce the negative impact of risks is to use the new technologies in minor features in our applications. For example, when deploying a new logging framework we used it only in one minor component. When we created a framework for sending emails via SMTP we only used it in an optional feature. As we grew confident with the new technologies and increased their robustness, we expanded their use across the application.
Here are a few good articles about the traditional benefits of the Project Management Triangle: