More than one solution to the Project Triangle

Comments (4)

Print This Post Print This Post

Email This Post Email This Post


triangle.gifAt some point, everybody learns about the dreaded Project Triangle. The arms represent tradeoffs between cost, time, and scope. The perimeter of the triangle represents your planning commitments, so if one dimension changes, another dimension will have to change in order to compensate. For example, if scope increases, you have to either: spend more, take more time, or give up some scope elsewhere in order to make the equation balance.

Occasionally somebody makes the mistaken suggestion that there is a fourth variable of quality, but really that’s a misunderstanding of the meaning of scope. The quality level you’re shooting for is not absolute — it’s part of scope. You have to articulate and verify the bar needed to satisfy your customers. If a system performs the functions you say you wanted and you still don’t like it, then you got the requirements wrong. If you update the requirements to address your objections, you’ll discover that the scope is greater than you identified. That confusion is a telltale sign of a team with immature design capability.

The art of project management is largely about knowing how and when to make these tradeoffs. First that means establishing priority. Priority is the root of all leadership. If you can’t prioritize the competing forces in your environment, then you are not in control of your responsibilities. The road to project success begins with prioritizing these project tradeoffs.

The good news is that there are design processes that are optimized for each of the primary tradeoffs: scope vs time, scope vs. cost, etc. Traditional network-model schedules are not very good at making any of these tradeoffs. The Lean approach we’ve been discussing here is best at making scope vs time tradeoffs. However, there is another approach that allows you to make scope vs cost tradeoffs, which might be a sort of Holy Grail in software project planning. That approach is the Set-Based Development method that is used in the Toyota Development System.

Toyota holds development time fixed, and partly constrains scope. The scope constraint is that it has to be a whole vehicle, and it has to be better than the previous design of the same model (or of some comparable benchmark). They make this work by over-provisioning resources. Toyota designs multiple independent solutions for each major subsystem of the vehicle. At regular intervals, less promising designs are weeded out and more promising designs are promoted or combined. This concurrent redundancy makes it very likely that a satisfactory solution will appear within the time allotted. Additionally, Toyota leaves the requirements open until the final design converges. In this way, Toyota strives to design the best possible vehicle in the time allowed, but not better than possible.


I’m already planning to address the set-based approach by the inclusion of Pugh Concept Selection in our design workflow, but we can talk more about the Toyota thing if people seem interested. Otherwise we’ll keep more focused a flow-oriented scope/time model.