Learn from Lean: use Collaborative Design for faster and cheaper projects

 When should a project manager plan to use the project budget? Should you keep a lot of budget in reserve for the last part of the project, to fire-fight problems? Intuitively, the answer is YES.

But the answer from Lean is NO. You should invest up-front in Collaborative Design. You will have fewer fires to fight. This article explains why.

Collaborative Design in Lean Manufacturing

Lean Project Management is based on Lean Manufacturing. Lean Manufacturing was pioneered in Japan by Toyota and Honda. Collaborative design was an integral part of the success of Lean Manufacturing.

It’s often hard to transfer concepts from Lean Manufacturing to Lean Project Manufacturing. But in this case it’s easy, because Collaborative Design comes from Lean’s new product introduction: for automobile manufacturers, introducing a new car is a project. Toyota and Honda pioneered Collaborative Design to optimise their project success.

It’s explained in the excellent book The Machine that Changed the World : the Story of Lean Production by James Womack et al.

In the best lean projects, the numbers of people involved are highest at the very outset. All the relevant specialities are present, and the project manager’s job is to force the group to confront all the difficult trade-offs they’ll have to make to agree on the project. As development proceeds, the number of people involved drops…

In many mass production design exercises, the number of people involved is very small at the outset but grows to a peak very close to time of launch… to resolve problems that should have been cleared up in the beginning.

The budget is spent very differently in Lean: it’s spent upfront. Whereas in Mass Production, it’s saved for downstream trouble-shooting.

Let’s draw this as a graph. Let’s compare two projects which have the same budget in man-days (effort). We see that the two graphs of effort against time are very different.

Collaborative Design drives project success. The authors quote some figures:

• cheaper: a nearly two-to-one reduction in effort
• faster: a saving of one-third in time

Collaborative Design in Project Management

Let’s bring this back from automobiles to project management.

A lot of projects follow the same curve as Mass Production. Planning is largely a solitary activity, mostly done by the project manager. Resources are added down-stream to firefight problems late in the project.

Collaborative Design brings together the key stakeholders (such as work package owners, subject matter experts and users) ...

Read the rest of the article here

•  to see other comparative graphs 
•  understand the three features of Collaborative Design
  

Use recipes to bake better projects

Are your projects unpredictable? Maybe they are a bit like my mother’s cakes!

Better cakes, better projects

My mother wasn’t a great fan of recipes. She had some cookery books, but didn’t always use them. She often baked a cake without using a recipe. Consequently, our family had some great cakes, but also a lot of middling cakes, and a few disasters. Unpredictable.

Does that sound familiar to project managers? Your projects may be a similar mix - few great projects, a lot of middling projects and some disasters.

If your baking was unpredictable, how would you improve it? You would need to start using recipes. And start taking notes on each recipe: “the oven should be at 200°C not 180°C”; or, “this recipe would be better with two eggs". Those notes help you tweak the recipe to improve the result. So next time you bake, try using two eggs. Or try baking at 200°C

To improve your projects, you need the same approach. But we’ll talk about processes instead of cake recipes. And we’ll need continuous improvement, instead of tweaks.

The objective is to get your projects under control. You need defined project management processes (your recipes), and you need feedback from real-world projects (that’s your notes suggesting tweaks). Then test out the revised processes in the next projects. That’s a cycle of continuous improvement.

click here to continue reading about 

• Donald J. Wheeler's Four States of Control

• W. Edwards Deming's SDCA cycle

• My recipe for baking better projects

When standard Project Management life-cycles are surprising

A few years ago, I created a project management software package called TrioProject. The package was quite good, but it had a major flaw. It used a Gate process approach, which was good. But it standardised the Gate processes… and to my great surprise, that proved to be a weakness. The standardised life-cycle was the flaw.

It came as a surprise to me, because I've been working on project management standards for decades. It was clear to me that, to improve project management, you need standards. But you have to standardise the right thing. If you over-standardise life-cycles, you are in trouble. I was in trouble.

