“Methodology” is such a cumbersome term, and “Project Management Methodology” even more so. Yet most organisations seem to think they need one. Over the years I have been the keeper of a few of these beasts (although I always tried to call it something more interesting), and so in this article I’m going to explore what goes into a Project Management Methodology and why you might want one.
A good starting point is to look at the sort of thing that most organisations (in my experience) publish as their Project Management Methodology. It normally looks something like this:
…although in most cases there are more boxes than this, with much more complicated names. Even the gates tend to have strange names and numbers, like “Gate TR4A, Ready for Integration.” (TR4A is a real example, by the way, and I have never managed to find out whether they really named their gates after models of Triumph cars!)
This is, of course, a top-level process map. Each activity or gate will then be linked to a more detailed description, supported by check-lists, RACI matrices and templates. So, for example, the description of the “design” activity is likely to describe the outputs of this phase, which might include an architectural model, a functional description, a set of use cases, a security framework, a traffic model, and so on. Each of these in turn will have some guidelines and a template.
The gate descriptions will describe the gating factors: the things that the project needs to deliver in order to clear the gate. For Gate 1 these might be fully-approved (“signed off”) versions of the design documents, along with a resource plan and budget for the next stage.
The one thing that this “PM Methodology” fails to mention is project management! In fact, these sorts of processes are really development methodologies, combined with governance rules. This is no bad thing to have documented, and it is essential information for the project manager, but it shouldn’t be confused with a Project Management Methodology.
What is a Project Management Methodology?
According to my Concise Oxford Dictionary, a methodology is a “body of methods used in a particular branch of activity”. And the corresponding definition of “method” is “special form of procedure”. So a Project Management Methodology is a collection of procedures used in project management.
Companies like to have their preferred in-house body of methods, and I like to think of these as simply: “the way we do things around here”. The contents of such a methodology can include any of the following:
- A framework, or project management approach, which is often aligned to or adapted from a recognised industry standard: PMI, APM, Prince2, Agile Scrum, etc.
- A standard terminology, which often comes from the framework itself. This is important in order to avoid confusion between terms such as Project Mandate, Project Charter, PID, etc.
- Specific guidelines on mandatory project management methods and artefacts, such as the need to maintain an up-to-date risk register, reporting formats and frequency, project planning rules (e.g. how to handle external dependencies).
- Templates for standard artefacts; most commonly status reports, risk registers, project plan.
- Tooling, such as SharePoint, portfolio and governance tools, reporting tools.
- Governance guidelines and rules.
These, and more, can be thought of as the onion-skin layers that surround the project manager:
At the centre sits the Project Manager. They bring with them their own unique set of skills, experiences and qualifications. They then operate within a framework, which may be unique to the environment, or more likely is based on a well-known approach such as Prince2, ISO, APM, PMI, Agile Scrum, DSDM, and so on.
Each organisation then has its set of rules and guidelines. These cover essential information that the project manager needs to know, such as: “How and when do I submit status reports?”, “What quality controls apply to my projects?”, “What mandatory artefacts do I have to maintain?”, “How do I secure project resources?”, “Who has to approve purchase orders?”. In a mature project management organisation these guidelines are written down in some form of Project Management Handbook (usually an on-line tool rather than a physical book), but sadly they are often assumed knowledge that the PM is expected to acquire through osmosis!
The guidelines are then supported by tools and templates. Tooling covers on-line storage of project documents (e.g. SharePoint), reporting tools, governance tools, etc. Templates should cover all project management artefacts such as the project plan, the risk register (or RAID), the status report, the Project Charter/Mandate/PID, etc.
Finally the outermost layer is the governance structure that the project needs to operate within. Governance is usually either the responsibility of the PMO, or of a separate governance function. They will lay down the rules and structure covering:
- What are the governance gates?
- What happens at a gate review?
- When are they held, and how does a project get on the agenda?
- Who attends, and what authority to they have?
- What needs to be presented at each governance gate?
- What exactly does a governance decision imply; what delegated authority does it give to the PM?
- What exceptional procedures exist if a project is going off track, and how are these triggered?
Whether it is formalised or not, all organisations must have some sort of approach to how their projects are run. Many will have some form of Project Management Methodology, but often this only covers a few of the topics that I have described. It is quite common to confuse project management with governance, and to only describe the governance gates.
Best practice in mature project management organisations is to have a Project Management Handbook (as an on-line resource, naturally) that covers all levels of the onion skin, from the framework, guidelines and templates up to and including governance.