Have you got an ‘ology?

“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:

Methodology

…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:

Methodology onion skin

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?

Best Practice

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.

By | 2017-03-07T08:24:13+00:00 October 22nd, 2015|Project Management|2 Comments

A Lesson We Still Haven’t Learnt

Without exception, in every organisation I have ever worked with, I have always heard it expressed that:

a) “We don’t do Lessons Learned very well,” and

b) “If only we could do it better, our project delivery would be more effective.”

It doesn’t matter whether you speak to project managers, PMO leaders or senior managers, the view is always the same. As a result, I have often been dragged into various initiatives to improve matters. My involvement has often been reluctant, as it is my view – which I have never hidden – that such attempts are doomed to failure! Why is this?

What most organisations regard as “doing Lessons Learned” is to build some sort of database in which the lessons are logged, tagged, categorised and organised. It might be a full relational database, an Excel spreadsheet, or a Wiki. But the result is the same: a “write-only” repository which starts off with good intentions, grows a bit, but is never consulted, falls into disuse, and eventually is abandoned.

I recently came across an organisation whose PMO function has a target of how many entries they can record in their lessons learned database per month. There is no measure of the quality of the entries, nor of their subsequent use or value to future projects. The result, of course, is to guarantee that the database continues to grow… continues to consume effort… and continues to provide zero value to the business.

And yet I also strongly believe that evaluating Lessons Learned is something that every project should do, because it contributes strongly to any organisation’s culture and future delivery capability. It isn’t the learning that I’m opposed to; it is the sheer wasted effort on what is often called (wrongly) a “knowledge database”.

Why we need to Learn from Experience

“Learning from Experience” (LfE) is the new and trendy name for “Lessons Learned”. It is a change that I definitely agree with, for two reasons:

  • It reflects what we are actually trying to do. To learn from experience.
  • It avoids the tedious and absurd debates over whether it should be “Lessons Learned” or “Lessons Learnt”!

The end-of-project LfE workshop presents the following opportunities:

  • To share experience, learn from what happened, and make improvements for future projects
  • To air any grievances or misunderstandings, and by doing so “wipe the slate clean” for the next encounter
  • To make recommendations for improvements to processes, systems and working methods
  • Team-building for future endeavours

Writing down the output and putting it into a (cough!) knowledge database is the usual outcome from such a workshop, but it isn’t where the benefit lies. The organisation’s real learning is in the heads of the individuals. Most of the same people will (hopefully) be working on the next project together or apart, and it is what they learn as individuals that contributes to organisational culture and improvement.

Unfortunately individual experience and learning is a rather intangible output, and certainly can’t be measured as a key performance indicator, but nevertheless it is at least 95% of the reason for holding an LfE workshop.

Actually there is a pragmatic way to record findings that apply to other projects, not involving a database. Do you use a risk register? Do you have a risk register template? Does it come pre-populated with common risks? If the answer to all of these questions is “yes”, then that is the place to put any relevant LfE findings. It pretty much guarantees that they will be in-the-face of the next project, without them having to interrogate a database. (And if the answer to any of the questions is “no”, my next question would be “why not?”)

How to hold a Learning from Experience Workshop

Here are some hints and tips for holding an LfE workshop, gained from my experience of participating in and hosting many such events.

  1. Hold it as early as possible in the project closure phase. Team members can start to escape quite quickly, and as soon as they are onto the next project they won’t want to give you any time.
  2. Make it clear to team members that their full participation is expected. No excuses.
  3. Allow plenty of time. At least half a day, possibly a full day.
  4. Hold it face-to-face and off-site, if possible. That way you get full engagement and fewer distractions.
  5. Use a neutral facilitator. The project manager is likely to be at the centre of the discussions, and is probably the least desirable person to have running the meeting. Invite another project manager (you can return the favour some time), a PMO member, or an external specialist. Commercial break: This is a service I provide. Can I help?
  6. If you have external vendors, invite them to participate, and ensure right from the start of the project that they understand that participation is expected – so that they don’t try to charge you for this variation to the contract. In any case, if they are expecting to work with you again, they should see the mutual benefit. But split the workshop into two sessions, part with and part without the vendors, so that your internal team can have a good moan!
  7. Instruct participants to prepare for the meeting in advance, by thinking about and writing down (a) what went well, (b) what went badly, (c) what to do differently next time.
  8. Invite the Project Owner to set the scene at the start, but then make it clear that they should make their excuses and leave. The discussion might be less inhibited without senior management present.
  9. Take the time to celebrate! If your budget allows (and you should really plan for this), invite the team out for a social and team-building evening immediately following the workshop. Ideally the Project Owner and Senior Stakeholders can act as hosts – and pick up the bill!

Possible Agenda

  1. Introduction from Project Owner.
  2. Brainstorm what went badly, what went well, and what could be improved next time. Do this under several categories, possibly by splitting into sub-teams. e.g. Overall project, Design, Development, Testing, Hand-over, Vendor Performance, Project Management.
  3. If you have worked in sub-teams, bring the teams back together and consolidate the findings.
  4. Summarise and record lessons and recommendations.

The LfE Lifecycle