I'm not the only person to make this mistake. Often, when I talk to PMOs, I discover that they've made the same mistake. I learn that they have a standard life-cycle such as 

• Charter
• Initiate
• Build
• Test
• Deliver and Deploy
• Close

So let's unravel this problem. Where did I go wrong?

A mixture of good and bad ideas

My first good idea was to use a Gate process. The Project is structured as a series of Stages, each separated by a Gate. This is a proven way of working. It splits the project into manageable chunks of work (stages). It allows the project board to control progress (gates).

My second good idea was to standardise the process. In this way, all projects follow the same path. This standardisation enables repetition, which is the basis for continuous improvement.

The flaw - my bad idea - was to over-standardise the process. Every project is different. So a standard life-cycle is overkill. It's a bad idea. The diversity of projects is enormous. In reality, many projects cannot and should not follow a standard process.

When standards become a problem not a solution.

Once you start down the wrong path, standards become a problem not the solution. If every project has to use a standard process then people hit problems:

• The process doesn't fit the project (square peg in a round hole)
• The project manager applies the process blindly, without enough thought

Some companies address these problems by multiplying the number of standards.

• One company used different life-cycles for different sized projects (small, medium, large).
• A building company used 3 standard processes, for construction, renovation and maintenance projects.

But multiple standards only complicate the problem, they don't solve the problem.

Faced with these problems, other companies give up on standard life-cycles.

How to ensure that standards are good news

The answer is not to reject standardisation. Standardisation is the foundation of continuous improvement and better project management.

But standardisation must recognise that each project is different:

• Yes, it's a good idea is to use a Gate process.
• Yes, it's a good idea to standardise the OVERALL process
• BUT it's vital to understand that each project is DIFFERENT

The way to achieve this is to use project design. For each project, the delivery must be designed, not standardised.

Delivery needs to be designed (not standardised)

Each project is different, and each project needs to be designed.

Project design is an early project activity which works out how to deliver the project. The project team works out how many stages are needed, and what those stages are.

That's the big challenge: every project must deliver differently.

During project design, the project team analyses project delivery and structures it appropriately. They understand their unique challenge, and design their unique solution.

So that's the source of the flaw in TrioProject. It was a mistake to over-standardise project delivery. You cannot decide in advance. Delivery should be DESIGNED and NOT STANDARDISED.

A sandwich of standardisation

The resulting standard project management life-cycle is a sandwich

• standardise the early parts of the project
• design delivery (recognising that each project is different)
• standardise the final parts of the project

This still provides the basis for a repeatable life-cycle. It allows for enough standardisation to enable continuous improvement.

Read my recent book to find out more about Project Design; and learn how to design your next project.

Traps to avoid

Before we finish, here is a reminder of the traps to avoid:

• don't standardise the number of delivery stages (for example 3 delivery stages)
• don't standardise the names of delivery stages (for example analysis, build, deployment)

A small project might need only one delivery stage. A larger project might need five delivery stages. A second large project might need five completely different delivery stages.

Build the Project Factory

To sum up, we standardise project management to give a basis of repetition. Standards provide the foundation for continuous improvement and for building a project factory.

But we also recognise that each project is different. We need to reconcile standards and flexibility.

In a forthcoming blog, I'll say more about the Project Factory. Watch this space.

Ignore the fashionistas: you still need Prince2 in an Agile world

Fashions come and fashions go. For fashionistas, yesterday’s fashions are history. 

In the world of project management, Agile is the current fashion, particularly the Scrum variant of Agile. If you browse many project management websites, you'd think Scrum has become the only way to run projects.  Some Agile fashionistas even suggest that everybody is moving to Scrum, and that “traditional” methods like Prince2 are history.

What should project managers do? Should you follow the current fashions? Or is there still life in older methods like Prince2?

A success story…

