Far, far more often over my career I have heard projects described as being late, or over budget, or having to be de-scoped due to not delivering … far more often than I have heard the admission that it was the plan that was wrong.
Yes, some projects are executed poorly. But many of the so-called late, over-budget and under-delivering projects I have looked at were over-optimistically planned in terms of the time and cost it would take to achieve a certain quality outcome in the first place. They were set up for their apparent failure.
Optimistic plans and promises are, unfortunately, often thought to be required in order to get a project started, get an organisation committed (I mean really get them physically stuck in it up to their waists rather than just intellectually committed, because that’s so easily backed out of), or, commercially, sell and sign a contract. I’ve often heard it said – usually at the eventual, successful conclusion of a project that turned out to be far more difficult and demanding than the original plan suggested a nightmare, that “we would never have started it if we had known it would be like that” – the suggestion being, curiously, not that the decision to start was based on some regretful deception, but that the illusion and optimism were in fact necessary motivating strategies, well played.
It’s worse than just optimism, though. There’s also often a major failure of re-baselining or change control when, often right at the start, the planned team is not fully staffed, required decisions are not made, there are scope additions and requirements not previously made known, but, but – this is the point – the delivery is still expected to the same quality, within the same budget and by the same date.
So not only was the plan optimistic, but even the agreed inputs to deliver it fail to materialise. It’s up to project managers to make sure plans are re-examined and re-baselined, and changes are controlled through traded concessions on time, cost and scope.
And that’s the third area where projects run into trouble (third after over-optimism and under-provisioning) – just not doing PM things. Of course, depending on the degree of novelty and the unknown, and depending on luck, projects can have serious technical issues. But I have found it far more common that they get into difficulties not because of the inherent challenge they are addressing, but more because of a failure to just do the basic PM things. Any ‘red’ (in trouble) project that one investigates is highly likely to get some crosses where there should be ticks in any checklist of good practice project processes, tools and behaviours. The answer is more likely to be there than that anyone is slacking or the challenge itself if just too great.
Some part of the work we do in knowledge management is about processes and services; and some part is about projects and change. If you don’t want your projects to be the ones blamed for failed performance then avoid over-optimistic plans (unless you accept the risks of playing that game); make sure the support and inputs required are always there, otherwise re-baseline and change control; and be sure to use proper project management skills, processes, behaviours and tools – they embody some of the best of re-usable PM knowledge after all, and wouldn’t you, as a KMer, want to use that?
And next time you hear that a deadline has been missed … consider whether it wasn’t the milestone that was set too early.
AI4KM - Robert Taylor 