Since the early days of software development we learned that there were some forces that were determinant for a project's success. We identified the triangle of scope, time, and resources (effort), and used to say to our users: "pick two".

Soon afterwards we understood that those three dimensions were not enough when we found that we could build software that met its scope, was done in time, and reasonably within the estimated effort, but was unusable because it was ridden with bugs and had an unbearable user interface. So we added a fourth dimension to the forces that drive software projects: quality. The typical depiction is a thetraedron because in it every vertex is conected to the other three, but a fully connected graph drawn as a asquare would fit the same purpose. We told our users and customers "pick three", and went on, failing to keep our commitments in about half of all software projects.

What we have found after a couple of decades is twofold. First, that it is never a matter of picking the constraints but of balancing them; agile development, for example, aims for a balance that delivers value earlier, even if it means a longer project and more effort in the end. Second, we found that the four dimensions were not enough, and that we needed to consider two additional dimensions to have a project that converges to closure: architectural design, and project design.

The issue is that it is not possible to build any moderately complex piece of software any way you want. The "best design" may be the one that dooms a project to failure, and a typical per-module process may make a project never ending. Both software design and project design must be flexible and thought out as to accomodate and balance the other forces. The whatand the how must be included in the plan. A time-critical project and a quality-critical (or resource-bound) project are totally different beasts, and they must be designed and executed differently.

An example. We all know what an automobile must do functionally, and how much it should cost, more or less. But there are infinite designs to meet the basic requirements, and many strategies to build those designs. Only some of them will be sucessful.

The new criteria add up to the forces that interact and must be balanced to have a succesful software project. They are now: scope, time, resources, architecture, and process. A fully connected exagonical graph.