Late answer, however I believe there is something to add to the existing replies. I believe that the whole idea of standard one-fits-all prioritisation graph is more than wrong, it's dangerous.
Widely Accepted Project Dimensions
The general agreement within management community seems to be that a project can be sliced into 4 dimensions:
Things start getting fuzzy when you either try to further subdivide these dimensions, measure them, or look on the way they affect each other to come up with a prioritisation.
Interdependency
In software usually scope means functional requirements (what software does and also what it is not supposed to do) plus any auxiliary requirements necessary to complete the delivery of the software to customers. Naturally, scope affects project time, cost and functional and non-functional quality.
Let’s say a business has a fixed window of opportunity to beat competitors or deliver some service and cash in. The time clearly takes priority over scope; parts of the system can be done outside software.
But for rocket engine control software the scope might be non-negotiable, and when it takes priority over time. In a similar vein there are interdependency between all of the dimensions.
Endless Slicing
The dimensions can be sliced further: shorter development time versus less effective and efficient system (time lost in maintenance and usage of the software), smaller development cost versus higher total cost of ownership and reduced lifetime (leading to smaller return on investment), higher versatility of use versus mode difficult to learn.
Quality is probably sliced into further categories the most, many of which involve conflicting choices:
- Functional:
- Non-functional:
- Usability
- Maintainability and design extendability
- Performance
- Operational and environmental
- Legal (and other standards) compliance
- Cultural (internationalisation, localisation)
- Look and feel
- Security
- Political
And the process of slicing a piece of software ecosystem into categories can be endless. And there are endless ways to measure a success or failure of a software project too. Including stakeholder satisfaction, where development team actually also has a stake in the project and hence their satisfaction matters.
Simplification is Harmful
Software design comes as a result of a series of trade-off between these categories. And as it is with cooking a good meal there are endless ways of combining ingredients, depending on circumstances, customer request, allergies and ingredient availability.
It’s probably best to avoid simplification by putting a poster on a wall where Cost always takes priority over Scope, or Maintainability is more important than Look and Feel. Project manager’s job is to keep in mind the whole picture and give team members guidance on making the prioritisation decisions daily, based on the circumstances.
A PM cannot be replaced by a graph on a wall, nor should a good PM try to outsource the essence of her or his job to a piece of paper.