Project Management Methodologies are a great rationale for inactivity, wondrous progenitors of inertia, magnificent justifications for procrastination and tremendous excuses for blind adherence rather than thought. They can also lend a fine, glossy sheen of order to chaotic realities.
Project Management Methodologies such as Prince2 and the PMI Project Management Body of Knowledge (PMBOK) are codifications of good practice. They formalise what has been found to work well. Being clear about a project's scope and objectives before starting it is, I suspect we would all agree, quite a good idea. So the "Project Charter" or "Project Initiation Document" (PID) is born in which one documents the scope, objectives and other key information about the project one is to undertake.
If you were the sponsor of a large project outsourced to a third party you (the customer) might think it a good idea for the top brass from the supplier company to meet every now and again with you and someone from your company who is in close touch with your (the customer) company's needs. This group comprising senior supplier, yourself, a senior customer and the project manager might even be given a name: the project board.
And who can argue with the idea that one should try to foresee what might go wrong during a project and try to pre-empt those problems or perhaps put some money in the budget to deal with them if they occur?
And one could go on to list in this common sense fashion many more things one should "obviously" do when running a project, and one could make a very reasonable case for writing a guide describing this good practice to assist future project managers.
So far all very sensible. So where does it all go wrong?
Well, first, the fact that good practice is written down somewhere does not mean that anyone will actually follow it.
But that problem can be addressed by training, can't it? You send everyone on a course that teaches them the contents of the project management guide - now called a method or methodology as it sounds posher - and set them an exam so they can prove they have memorised the book. And suddenly they're "qualified" project managers! (Oh yea?)
But at least they have learned the terminology and some project management processes. The next problem is ensuring
they use those processes on their projects. Easy: set up some sort of review process to ensure all projects follow the
methodology. It's not difficult to ask the project manager: "is the project board in place comprising senior customer,
senior supplier, project executive/sponsor and project manager?" and easy for the project manager to show the PID
which lists a name beside each of those four role titles.
Pretty soon everyone in the organisation knows you have to have a PID if you want to do a project and if you don't have one the assurance guys will be all over you.
So you hear people saying: "I want to do such-and-such, can you go and write a PID for it?" And someone goes off, finds the PID template and fills in the boxes with things such as the names of the people they think would be good as senior customer, senior supplier or whatever, show the PID to project assurance who check all the boxes have been filled in and everyone is happy. The fact that these role players haven't even been consulted is neither here nor there. Anyway, they'll find out they have the role when they get their copy of the PID. And when the PID is published everyone takes issue with it and round and round we go.
And if the methodology says you should have a project board and your PID says you will have a properly constituted project board of senior customer, senior user etc, will the assurance guys challenge you and say you shouldn't have a project board? Not in a million years! The fact that such a board happens to be a complete nonsense for your project is irrelevant. No-one is thinking any more, we're just following the methodology like so many Daleks.
And, believe it or not, in this scenario we were very lucky: we had a proactive project manager who at least got on with it and got the PID written.
Had we been unlucky our project manager would have said: "I can't write the PID until you give me a project brief and then I can't write it until... etc." And you get a million reasons why the project management process means that little or nothing can be done.
If you really want to upset a dynamic executive try this. He asks you to get something done for him. Your reply is to list a dozen documents you will therefore have to write before you can even start to do what he asked you to do. (Though don't worry, organisations that are hidebound by project management methodologies tend not to have too many dynamic executives within them.)
The picture is pretty clear: a good idea turned nightmare - the road to hell is indeed paved with good intentions.
We have painted a black picture of an organisation that is slave to the methodology; the methodology inhibits, smothers, misleads, misinforms. How do we achieve the good news outcome, one in which the project management method enables, guides and assists?
It starts with the training. Rather than training people to memorise a methodology manual project management training should teach what it means to manage projects. This is more difficult.
Rather than project managers using the project management methodology manual as a set of proscriptive procedures to be followed unthinkingly, they use the manual as a guide to inform them, a set of tools from which they can select. The fact that something was good practice on one project does not necessarily mean it will be good practice on another project. Project managers take charge, they make decisions - they manage rather than simply administer a process. This is more difficult.
Project Assurance should not be about checking boxes have been filled in, it should be about whether, in project assurance's judgement, a project has been adequately defined and planned; are the roles the project manager has defined appropriate for the project and have role players understood and agreed to them. When validating project status, assurance do not simply look to see if the right forms have been filled in. They have to assess the actual health and likelihood of success of the project. All this requires experience, judgement and the expressing of a challengeable opinion. This is much more difficult.
Rather than using a standard methodology manual as the organisation's project management process, the organisation writes its own set of project management standards which are broken into two parts: rules and guidelines. Rules are mandatory, guidelines are optional. And, by the way, one rule would be that there must be a project sponsor/executive and a project manager. A guideline would suggest when it might be appropriate to have a senior supplier joining the sponsor and project manager to form a project board. The rules and guidelines can be consistent with a methodology such as Prince 2. Writing one's own set of rules and guidelines is more difficult than adopting a methodology manual as is.
Clearly, all this requires an understanding of what project management methodologies are driving at and the adoption of the underlying spirit rather than the bureaucratic veneer. Yes project managers need training, yes project assurance policing is needed, yes there must be mandatory processes - but all of these things should have the aim of maximising the chance that projects will actually get done effectively and efficiently rather than maximising the appearance of order by imposing a uniform blanket of non-functional bureaucracy.
In our project management course, now available free in book form, we teach project people what project management is really for: to help them get things done. We describe how documents such as a PID should be like meeting minutes: when you've decided what you're going to do and got agreement, write it down. We cover how Project Assurance should help project managers make informed decisions on things like appropriate roles and appropriate controls for their project. We describe how project health checks - as opposed to bureaucratic compliance checks - should be run. We describe how to set up and operate controls that actually help the project manager run the project. And much more.
Management Book is essentially the text of the project management course and is a comprehensive
and practical guide for new project managers. More experienced PMs will also find some useful things in it.
Project Management in the Public Sector
So You Want To Be A Project Manager?
Risk Management in Software Development Projects
Quality Management in Software Development Projects
The Tale of Three Project Managers
Towards a Project-Centric World
Project Management Proverbs
I.T. Project Management Book
Copyright M Harding Roberts