There are a lot of project characterisation schemes out there. Most companies have one, whether formal or informal. There are a few published ones however which lend themselves to thinking about how different projects require different ways of managing them. Here are some of the ones I think are most useful.
A couple of early characterisation systems come from the NPD field. Wheelwright & Clark suggested back in 1992 that projects be differentiated according to their impact on the product portfolio, while Turner & Cochrane used a goals and methods matrix to break projects into 4 types based on uncertainty of each.
More recently, Aaron Shenhar & Dov Dvir have evolved a four factor framework (the Diamond Framework) for adapting management style to the nature of the project. They’ve evolved this over a decade or so, and the current variation on it is published in Chapter 50 of The Wiley Guide to Managing Projects, as well as their recent book Reinventing Project Management. The four dimensions are Novelty, Complexity, Technology, and Pace, and they advocate adjusting the project scope (as opposed to product scope) and management approach based on variations in each of these. This framework is primarily aimed at engineering-based projects (NPD, software, construction) – the framework doesn’t look to me to be terribly useful with respect to the “soft” aspects.
Lynn Crawford & Julien Pollack’s framework for assessing the softness of projects is a good guide to this last factor. Although they don’t explicitly say so, it’s basically a way of selecting between controlling, learning, and problem structuring approaches to a project or problem. They assess projects according to 7 factors: Goal Clarity, Goal Tangibility, Success Measures (quantitative v qualitative), Project Permeability (how subject to outside influences), Number of Solution Options (or method clarity), Practitioner Role (expert v facilitator) and Stakeholder Expectations (technical vs social).
Alastair Cockburn ’s Methodology Grid breaks projects down by the number of people (roles) involved and criticality, and then by project priorities (productivity, cost, traceability etc). It’s strictly a categorization rather than classification system, as project priorities isn’t a graduated scale. In the web page linked to above (this grid shows up in any number of other Cockburn and Crystal-related places) he discusses in some depth the issues and drivers surrounding selecting and designing a methodology, and gives some principles:
-
A larger methodology is needed when more people are involved
-
More publicly visible correctness (greater density) is called for on a project with greater criticality, where more damage can result from an undetected defect.
-
“Weight is cost”: a relatively small increase in methodology size or specific density adds a relatively large amount to the cost of the project.
-
The most effective form of communication (for the purpose of transmitting ideas), is interactive, face-to-face
Cockburn is an (agile) software guy, but there’s little in this page (beyond the examples) that links it to software – the arguments are universal.
Ole Jepsen’s Project Analyzer uses a dozen or so criteria to assess the necessary rigor level of a project – pretty much equivalent to my “uncertainty tolerance” dimension. It breaks this down into 4 categories (quality management, requirements management, planning, and documentation), and illustrates nicely the cost of increasing rigor in terms of overhead vs productive work. It comes from the software industry, but looks useful across engineering-related projects.
Todd Little’s Houston Matrix uses 10 criteria to characterise projects by their associated level of uncertainty and of complexity. Todd then categorises projects as Dogs (simple projects with low uncertainty) Colts (simple projects with high uncertainty), Cows (complex with low uncertainty) and Bulls (complex with high uncertainty), and advocates adjusting the management mix as appropriate. This isn’t a million miles from my typology – several of the factors he uses for uncertainty are also tolerance drivers. Plugging the projects from this paper into my schema would mainly result in a rightward skew of the upper regions – some of his dogs would become bulls. As he notes, this has a tendency to happen over time anyway.