When starting a project:

  • What do you bring to the piece? Based on your own experience, what do you expect to be the problem areas?
  • Speak to other project managers. What is their experience? What do they think you should watch out for?
  • Speak to team members. Have they done anything similar before? What did they learn from the experience?
  • Look at the standard risk register. What in there might bite you?
  • Consult the knowledge database, if you have one. It probably won’t help, but it can’t hurt.

During the project:

  • Record any lessons as they happen, so that you don’t forget at the end. If you maintain a project workbook, this is a good place to keep them.

At project closure:

  • Hold an LfE workshop.
  • Add any relevant findings to the standard risk register (via the PMO).
  • If someone is collecting contributions to the knowledge database, send them a charitable donation.

p.s. What about Agile?

Agile Scrum includes a Retrospective at the end of each Sprint. So the process has an inbuilt a continuous “inspect and adapt” cycle, which improves the capability of individuals and of the organisation. There is no need for anything else!

By | 2015-09-14T13:19:49+00:00 September 11th, 2015|Project Management|1 Comment

The Scrum PMO

The challenge is this: How do you make Agile Scrum work in a traditional corporate environment? The problem is simple to state, but the solutions are frustratingly complex.

I am a strong believer in Agile Scrum. I like the theory, and I have plenty of experience of it succeeding in practice (having served as a team member, ScrumMaster, Product Owner and as an agile coach).

The challenge

Scrum is usually represented something like this:

Scrum

 

Part of its power is the simplicity of the model. The Product Owner sets the priorities, the ScrumMaster coaches and facilitates the team, and the self-organising Team gets on with the work. It works very well.

Unfortunately large organisations now throw two huge spanners into the works:

  1. Governance. Meaning stage gates. Typically there will be a formal and complex corporate hoop to jump through in order to move between project phases (such as from “Feasibility” to “Detailed Design”, or “Alpha” to “Beta”, or “Planning” to “Delivery”). Such gates are likely to involve the very un-agile practices of baselining the project scope, plan and milestones.
  2. Management reporting. Senior folk like to know how the project is progressing against plan.

Both of these requirements are understandable in a command-and-control management structure, but they conflict with the agile philosophy. For organisations that are in transition from traditional to agile methods throwing them away is a step too far, so they remain as a necessary evil, and a potential source of friction for agile delivery.

A possible approach

A solution that I am seeing being tactically deployed by my current client is to put an insulating layer between the Scrum Team and the corporate governance layer. For want of a better term, this is referred to as a Scrum PMO (Project Management Office). The PMO can be a single person, or a small team.

Scrum PMO

 

The primary purpose of the Scrum PMO is to keep the corporate hassle away from the Scrum Team, so that they can get on with the business of being a high-performing team! There are two main interfaces shown:

  1. For Governance processes, the PMO represents the project. The overhead of preparing governance materials and attending governance boards falls entirely to the PMO. This can be substantial – including preparation of high-level project plans, scope documents, risk assessments, and whatever else is needed to feed the corporate machine. The PMO does this based on an information exchange with the Product Owner – but in a way that seeks to minimise the impact on the Product Owner.
  2. For Reporting processes, again the PMO represents the project and prepares all necessary management reports, including status reporting against the high-level milestones. Reporting is based on information received from the ScrumMaster, who should be preparing NOTHING more than one would normally expect in Scrum (such as burn-down charts).

The Scrum PMO can, of course, serve more than one Scrum Team:

Multi PMO

Hasn’t anyone solved this before?

The approach shown is very similar to that adopted by DSDM (Dynamic Systems Development Method) – the flavour of agile favoured by (for example) the APM Group’s AgilePM qualification. An excellent paper “The DSDM Project Framework for Scrum” can be downloaded from DSDM.org, and it contains this diagram:

DSDM scrum

Source and copyright: DSDM Consortium

 

 

Notice the “Project Manager” sitting outside the Scrum Team, whose role is much like the one I have described for the Scrum PMO.

Is this the right solution?

So far, in my experience, it seems to work – but the Scrum PMO needs to be seen as a transitional sticking-plaster solution. At the same time as ridding the Scrum Team of corporate tasks, overall it is adding significant overhead and bureaucracy.

Also, the insulating layer is removing senior management from direct involvement in the work of the teams – and in doing so, giving a false sense of security.

But it is probably no worse than the traditional approaches that went before, and if that is what it takes to enable Scrum Teams to succeed, then it is the right answer. For now.

By | 2015-08-19T11:24:44+00:00 February 13th, 2015|Agile, Project Management|6 Comments

We Need a PMO!

You know those dreadful surveys where management ask for staff feedback? Well once upon a time I worked in an organisation where the most frequent suggestion from the project management community was: “We need a PMO!”

So I set myself the task of trying to understand the request. What exactly were they asking for? What is a PMO?

Even the name is confusing. Is it a Project Management Office, a Programme Management Office, a Portfolio Management Office, or perhaps it is a Project Office or a Project Support Office?

