Project dimensions

In Karl Wiegers' book "Practical Project Initiation" he includes an approach to developing a view of a project's constraints.

The starting point is to map the 'five project dimensions' on a kiviat diagram (radar chart) showing their degree of flexibility.

Wiegers sees that the 'iron triangle's' three project dimensions are inadequate, and if stated as 'time', 'cost' and 'quality' he's dead right. But he re-engineers these three into five (see the illustration from his book, below): features, quality, cost, schedule, staff. There was a question as to whether 'risk' was a project dimension. Of course, it isn't; it is a characterisation or qualification of any of the legitimate dimensions and doesn't have an independent existence or basis apart from the subject that is at risk.

But is five better than three? Does it help?

My first reaction is that 'quality' is a fake dimension, and 'features' perhaps as well; (although in software development, maybe its meaningful). These two attempt to split out the one parameter that has basic meaning for the project's mission: '[technical] performance'. If I need performance at 'n' for a project, then the only 'quality' I'm interested in is in 'n' being achieved. If there's an acceptable range, then it is the performance range, not a separate thing called quality range. So performance accepted is not just 'n', but anywhere between 'n-m' and 'n+p'.

'Quality' as an add-on extra to production is unhelpful and only serves to create an add-on industry of 'quality' advisors.

The two dimensions of 'schedule' and 'staff' are also related, and I question the split. However, I can see the sense operationally, with the use of the five dimensions is to establish the constraint envelope. If schedule (I think the term 'delivery' is better, it carries a reminder that the project is there to produce things, and not just to formulate an abstract schedule) is highly constrained, then staff flexibility might be nice to know, but possibly irrelevant; on the other hand if staff is a constraint, and delivery is flexible, then so what?

BTW, I'm glad Wiegers uses 'staff', not 'resources'. Staff are people, iron ore is a resource.

So, for me, the constraints to a project, or to a work package in a large project, come from the requirements for delivery, and this is probably related to interfaces with other work packages, the performance requirements and mission the project is to be used for, and the funds available to be invested for an expectation of return (I prefer to talk business, rather than accounting).