Why a project manager is like the conductor of an orchestra

Here’s an incredibly easy question that many people get wrong.

Question: What is a project manager? 
Answer: Someone who manages a project.

Many projects and many companies get this question wrong. They don’t understand the project manager role. They think that the project manager delivers the project. They think the project manager is a “doer” not a manager.  They hire technical specialists as project managers and ask them to get stuck into the technical work.

Let’s be clear: The project manager’s role is to MANAGE the project. He or she is primarily a manager. Any technical expertise is useful but secondary.

Prince2 is clear about this. Prince2 has a well defined project organisation, in multiple levels

    1.    At the top level is the Project Executive (sometimes called Project Sponsor or Project Owner) and the project board. This is the level which takes decisions and assumes accountability.

    2.    In the middle is the Project Manager, who manages the project day-by-day and coordinates the specialist work.

    3.    At the third level are the Project Teams who do the specialist work and need technical expertise.

For Prince2, the project manager is like the conductor of the orchestra.
    •    The conductor doesn’t make music;  s/he coordinates the musicians.
    •    The project manager doesn’t deliver the project’s work;  s/he organises the work

For Prince2, a key task of the project manager is to package up work and give it to the teams.

It’s like a handshake. We need agreement between the project manager and the team manager on the work to be done

    •    The Project Manager proposes a “Work Package”
    •    The Team Managers proposes a Team Plan to deliver the Work Package

Once they are agreed, the work can start.

And once the work does start,  the project manager has to follow up on progress.  The project manager has to MANAGE progress, without being too “hands-on” nor too “hands-off.”

    ❑    If the project manager is too hands-on, s/he wastes time (and often ends up doing the work rather than managing it)
    ❑    If the project manager is too hands-off, s/he may lose control (and fails to manage)

To manage correctly, the project manager should review the work package status regularly at periodic “check-points”. A check-point isn’t a long and boring weekly status meeting. Prince2 avoids “management by meeting” which is time consuming and ineffective.

A check-point is a regular event, typically weekly.
    •    A written status report
    •    A meeting (optional)
    •    Follow up

A check-point should always start with a written status report. It’s important that the status report is written, and it’s important that the project manager gets it before the meeting. This allows the meeting to be a short-and-sharp meeting - the Project Manager can focus on a few key points from the written report. This is “management by exception”, which saves time and helps to ensure that the Project Manager is focused and effective.

The team’s checkpoint report is structured into
    •    what the team has done in the current week
    •    issues
    •    what the team expects to do next week.

Let’s look at an example. Perhaps a team manager sends a Check-point report every Thursday to the Project Manager. On the Friday, the project manager might discuss with the team manager (face to face, or by phone, by instant message…):
    •    two tasks which were not finished on time
    •    one issue which looks worrying
    •    one task which must be planned for next week

The Project Manager focuses on a few exceptional points rather than on the broad status. It’s management by exception. The Project Manager is a manager, and doesn’t need to control everything in fine detail. In some projects, the Project Manager may need strong technical expertise in order to define Work Packages; and may even directly manage one or more teams. But the key task for the Project Manager is to manage.

So now we have the right answer to the question “What is a Project Manager”. The answer is simple with Prince2. The project manager is … a manager.

Size matters: when should big projects become programmes

Some project managers still like to use the old “rule of thumb” that a project shouldn’t last more than 9 months. This is project management folklore. If a project is longer than 9 months, says the old folklore, then it is likely to fail. So best split it into pieces.

As with much folklore, this “rule of thumb” contains some wisdom, but it’s not rigorous and proven. Methods like Prince2 help to show that project length is only one factor likely to cause project failure. A 9 month project can fail for many, many reasons (as can a 3 or 6 month project);  whereas a  2 year project which is correctly managed can succeed (and many do)

More importantly, the old rule ignores the emergence over the last 20 years of programme management. Programmes are used for handing major initiatives and business changes, and typically take years rather than months.

Does the old rule of thumb maybe need to be rewritten? Should it say “if your project will take more than 9 months, then run it as a programme”?

Let’s consider some of the main differences between a project and a programme
    ❑    A project focuses on deliverables, and is generally shorter and more structured
    ⁃    When the deliverables are in place, the project is finished.

    ❑    A programme is a longer initiative, which often more flexible
    ⁃    delivers one or more strategic objectives
    ⁃    focusses on delivering change - when the benefits from the change are in place, the programme is finished

This tells us that the differences are not due to the length of the project or programme. More important is what it delivers: the vital difference between programmes and projects relate to the nature of the change, not to the duration of the change initiative