Whatever it is, here, in alphabetical order, is the list of tasks and topics that I came up with, for things that it might do:

  • Ad-hoc support for project managers
  • Longer-term benefits realisation
  • Business case planning support
  • Coordination of communications
  • Change control
  • Dependency tracking
  • Project governance
  • Lessons learned library
  • Lessons learned facilitation
  • Management of escalations
  • Ownership of project management best practice
  • Planning, and planning support
  • Prioritisation
  • Project administration support
  • Project resourcing
  • Project start-up support
  • Project tooling
  • Quality management
  • Reporting
  • Risk management
  • Support for Project Owners
  • Training of Project Managers

The list drew on several sources: P3O, Good PMOProjectManagement.com, and my own experience. In this instance the focus was on “project” more than “programme” or “portfolio” – the inclusion of which would have given rise to a longer list.

There are two remarkable things about this list. Firstly, it is vast and varied (yet incomplete; I’m sure most readers will have spotted gaps and omissions). Surely no single PMO can cover all of this scope. But secondly, all of the items mentioned are valuable, or even essential to a project-driven organisation.

The reality is that all of these things exist in most organisations, but they don’t necessarily get parcelled up into a PMO. There might be a CTO office responsible for reporting and communications, for example. Project resourcing might be handled by a resource management function. And so on.

No two organisations are the same, and for this reason no two PMOs are the same.  I have learned that when someone asks me to help implement a PMO, a lot more exploration is needed to understand the request – because my understanding and experience of a PMO is likely to be completely different to theirs. Most importantly, they are likely to assume that I know what they are asking for – and I certainly don’t!

One of the fundamental decisions for a PMO is to decide who it serves. Who is the customer? Does it look upwards, serving senior management with reporting, tracking and escalation? Or is it there to support the project managers with best practice, training, and administration services? Does it carry a big management stick with which to beat the project managers, or is it the place that they come to for support and guidance? In practice it is probably some balance of the two, but that balance should be an explicit decision – which is then built into the PMO’s operation.

If I were drawing up the list now, I would add the following:

  1. Coaching of project managers. The PMO is a good place to coordinate a coaching programme.
  2. Establishing an Agile Scrum environment. For organisations implementing Scrum (as many are), the PMO can provide a useful function of insulating the scrum teams from corporate governance.

Returning to my story of the PM community that were asking for a PMO. On listing the functions, analysing the list, and presenting it back to the PMs, it turned out that my small “PM Excellence” team already provided about half of the functions of a PMO, although we didn’t call it by that name. About another 40% existed elsewhere in the organisation. In fact the only partially missing items were to do with PM support: admin services, start-up support, ad-hoc support. So what they were really asking for was a bit more admin support.

Did we meet their need? Well, partially. You know how big corporations are. But that’s another story.

By | 2015-09-18T13:09:43+00:00 January 16th, 2015|Project Management|0 Comments

Doing Less

I wish I could find the exact quote. Back in the early 90s, when I was using Prince 2 on several projects, there used to be a slim “Introduction to Prince 2” volume that explained you don’t have to do everything on every occasion. It said something like “the Project Manager needs to distinguish the essential from the merely important.”

At the time, I was really looking forward to the occasion when my Project Owner would ask me to do something, and I would be able to reply: “No, I’m not going to bother with that; it’s merely important.”

Alas, my Project Owner was far to sensible to request anything other than essential, but the phrase has stayed with me to this day.

The real sentiment behind the statement is that the PM should not be following the methodology blindly and by-the-book, but should be thinking about why the various activities are needed — what value they add — and adjusting them accordingly. Take reporting, for example. In many organisations, project reports are issued weekly. In some, they are issued fortnightly. In the former case, does the report add twice as much value compared to the second? If not, why spend double the amount of overhead on producing it?

It isn’t just the frequency of reporting that is an overhead; it is also the volume. I have known a few senior stakeholders who are genuinely able to absorb and respond to a multi-page report each and every week. Many more, however, only have enough time and attention to pick up on a few bullet-pointed highlights. So if that is your typical stakeholder, why write any more?

As Project Managers, we are an overhead. We may work hard in terms of hours and effort, but it is the team that does the real work. So the less time that is spent on project management, the better. Agile Scrum recognises this in the use of self-organising teams. There is no project manager, and no project management overhead. Project Managers are an endangered species in the Agile world.

Actually I don’t think the wider profession of project management is threatened by Agile, as there will always be essential (that word again!) activities that sit outside the Scrum team: portfolio and programme management, long-term planning, corporate governance, executive reporting. These are the domain of PPPM (Portfolio, Programme & Project Management) and the PMO (Project — or Programme, or Portfolio — Management Office). Our employment prospects are safe, even if we don’t retrain as ScrumMasters or Product Owners.

It is a sign of maturity and experience as a Project Manager that we prioritise our own time more effectively. Comprehensive methodologies such as those documented in Prince 2, PMI’s PMBOK, APM’s BOK, and others, are more likely to be followed as a “paint by numbers” exercise by those early in their project management careers. And a good thing too, as they contain a great deal of insight and best practice that provides a solid framework. Over time, we learn which things to leave out, and which to focus on – and that varies from project to project. The ability to distinguish the essential from the merely important comes with experience.

 

By | 2015-08-19T10:54:44+00:00 January 2nd, 2015|Agile, Project Management|1 Comment