I dislike the word “methodology” so much that I once had it removed it from my job title. Instead of “Head of PM Methodology”, I styled myself “Head of PM Excellence”. One sounds like a good thing, and the other doesn’t – wouldn’t you agree?
Nevertheless, “PM Methodology” is something that every project-driven organisation needs. In this blog post, I want to explore what it is, where it comes from, and why you need one. And also, what to call it.
The American Heritage Dictionary defines “methodology” in way that almost suits our purpose: “a body of practices, procedures, and rules used by those who work in a discipline”. But I prefer to think of it as “the way we do things around here”.
Sometimes I hear that organisations have adopted Prince2. Or PMI, or IPMA, or APM, or Scrum, or ITIL,… Well, good for you – but that isn’t the whole picture. These frameworks are great, and they come with books, training regimes and certifications. But they are generic, and not sufficient on their own. A project manager, no matter how trained, experienced and certified, still needs to know how to apply the methods in the context of the organisation – and each one is different. For example:
- what are the project governance processes and procedures?
- how are budgets obtained and managed?
- what are the reporting requirements?
- how are team resources assigned?
- are there mandatory templates for PM artefacts (e.g. Project Charter)?
- where are “lessons learnt” stored?
All of these, and more, need to be understood in order for a PM to successfully deliver a project. This constitutes the set of processes that are the organisation’s unique PM methodology.
The PM needs to understand the rules of the game within the project, and the external interfaces. Within the project there will be governance gates, reporting standards, terminology (possibly based on an industry standard) and mandatory templates. External interfaces may include the “rules” for engaging with Finance and Procurement, and the way to hand over to Operations.
The methodology needs to be documented and communicated to the PM community. This is the function of a PM Handbook. There was a time when it would have been a printed and bound physical book. I have seen some impressive attempts, but they are usually to be found in need of updating, and gathering dust on a bookshelf. A more “Enterprise 2.0” way to publish a PM Handbook is to use an on-line collaborative tool – perhaps based on a Wiki, Sharepoint, or process-management platform. In this way the Handbook becomes a living record of best practice, containing not just what has to be done, but also enriched with helpful hints and tips from the community. It is definitely not called “The PM Methodology”, but might be “The PM Handbook” or perhaps something more creative: “The PM Hub”, “PM Central”, “PM Community Site”, etc.
Things that I would expect to see included, as a minimum, are:
- Where projects come from: the initiation process
- Stage gates and governance bodies
- Corporate entities that must be informed or included: Security, Legal, HR, etc.
- How to get money and people
- How projects are managed, including project review processes
- Change control
- Risk management approach
- Project reporting
- How projects are closed
- Mandatory templates
- Optional templates
…and it needs to be accessible, concise and digestible. The role of a PM Handbook is not to teach someone how to be a project manager – they should already know that. It is the guide to “how we do things around here”.
The test of a PM methodology is this: Imagine you have a new PM joining your organisation. They are qualified, accredited, and experienced. Does your PM Handbook provide them all they need to know to deliver a project successfully in your environment?