There’s a good reason why Scrum is fashionable - for many teams, it's a success story. But if we pause to understand the roots of that success, then we will find that not everyone can go with the crowd and follow the latest fashion.
The popularity of methods like Scrum is driven by two waves of innovation

❑  the rapid, unrelenting growth of the Internet
❑  the increasing incorporation of software in products

For project teams working in one of these areas, Scrum can boost project success rates.

Using Scrum, a dedicated, motivated, self-organising team can work in “discovery” mode,. They don’t start with a detailed specification (or with any specification at all, in some cases). The team works iteratively, in discovery mode, converging to a solution. Using sprints, they manage their time constraints - each sprint delivers on time.  For many software development teams, Scrum is a good choice.

… with limitations

However, success using Scrum is based on two key assumptions

❑ the project can use discovery methods, starting with little or no specifications
❑ a dedicated, self-organising team can be put into place

In many companies and in many projects, these assumptions are simply not valid.

If you look at the context of your project, you may find that it is very different from the world that the Scrum fashionistas inhabit

SPECIFICATION DRIVEN: Your project may need to start with specifications, for one or more  reasons, for example:
- a detailed design is highly desirable (e.g. for a construction project or an IT infrastructure project)
- a specification of the final solution is needed in order to get budget approval
- a specification must be created as the basis for a contract with one of the project’s suppliers

SILO BASED ORGANISATION: Your project may not have a dedicated team, for example:
- some team members perform both project work and day-to-day support work
- some team members work on multiple projects
- your silo culture is stronger than your project culture (so each team member reports to their line manager not to your project)

As a project manager, you need to understand your project constraints. Your project method must align to your constraints. If you use Scrum in the wrong context, you will have a square peg in a round hole, and your project will suffer.

So how to run your project in these cases? The traditional methods such as Prince2 are still there to help you. They are not history, Prince2 remains valid

    ❑    Prince2 is a general purpose method (not just for software projects or internet projects)
    ❑    Prince2 can create well-structured specifications using product based planning and product descriptions
    ❑    Prince2 uses a team based approach, able to cope with the traditional silo organisation and with non-dedicated teams.
   
Additionally, Prince2 is a full-strength project management method, covering essentials such as budgets, business case, risk management; most of which is absent from Scrum, which is a delivery team approach rather than a project framework.

It’s not always a binary choice for every project. It’s not simply Prince2 or Scrum. If necessary, you can blend the two. Inside a Prince2 project, you can have teams using Scrum; or you could run one project stage as a timebox. For example, inside a product development project using Prince2, you may have a dedicated team working on the software, using Scrum to ensure on-time delivery of a high quality software solution. (There”s a recently launched Prince2 add-on called Prince2-Agile which explains how to blend the two)

So be careful with your next project. Don't simply go with the crowd, don't be a blind follower of fashion. To ensure project success, you need to understand your project constraints rather than listen to the fashionistas.

Need inspiration on project quality? Look at your car!

If you are a project manager and you need to deliver quality, then go look at your car for inspiration. Your car is a high quality product which should inspire you in your project management...

A modern car is long-lasting and useful. It's high quality. The car manufacturers (Toyota, Renault, Ford, etc.) have worked hard to improve quality over many decades. Consider the last 50 years. If you compare the quality of two cars from 1964 and 2014, the difference is huge. The 1960's car had an limited lifespan, typically less than 10 years - its body would rust away year by year, its engine would wear out; whereas today's car should run for several hundred thousand kilometres and remain largely rust free for all its long life. Additionally, that 1960's car was basic - no radio, no heater, no seatbelts. That's very low quality in today's terms. Today, all that comes as standard.

So when you look at your car, you should admire a high quality product, and ask what the project manager can learn from car manufacturers.

In manufacturing, quality is defined in two ways: "Meets specification" and "Fit for use"

The manufacturer has delivered both in your 21st century car

- manufacturing specifications have vastly improved (better paint, more robust engines, etc.).