One simple way to understand whether to use project management or programme management is consider the nature of the change
    ❑    Project management is good if you are changing things (or making new things)
    ⁃    software and web sites
    ⁃    new or improved products
    ⁃    new IT infrastructure
    ⁃    buildings, roads

    ❑    Programme management is better if you are changing people (or their way of working)
    ⁃    restructuring, reorganisation
    ⁃    new processes
    ⁃    better ways of working
    ⁃    globalisation
    ⁃    expanding, downsizing, outsourcing, off-shoring


So that old “Rule of thumb” is a nice proverb. Like all proverbs, it seems right at times, but often it’s wrong and misleading. Better in today’s world to use another rule of thumb: “If your project will take more than 9 months, attend a course on programme management”.

Aim high to build a high performance team

In today’s fast moving world, most organisations have a large change agenda. Do you have more projects to run than people to run them? Are you forced to use inexperienced staff to run key projects?

One response to this challenge is to look at best-practice frameworks like Prince2 for Project Management, or MSP for Programme Management. But it’s important to set the right goal.

When you start to deploy a best practice framework like Prince2 or MSP for your team or company, you should set the goal high. You want a high performance team, not just a few star performers. If you create team-wide strength in project management, you can really start to deliver your organisation’s change agenda.

Some organisations hesitate to standardise on a framework like Prince2; perhaps they train a few people, but they don’t roll it out to everyone.

They are missing the benefits of a generalised solution. The way to get full benefit from a framework like Prince2 is to generalise its use.

There are three reasons why you should widen the rollout of a framework like Prince2 or MSP:
1) each framework is relatively simple to learn so training is short and relatively cost effective
2) a framework provides a single point of truth to unite the team
3) a framework helps your organisation to improve and innovate.

Let’s look at those points

1) Speed: Learn in a week

All the best practice frameworks  from OGC (Prince2, MSP, MoP, P3O, etc) are reasonably simple to understand. With a week’s training, you can understand the key concepts, pass an exam and get a basic understanding of how to use the framework.

At the team or enterprise level, this means that all your team can learn your method. You can train them all. This is a key to success.

2) Single point of truth

If your organisation uses a framework such as Prince2, you have an external reference.

There are thousands and thousands of books on Project Management. Every author has his or her own ideas. If you don’t have some reference point for your organisation, every Project Manager will have his or her own ideas.

Prince2 has condensed a huge diversity of opinion into one book, which covers a major part of Project Management. That means that an organisation which adopts Prince2 has started to simplify its Project Management problem. With Prince2, you start to introduce a single vocabulary, a single point of view, a single intellectual framework. That’s significant added value, and a second key to success.

3) Improve and innovate

Don’t be worried by Prince2’s apparent complexity. Treat it like a supermarket which stocks 10,000 items, but you only need a week’s groceries. It up to you to choose. You can adapt Prince2 to your needs. This is what Prince2 calls “tailoring”.

If you tailor Prince2 with intelligence, it becomes a springboard to innovation. It becomes easier to implement, easier to use, and easier to adapt to your business needs.

You should start with the standard framework of Prince2, then simplify in order to implement it. If you hit barriers to implementation, then simplify it further. (That’s quite normal - the first simplification is never quite enough!). This simple core is your starting point. It’s your foundation for building team-wide high performance.

As you continue, you can build on this foundation. You have focussed on the essentials of your project management problem. You have  a basis for continuous improvement, for further innovation. And that’s your third key to success.


That’s three keys to success to building in-depth strength, and a high performance team. You need to aim high to increase your project capacity, and to meet the challenge of delivering an ambitious change agenda. Aim high, deliver high performance.

Mapping the future, mapping the past

 This is about understanding the past. It’s a case study, but it’s more than that. It’s about how we can better understand the past if we have a frame of reference.

The case study explains how a large company improved its project & portfolio management.

This multi-national organisation was structured as 7 business units. They had an ambitious change agenda. To deliver this huge amount of change, they needed to improve their project management.

They ran a 3-phase improvement initiative to improve project management
    ❑    Phase 1 introduced Prince2 project management, supported by heavy-duty EPM tools (Enterprise Project Management software)
    ❑    Phase 2 measured regularly the improving maturity, by measuring the use of Prince2-based methods and the tools. With these measures, they found the weak spots, and took corrective action
    ❑    Phase 3 introduced portfolio reporting. It started once the level of maturity of Project Management was acceptable - it needed good quality project data as the starting point for consolidated portfolio reporting.

We can understand this case study in terms of P3O. That will be our frame of reference. P3O  provides organisations with a top-down approach for improving their P3 (P3 stands for projects, programmes and portfolios). The O stands for Offices, so P3 + O gives P3O.

