Project management has tended to be a one-size-fits–all discipline. This attitude is reinforced by the profession’s Bodies of Knowledge. The PMI, for example, claims that the “knowledge and practices described are applicable to most projects most of the time,” [48], while with Prince2 “you can apply the principles ….. and the associated training to any type of project” . However there is plenty of evidence to suggest that current best practice in project management can give less than ideal results [49-52].
One possible factor driving this is the possibility that one size does not in fact fit all, and that standard methods are inappropriate for some projects. Although mainstream PM literature is starting to recognise that projects are heterogeneous, and that this has some management implications, it is still not very accepting of alternative approaches. The NPD management field has recognised for a while the difference in project characteristics but, made no great attempt to derive implications for management methodologies. Most attention to the implications of characteristics for methodologies has come from the software, infrastructure, and organisational change fields. These fields have widely disparate approaches & experiences, but little attempt has been made to integrate the thinking. I think there’s scope to pull the various characterisation systems together and see if something can be derived which tells us something about the applicability of the various management methodologies.
Approaches to date have mostly focussed on uncertainty [53-59] and complexity [53, 55, 56, 59-61]. However complexity is to a large extent a driver of uncertainty, via inability (for resource or systemicity reasons) to fully comprehend the situation [53]. Time pressure is also a driver of this, through reduced ability to take the time for comprehension and increased propensity to turn up the control inputs.
The software industry focuses also on criticality [62-66]. This is independent from uncertainty, and is more about the consequences of uncertainty. Criticality is not recognised as a factor by other fields as the range is smaller – generally high in infrastructure due to costs, generally low in organisational change.
There are other factors which impact upon the consequences of project uncertainty. When the team’s ability to disseminate and integrate information is low, its ability to react to events in an unplanned fashion is reduced. It is therefore likely that unexpected events will have a larger impact than they might otherwise have before the team brings them under control – the consequences of uncertainty are magnified. In these circumstances the gap between perceived and actual uncertainty may also be higher, so an additional buffer is required. Drivers for poor communications are large or geographically dispersed teams. Other drivers which leverage consequences are team capability (coherence, experience, and proportion of Cockburn level 2 & 3 members) and “hardness” of stakeholder expectations.
Consequences of uncertainty are independent of the magnitude of the uncertainty itself, thus we have a 2-dimensional typology (see Figure 1). The orthogonal relationship is similar to that seen in risk management approaches such as FMEA, where the probability of an event multiplied by its consequences give the risk factor. This typology lets us draw a number of conclusions – or at least discuss a number of factors – relating to project behaviour and management tools. I’ll discuss these at a later date.

I found your site on google blog search and read a few of your other posts. Keep up the good work. Just added your RSS feed to my feed reader. Look forward to reading more from you.
- Sue.
Comment by Sue Massey — January 30, 2008 @ 5:00 pm
Update to this: Originally I had the vertical axis the other way up and was calling it “tolerance”. I’ve since inverted it and am now calling it “consequences”. Consequences is the combination of how much is at stake (criticality) and how comfortable we are that we can prevent unexpected events from becoming disasters (which is driven by team factors including communications, expertise, and authority). Using axes of uncertainty and consequences gives a nice analogy with risk management techniques like FMEA, where probability x consequence = risk.
Comment by Dave — March 7, 2008 @ 10:26 am