- customer satisfaction has vastly increased (the car is more "fit for use" - temperature control, audio, safety...)

Both of these definitions come from the world of manufacturing, but both can be applied to projects.

•  In automobile manufacturing, the car is the product. Toyota, Renault and Ford focus on delivering a high quality car
• In project management, your project has a "product" - this is your deliverable or your solution. This is where your quality focus should be.

We have two definitions of quality, so there are two ways to focus on quality in products.

1.  Using the approach of "meet specification", the starting point is to define (i.e. write down and describe) your final product, then to break it down into sub-products. To document that breakdown, you can draw a simple diagram called a "Product breakdown structure", which shows the 15 or 20 deliverables that make up your final product. You can then focus on each of these deliverables - particularly, on how to deliver quality for each deliverable, one by one. If each deliverable is high quality, then your final product will be high quality
2. Using the approach of "fit for purpose", you start with a less defined final product, typically a list of user needs or functionalities. (Sometimes these are expressed as "user stories"). You then work iteratively, trying to converge towards a solution that meets user needs. Each iteration is a better approximation to the final product, and where possible, is a partial working solution. Throughout the process, you work closely with your user or customer, showing them each iteration to get their feedback, so they can check that it's fit for purpose. Iteratively, you converge towards a high quality solution.  

These two approaches correspond to two Project Management methods

•         Prince2: The specification-driven approach is the way that the Prince2 project management method addresses quality. Prince2 has a "path to quality".
•         AgilePM: The iterative approach is an Agile way of working, supported by methods like DSDM (which is the basis for the AgilePM certification). DSDM says "never compromise quality"

Whatever your method, it's time to take action on Project Management quality.

One of the famous books on manufacturing quality is called “Quality is Free”. The book says that addressing quality correctly doesn’t cost you time and money, it saves time and money.

If you don’t use a robust approach to quality, you’ll probably waste time. You’ll discover the defects downstream. You’ll find out the customer’s quality expectations when you deliver. And you’ll probably fix any problems. But fixing quality defaults once the product is delivered can be very time consuming. You may end up doing the work twice… once to make the product, and a second time to fix it.

So addressing quality saves you time, keeps your customer happy, and delivers added value. Free of charge.

So maybe it's time to go admire your car... and to get inspiration for your next project.

6 honest servants to build your Communications Plan

Do you know who said this?

"I had six honest serving men. They taught me all I knew.

Their names were: Where, What, When, Why, How and Who"?

You probably don't know - but you'll recognise his name. It's Rudyard Kipling, author of "The Jungle Book", now famous as a Disney film.

Rudyard Kipling's saying can help you in Project Management. His basic questions "What, When, Why, How and Who" can guide you though the tangled jungle of project management communications.

Communications are important in Project Management - they can be critical to project success. Various analysts have highlighted poor communications as a major source of project failure, from the Standish Report of 1996 to the 2007 survey by COMPTIA.

Why is it so important to communicate? Firstly because many projects are cross-functional. Most organisations are functionally based - they are a series of functional silos. Things may work well inside each silo, but projects need to work transversally, across the organisation (more than one silo) and they often need to work with partners outside of the organisation (more than one company). For a cross-functional project to succeed, you need rich, transversal communications.

Secondly, the project is a vehicle for change. People are naturally resistant to change; they are familiar with the current ways of working. Change is disruptive; there is resistance to change. For your project to deliver real change, you need to communicate to maximise buy-in and to minimise resistance.

As it is important to communicate, the project manager needs a communication plan. This is where Rudyard Kipling's saying comes in.

We need our own Six Honest Serving Men to create a communications plan.

·  To whom? The stakeholder group who receive the communication

·  What? The message to communicate

·  Why? The objective of the communication

·  By whom? Who will create and/or deliver the communication

·  When? What frequency, or what date, or during which stage of the project

·  How? What channel of communication (email, face to face, meeting, intranet...)

Example