So let’s use the P3O framework.  How does this case study look in P3O terms?

Retrospectively, we can detect the gradual construction of a P3O model, as the 3 phases advanced
    ❑    Phase 1. Local CoE functions were set up (Centres of Excellence) supporting the deployment of Prince2.
The local CoEs
    ⁃    published standards, procedures, templates
    ⁃    provided training, coaching
    ⁃    ensured tool support
    ❑    Phase 2. A centralised the CoE function emerged. The local CoEs were merged into a single unified CoE.
The central CoE
    ⁃    measured the maturity of Prince2 and tool using with a P3P3 approach (P3M3 is a maturity model)
    ⁃    provided an Information Portal with standards, procedures, templates, etc
    ⁃    continued to provide coaching to teams with low maturity
    ❑    Phase 3. A Portfolio Office structure was deployed, with a central Organisational Portfolio Office managed by a senior manager.
Each Portfolio Office
    ⁃    introduced Portfolio Design - budget management, demand management, resource optimisation, portfolio optimisation
    ⁃    coordinated Portfolio Delivery - monitoring and control of projects, data consolidation, status reporting

This provided the foundations for solid Project Management.
We can see that the P3O support was a key enabler
    ❑    The P3O structure was a key enabler of for project management.  Without support from the CoE structures, this major Prince2 and tools deployment would not have succeeded, and the high maturity levels in Project Management would not have been achieved.
    ❑    The P3O structure was also an essential enabler for Portfolio Management structure. Without the Portfolio Office, the ambitious work to structure Portfolio Management would not have progressed. It was beyond the reach of the business managers responsible for the portfolios - the support of the Portfolio Offices in the P3O model was vital.

By looking back at the past, we learn lessons by finding a good frame of reference.

Now look forward to the future. To improve your organisation’s project management, use a good frame of reference. Try using the P3O framework to map out the future.

Why the Project Manager is a Time Traveller

In the popular Science-Fiction film, “Back to the Future”, a mad scientist makes possible time travel. Marty, the film’s hero, can travel to the future. In real life, we can’t travel to the future, but we often need to imagine the future.
The project manager (and programme or portfolio manager) is a change agent, who will change or innovate, to build a different future. The project manager’s job is to imagine a new future and how to get there. We travel to the future in our imagination.
So the Project Manager imagines the future, and converts it into a plan. A good project manager will spend a lot of time planning, which is almost “living in the future”

• planning the journey to the future (how to get there)
• planning the destination (what the future will be like)

The experienced Project Manager is constantly thinking weeks ahead … imagining what will happen next week, next month, next year. That’s a key characteristic of a good Project Manager.
Planning can be a major, time-consuming activity for the Project Manager. If done wrongly, the Project Manager can waste much time on planning, as one plan gets replaced by the next and then the next...
To plan effectively and avoid wasted time, methods like Prince2 (for Project Management) and MSP (for Programme Management) can help enormously.
Three key strengths of the Prince2 approach to planning are:

1. Prince2 starts the planning process with Product Based Planning. You start with the “What” (your deliverables, which give a picture of the future) before the “When” or the “Who” (which tell you about the journey). Product Based Planning generates more robust plans, which are easier to understand and maintain.
2. Prince2 has three levels of plan - project plan, stage plan, team plan. This reduces complexity, and aligns planning to the team structure.
3. Prince2 uses just-in-time planning - as the next stage approaches, the stage plan is created. This avoids the need for a hard-to-build and hard-to-maintain mega-plan for the entire project.

MSP has a similar approach :

• MSP separates the picture of the destination (the Blueprint) from the journey (the Programme Plan)
• MSP has several types of plan - programme plan, project plan, transition plan… This is aligned to the programme organisation, and avoids building one hard-to-handle mega-plan

Planning is important. As project teams move to “light” forms of Agile, some fall into a trap. Essentially, they move to “discovery mode” and stop planning. The daily stand-up meeting can’t replace a plan, it’s too focussed on the present, not the future. Planning is not optional. As the old saying goes “If you fail to plan, you plan to fail”.
So make sure you are a time traveller. Spend time in the future, and build your plan. Then use it. As the other saying goes “Plan your work, then work your plan”.

"Prince or Agile?" is like "Hammer or Screwdriver?"

All around the world, the Prince2 project management framework is growing in popularity, but a new challenger, Agile, has appeared. So we are starting to hear a debate “Prince2 or Agile?”.

That’s an interesting question, but often it’s the wrong question. If you are starting a home improvement project, you don’t ask “Hammer or Screwdriver?”
- You probably need both
- You need to know when to use each tool
- You need to know how to use each tool correctly

