The Software Project Cube

The iron triangle in project management tells us that a product is the result of scope, time and resources.

Product = Scope * Time * Resources

Scope is often considered to consist of both features and qualities, while the resources usually consist of people and the tools they use. On top of that, I often like to think of the product as a combination of assets (the stuff the product is made of, like code and graphics files) and artifacts (the stuff that describes the product, like design documents and invoices). This results in a system with three dimensions, six types of nodes and many connections between those nodes. There are relationships among features, among people and among classes, but there are also relationships between features and people, between tools and artifacts, and between qualities and assets. You will understand that I find the iron triangle a bit limited in its power to express the intricacies of managing software projects. I prefer to think of them as complex adaptive systems with hundreds of nodes and many thousands of connections.

Alistair Cockburn has suggested that process is the fourth dimension that is missing from the iron triangle. Process determines the way people use their tools, the way tools monitor the qualities, the way qualities are expressed in assets, the way assets are described by artifacts, the way artifacts elaborate on the features, etcetera. Therefore, in my cubic representation, process is the emergent and balancing property that strengthens the cube. In my assessments of processes and best practices I always check how they relate to the software project cube.