To Whom?	What?	Why?	By whom?	When?	How?
Entire project team	Initial objectives	Get involvement	Project Manager	Start of project	Kick-off workshop
Order management team	Training schedule	Ensure availability for training	Order Admin Manager	Start of stage 2	During monthly team meetings
Sales Force	New bonus scheme	Motivation	Regional Sales Manager	At next Quarterly Meeting	Powerpoint with Q&A
Internal Audit	Process flowchart	Compliance	Process team lead	For each new version	Process workshop
etc...

Creating the communications plan is the first step. Once that's done, the next step is to put the plan into action - to use it to organise your communications, week-by-week, month-by-month.

For the project manager , creating a communication plan is useful investment of energy. It normally takes you only an hour or two to create an initial plan, and it will save you hours of sweat throughout the project. It helps identify your transversal stakeholders. And it helps you focus on areas of possible resistance, and how best to mimimise resistance.

A communications plan is a best practice approach. In the Prince2 project management method, it's the basis of the project's Communications Strategy.  In MSP, for programme management, there is a diverse toolkit, starting with a Stakeholder Engagement Strategy; passing by various Stakeholder Analyses; and finishing with a Communications Plan.

Whatever your method, get out of the jungle! Remember Kipling's six honest servants and create a communication plan for your project or programme.

Project management, change management are like apples and pears

Should a project manager be a change manager? The traditional answer was YES, a project manager should know how to manage change. Today the answer is more often NO, as there are new and better ways to manage change.

Change initiatives are increasingly using a new role of Business Change Manager to manage complex change. In such cases, the project manager is no longer a change manager. Apples are apples and pears are pears: project managers manage projects. And change managers manage change.

What is wrong with a project manager running change management? Why invent this new role of Business Change Manager?

If we understand the Customer - Supplier relationship in projects, we will understand why. A Customer - Supplier relationship underpins most change initiatives: the project teams are on the supplier side, delivering a solution. The business teams are on the customer side, using the solution.

This “customer - supplier” relationship is not a question of contracts or invoicing. This relationship exists even for internal project teams working inside one company - an internal supplier provides a solution to an internal customer

This is why the we have two distinct roles, the project manager role and change manager role. One role on the supplier side, a separate, distinct role on the customer side.  And this is a peer-to-peer relationship, where the two roles are equal, not hierarchical.

Programme management methods like MSP (Managing Successful Programmes) recognise this separation. MSP has two two key processes
    ❑    a supply side process, called “Delivering the Capability”, for building the solution in project mode 
    ❑    a change management process on the customer side, called “Realising the Benefits”, for transitioning to the new solution and measuring the success of the change.

This approach has many advantages. Notably, it recognises that the motivations of the Project Manager and the Business Change Manager are very different.

The Project Manager is often motivated by
    ❑    technology (performance, features, innovation)
    ❑    sign-off and approval
    ❑    project performance measures such as finishing OTOB (On-time and On-budget)
   
The Business Change Manager has different concerns
    ❑    reliability, stability
    ❑    ease of use, training, support
    ❑    good documentation
    ❑    long term benefits

The Business Change Manager role needs business skill, rather than project management skills. The Business Change Manager should be chosen from the business area that will use the new solution. Crucially, after the solution is implemented, the Business Change Manager will return to the day-to-day business, and will use the solution week-by-week, month-by-month.

This reveals another important difference in motivation between the two roles the Business Change Manager (and his or her colleagues) is going to use the new solution, whereas the Project Manager will probably never do so. That’s a big difference, and that’s another reason why we we need a dedicated Change Manager.

So for your next business change initiative, try not to mix apples and pears. Don’t confuse project teams (apples) and business teams (pears). Project managers should manage projects. And change managers should manage change. Keep those apples and pears apart.

Time for timesheets.. or wait until tomorrow?

If you want to get control of your projects, you should use timesheets. Or should you? Is the accepted wisdom really wise?