The same applies to Prince2 and Agile. A mature organisation will have both methods in their toolbox, and will skilfully use the right tool at the right moment.

So if we might need both Prince2 and Agile, how do they compare as tools?

We need to compare like-for-like, so the starting point is to find the right Agile. There are many variants of Agile, many of them lightweight variants such as SCRUM and XP. These lightweight variants are not full-scale project management methods, they are used by teams to manage parts of projects, mostly the IT parts. A heavyweight contender to Prince2 is Agile ATERN (also known as DSDM)

Both Prince2 and Agile-ATERN are fully-fledged project management frameworks. Both are general purpose methods. Both are enterprise-ready with a focus on value-for-money, on control, on quality, and so on.

Which one to choose?
* Prince2 is the better choice for specification-driven projects
* Agile ATERN is the better choice for discovery projects
* Agile ATERN is great for deadline-driven projects

The type of project helps you choose your method:

• Specification driven means you start off with a written document (and probably with a contract)
• Discovery projects have only the essential needs decided up front
• Deadline-driven projects must absolutely deliver on time

But you don’t always have to choose. It’s not an “Either-Or” choice. Just as ATERN has integrated ideas from Prince2, so you can make Prince2 more Agile

Here are some ways that you could make a Prince2 project more Agile:
- use your first stage to build a “kleenex” prototype (limited functionality, simulate the real solution)
- use a pilot stage (limited deployment, get something working and into daily use)
- use time-boxes (have zero time tolerance for a stage, but high scope tolerance - if you are running late, reduce scope)
- start your day with stand up meetings (e.g. project manager plus team managers)
- use “Enough Design Up Front” (EDUF) not “Big Design Up Front” (BDUF) by finalising your product descriptions at the stage boundary (rather than on the PID)
- for a work package where you need a discovery approach, use a lightweight Agile method such as XP or SCRUM

So just as it’s not “Hammer or Screwdriver” for your home improvement project, so it’s not “Prince2 or Agile” for your company.

Just as you need a Hammer and a Screwdriver at home, you may need Prince2 and Agile at work. The way forward is to have both tools. If you are using Prince2 today, you should start looking at Agile ATERN.

How MSP helped a tiny organisation... to survive

There is a growing understanding that Programme management is vital for big organisations. Methods like MSP are increasingly used by big organisations for major transformational programmes like
    •    company mergers
    •    business reengineering (e.g. ERP or CRM rollout)
    •    launch of new products, services or markets
    •    public sector reorganisation
    •    major sporting events which help regenerate run down urban areas

But it’s less well understood how a method like MSP can help small organisations or small teams.

Small organisations can face for the same need for transformational change as big organisations.

So let’s look at how very small voluntary sector organisation has benefited from MSP over the last few years. The organisation is indeed small, with only 5 staff. But from 2005, it identified some big problems… which could have threatened its very existence.

It’s a publicly funded organisation, and the management team saw that it was not delivering value for money to the funding bodies. It was time for change, time for transformational change, time to apply some MSP best practice. Otherwise, in today’s difficult times, the funding would have been cut, and the very future of the organisation put at peril.

Here’s three of the ways that MSP helped this tiny organisation to re-invent itself... and survive!

1) Develop a vision to drive the change: since end 2008 a vision statement has been in place. The organisation must change over the coming years. It must reinvent itself.

The vision statement explains where things are heading and helps to guide the change. At various annual meetings (AGM, board of control), the vision has been explained and agreed. This is the MSP way - build consensus for change, starting with a vision.

2) Analyse the stakeholders: from 2005, the organisation started to look at the funding bodies as stakeholders, not just as sources of income. MSP helps you to get a 360° vision, to view your situation from the point of view of the stakeholder. With MSP you seek to understand their interests, and to work out how to engage with each stakeholder.

3) Build a project dossier, run the next tranche: In 2010, by looking the stakeholder interests of the major funding body, the organisation identified several options to provide stakeholders with better value for money. One was an outreach project, providing services in a wider geographical area. Another project was educational, targeting 11-15 year-old school kids.

In MSP terms, this was a part of the project dossier, to be rolled out in the next tranche of the programme. Once the tranche plan was agreed, the projects were launched. Soon the outreach solution went live, and by 2011, the benefits were clear and measurable. The outreach was working in 12 towns. Equally, the educational project as fine - the schools were happy.

This tranche delivered clear benefits to a key stakeholder. The story continues today - additional opportunities, follow-up projects in more schools, new projects in the 12 towns… the new tranche is under way.

So we have seen three of the ways that MSP has helped a tiny organisation to reinvent itself. MSP can help your small business or your small team. It’s not just for the big guys!