Calling battle-hardened project managers!

My friends on the BCS PROMSG (Project Management Specialist Group) committee are always on the lookout for new speakers who are both interesting and instructive. What they would like are battle-hardened project managers who have plenty of war stories.

Of course, one problem is that battle-hardened project managers may be too preoccupied with their ongoing battles to spare time to talk. (Other, less militaristic metaphors are available)

The thing is that when we do get them they are often very interesting, but sometimes it is difficult to draw lessons that are transferable to our own daily work. Project Eye has already told in a previous post of one veteran programme manager who commented that sometimes on projects people are over-cautious when it comes to taking risks. This might be true, but by itself not very helpful.

We want to be told more precisely exactly when we can take risks and when we should not.

Project Eye was once at a planning meeting in an organisation where proposals for new IT projects were being discussed. A grizzled IT veteran pronounced on one project proposal that having two separate leads - a technical and a business lead- was a recipe for disaster. Now it could be that there would be conflicts between the two roles. But Project Eye’s experiences of such situations have been happy ones.

Project Eye was the technical lead and came to have a great respect for the insights of the business leads, and they were able to convincingly feign confidence in Project Eye’s technical judgements, but perhaps Project Eye has just been lucky.

So what this post is really about is how we can usefully draw lessons from previous projects.

A project manager may be very competent, but still have a limited range of experience. It could be that they have had responsibility for lots of projects, but that these have all been very similar. They may be thrown if a somewhat different project appears out of the blue. Perhaps they have been implementing off-the-shelf IT solutions, but a new project requires a lot of new software to be produced.

Someone who is a consultant on the other hand may have made contributions to lots of different projects but may have had only a brief impact on each one, and not seen the longer term effect of their advice.

What is needed is some way of taking on board the lessons of a broader range of projects than those experienced by a particular isolated project manager. Project Eye guesses that the best time to try to take on the lessons of past projects is when identifying the risks. The thing about a risk is that it is not something cut and dried. A risk has a possibility of materialising in the light of day, but no certainty.

Project Eye is feeling a bit blokey, so we are going to follow the military analogy with footballing one. We do not know that Sunderland will be relegated from the Premiership, but there is clearly a chance they will, and that chance is greater than it is for Manchester City. To be useful the perception of a risk needs to be seen as a cause and effect. For example, a late delivery of a project is an unwelcome outcome, but to be expressed usefully as a risk a possible cause for this needs to be suggested, such as changing requirements.

Now the key point is that a problem that has actually had a damaging impact on one project is a possible risk on other projects. If we can collect these problems/risks from lots of projects over time, we can see which ones are most common and thus the most serious ones to be treated as risks on new projects. We can even suggest practices that ought to be adopted as a matter of habit to stop the most frequent problems re-occurring. Basic hygiene can stop diseases spreading.

What this suggests is that while individual project managers are vital to the project risk assessment, there needs to some broader, longer term process that can make sure that risk knowledge is collected from each project and is shared with others.

But we could go further. Imagine a situation where doctors in the NHS relied solely on their personal experiences when diagnosing a patient’s complaint. In actual fact, of course, they have access to a vast shared body of evidence-based medical knowledge that has been built up over many years.

In project management we have some general standards such as PRINCE2 and BS 6079, but the evidence base for them lacks rigour. They also do not provide advice on what to do when a particular problem emerges. Given the amount of money wasted on unsuccessful IT projects, an attempt to build such an evidence base would be worthwhile.

November 2019

Search this blog