Timesheets allow you to measure effort; i.e. man-days of work. All project management methods suggest you should control time and cost. Human effort one dimension of cost. It is normally expressed in man-hours or man-days of work (which usually can be  converted into a financial cost). To control effort, you need to estimate it when you plan and then track the actual effort. That’s where timesheets come in, to track the actual effort.

The Prince2 project management method follows this approach. The Prince2 planning process has an estimating step. For Prince2, effort is the primary resource estimation for each task. (Secondary resource needs include equipment, travel or money). By saying that you should control effort, Prince2 ask you to plan and then to track effort. Prince2 therefore assumes that you will use timesheets.

That’s what they are doing at one major bank using Prince2. Effort is indeed the main measure of project resource estimation. A small banking project may have a budget of 50 man-days of effort, whereas a large project may have a budget of 3000 man-days. To monitor progress, the bank uses timesheets to record actual effort by the project teams. So, for example, a 10-week project estimated at 50 days may finish with 45 (or 55 or whatever) actual days of effort. This is calculated from the timesheets of all the project team members submitted during the 10 weeks.

So timesheet solutions aggregate a lot of data from a lot of people. You need timesheet software, which lots of people need to use correctly and regularly. That’s where the problem starts. The software vendors will tell you that the software is easy to use (maybe true, maybe not!), but they won’t always tell you how much work is needed to achieve a sustained, widely-used solution which truly delivers benefits to your wider organization.

In some organisations, there can be hundreds of people working on various projects. A large hospital tried to implement a timesheet solution to control project effort.  Inside the IT department of about 50 people, this worked OK.  But most projects go beyond IT. The hospital has about 3000 staff, very many of whom could work on a project. You can’t ask 3000 people to fill in timesheets, just because some of them may work on a project from time to time.

Even for the small IT department, the hospital hit another problem, of scope creep. Once they had estimates of project effort for their teams, they had a partial forecast everyone’s future work plans. So they decided to go for a 100% solution, and complete the picture with plans on non-working time (holidays, etc.) and non-project work (support, maintenance, staff meetings, etc.). Once you try to manage the full working week for your entire team, you add extra complexity for little benefit. The hospital could not sustain the effort, and the timesheet solution failed.

There are a lot of failures with timesheet implementations. It’s hard work and there can be a lot of resistance. People don’t like filling in timesheets. It takes a lot of work to get everyone to submit a time sheet each week (and to sustain this 52 weeks per year). Furthermore, if you succeed, the data quality may be low, and consequently the benefits for project control may be slim.

Timesheets can work well in certain environments, for example where hours are billed to the customer. Or in closed environments, such as software development teams, where all projects are done by a limited number of project team members. In these cases, there is a clear benefit to the organization, so you can more easily succeed with timesheets.

If you choose not to implement timesheets, what can you do? One major chemicals company has decided not to use timesheets today for their projects. They know it’s premature – timesheets wouldn’t work today. Their solution is to track cost and time, but not effort.  Costs are tracked (expenditures); time is tracked (activity start and finish dates); but effort is neither estimated nor tracked.

So should you use timesheets? If your goal is to improve your team’s or your company’s project management maturity, yes, it should be on your long term agenda. Should it be a priority? You need to analyse timesheet deployment as a long term project. It’s not a quick-win software implementation project – you need sustained long-term commitment to get any benefits. Work out the business case, study the risks of failure.

You’ll possibly find that deploying timesheets is not a priority project. Your return on investment is perhaps too uncertain, your risk too high. Focus instead today on easier project management improvements with more certain benefits. Wait a while until you tackle timesheets. Mañana, demain, morgen, tomorrow.

Can you measure your project performance?

The Dutch say “Meten is Weten” – to measure is to know. Measurements have become fashionable everywhere. In companies, in schools, in hospitals … everything is driven by targets and measurements. Everyone is trying to deliver their targets and key performance indicators (KPI’s).

The fashion has come to the world of Project Management. However, in Project Management, targets are used slightly differently. Rather than set an arbitrary target, you create a plan. To measure, you compare your plan against reality (your “actuals”). Project performance measures how well you are delivering against your plan.

The traditional performance measurements for projects have always been cost and time. There’s even an acronym OTOB which neatly sums up the Project Manager’s drive to deliver on time, on budget. When people speak about project performance, they typically are talking about OTOB: are you delivering on time, on budget, relative to your original agreed plan?

If OTOB is the traditional measurement of Project Performance, modern Project methods have followed the fashion, and added more measurements. Some people have added a third dimension, Quality, and transformed OTOB into OTOBOQ.

The latest Prince2 manual (2009) follows the fashion. The subject of measurements arrives in Chapter 1, which introduces 6 key aspects of performance (whereas in the previous version it was buried in a later chapter). Prince2 suggests that the best practice is to control not just Time and Cost, but also Scope, Quality, Risk and Benefits.

In reality, you may need to go a little further: you may need to break Cost into Financial cost and Effort, as these must be controlled very differently. Financial cost is based on expenditure of money (purchase orders, invoices…), while Effort is man-days of work. So you have up to 7 aspects of performance to control. For each, you need to compare plan versus actuals

❑ Time
Time is the easiest measurement. Your plan is probably a schedule of work (typically a Gantt diagram), including milestones (and for Prince2, stage boundaries). So this plan gives your planned time. As the work advances, you track actual time using the dates that the work was actually finished.

❑ Financial Cost
Financial cost data is also quite easy to measure. You can estimate your planned costs in various ways. Some people estimate from the Gantt diagram; others collate the information in a Business Case. You should measure actual costs as soon as you commit to expenditure (e.g. when you raise a purchase order). Be proactive about recording actual costs: don’t wait until the invoices are recorded in your accounting system, and certainly don’t wait until they are paid. 

❑ Effort
Effort is mandays of work. Effort can be easy to estimate, but is often difficult to measure. Using a Gantt diagram, you can estimate effort in man-hours or man-days. This gives your planned effort. Effort is difficult to measure, because most organisations don’t have time-sheet systems (or if they have them, they are not used by all project contributors). And, as it’s surprisingly difficult to deploy time sheets solutions (i.e. to get enough people to use them week by week), measuring actual effort is also surprisingly difficult. (For many projects, it’s effectively impossible).

❑ Scope
Scope used to be hard to control, but with modern methods, it’s a lot easier. If you use Prince2’s product based planning, you can predict your planned scope based on the product decomposition. It’s easy to detect when the products are delivered, so you can easily track actual scope. (It’s not just Prince2 that helps. Some Agile methods, such as Agile Atern, also are making control of scope easier: Atern uses a Prioritised Requirements List).

❑ Quality
Prince2 also makes it easier to control quality. Using Prince2’s product based planning technique, you can do simple-but-effective quality planning, giving your planned quality. As the work is done, each planned quality test is done, which gives your actual quality.

❑ Risk
Risk is typically controlled though regular estimates throughout the project, rather than by measurements. Each time you plan (or replan), it’s wise to perform a risk analysis. This gives your forecast of risk – your planned risk. When you execute your risk counter-measures, you mitigate the risk, and lower your forecast risk level. To measure your actual risk is difficult, and probably impossible. The best you can do is to revise your estimates, using regular risk analyses.

❑ Benefits
Benefits are also typically controlled through regular estimates, rather than measurements. In many projects, you cannot measure the benefits, as they are realised after the project has closed. Your Business Case should give the planned benefits. If you can’t measure actual benefits, you should review estimates regularly: using Prince2, you will review your Business Case at the end of each stage (and the associated Benefits Review Plan).

So for Project Managers, “Meten is Weten” (to measure is to know) is a little simplistic. You need to control project performance, but you can’t measure everything.

Certainly Prince2 helps you to "know" your project -  it gives you a framework for controlling your performance – and that helps with boosting your  performance. Give it a try!