PM2 : Government isn't a community

PM2: Government isn't a community

In January, the European Commission published PM2. This is yet another Project Management framework created by yet another government body. This is the wrong initiative, done in the wrong way.

The world doesn't need another top-down government-inspired initiative. More so-called "best practice". We already have the PMI from the US, Prince2 from the UK, and several others. PM2 adds nothing new, it just reassembles the existing pieces in a different way.

A new set of rules

Government-driven methods attempt to codify "best practice" in a book. This "bible" is a static set of rules which is defined to be "best practice". It becomes the basis for compliance and creates an ever-growing training and certification industry. Henceforth, every CV must include certification. Everyone who wants funding must follow the rules.

PM2 follows this pattern. It is driven by a set of rules, not a community of practice. Maybe it's called Open PM2, but there are no clear feedback mechanisms to ensure that "best practice" does actually work. There is a network around PM2 (PSN), but the focus is implementing the method, and especially on training and certification. This will surely become a community of compliance rather than a community of practice.

Need a new approach

Agile has shown the way. There is a real, innovative community around Scrum, sharing good practice. Good practice evolves, bottom-up, driven by community feedback. SAFE explicitly promotes communities of practice (SAFE is a scaled approach to Scrum).

Beyond Agile, the wider Project Management world also needs to move to communities of practice. We don't need yet another top-down method like PM2. We need a bottom-up approach, based on  communities of practice. Each community will identify good practice, proven in day-by-day use. Ideas will be shared using modern social networking techniques.

This is the forward-looking approach proposed by Lean3. Sadly, PM2 is not forward-looking, it's just a rehash of old ideas, just another set of rules.

Why I stopped blogging (and why I'm starting again)

I stopped writing this blog in May 2015 

I stopped because it was time to be less evangelical about Prince2. It was time to start facing up to the truth.

My blogs were "explaining" Best Practice, as defined by Prince2. They were broadly uncritical. I assumed that Prince2 was "Best Practice", and explained how to get it to work.

For example, I explained how to analyse risk. I knew that,  until you simplify the Prince2 risk approach, it's not usable. I knew that no-one uses the Prince2 "Best Practice".

Same with communications. I wrote a blog on communications. Prince2 has an unusable "Communications Strategy". No-one uses the four strategies in Prince2. Again, I was blogging to explain how to convert  so-called "Best Practice" into real workable practice.

This incessant need for simplification told me that Prince2 is not "Best Practice"...  It was time to wake up.

In 2015, I faced up to the facts: the term "Best Practice" is now meaningless. So I stopped writing this blog.

Since then, things have got worse

Prince2-Agile was a car crash

In June 2015, Axelos launched Prince2-Agile, a new companion guide to Prince2. This guide purports to explain how to combine Prince2 with Agile.

But it was a car crash. All of Prince2 meets all of Agile in a mammoth mash-up. The premise of the book is to use Prince2 in its entirety (all 7 processes and all 7 themes), then to add Agile. The resulting behemoth (P2 + P2A = 700 pages and 2kg of paper) is hard to explain, let alone to defend.

 Even the most evangelical supporters of Prince2 struggle with this. This is not "Best Practice". No one introduces Agile into projects like this. I know how people blend Prince2 and Agile, and it's not like this.

Prince2 needed a diet, got a sugar rush

In 2017, Axelos updated Prince2. Prince2 was aging. It was fat and bloated, full of junk that no-one uses. Put instead of sending Prince2 to a health farm, to lose weight, Axelos added more fat. More bloat.  Prince2 grew to over 400 pages.
The new book now wants the Project Manager to become a methods expert, and to tailor Prince2 for each project. That's not Best Practice. In most well-organised companies using Prince2, the corporate PMO downsizes Prince2 massively. Once.

I'm starting blogging again

I'm starting to blog again. I'm starting to blog about Lean3, a new approach to Project Management.
I've not given up on Prince2. It's a tool we can still use, but it's fossilised and we need to plan for the future. Prince2 is our past.

Lean3 rejects the idea of frozen "Best Practice", written by a guru and published in an expensive book. Lean3 will have strong feedback from the community, using social media techniques.

Lean3 argues that each community of practice should define its own good practice. Good practice which is used and proven in practice.

Read more about Lean3 at www.lean3.com

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.

If you want to get things done, prioritise

If you want to get things done, you need to prioritise. Not all things are equal. In this busy world, if you don't prioritise, you won't get the right things done.

This simple truth applies at all levels. At the lowest level, it applies to your personal productivity. At the wider level, it applies to your project, your team or your company. If you don't prioritise, you won't drive things through and get the essential things done. You'll get distracted on the way by myriad lesser details and secondary priorities

Personal productivity

Getting things done (GTD) is the current fashion. An American guru called David Allen has pioneered a method called GTD which has been commercial success for him, but a disaster for many people's personal productivity, The fashion has created a tsunami of GTD offerings - there are hundred of Smartphone apps, Mac and PC software apps, books, websites and videos based on Allen's work. All of these can lead you into the same trap: you end up with long, long lists of un-prioritised tasks, which you try to pick off one by one. Do you get more things done? For many people, the GTD method doesn't increase productivity; it produces a mess. It's like a compost heap – a large, untidy mixture of assorted tasks, some old, some new; some urgent, some trivial.

There are better ways to work, and better apps. An early app came 10 years ago with the Palm Pilot, before Allen wrote his book. The Palm was a predecessor of the smartphone, and part of its success was due to its excellent ToDo app, which prioritised tasks as ABC (and, of course, also by category). You knew what was important. Today, there are a few good alternatives to GTD, such as the 2Do app, which prioritises tasks in 5 ways (Star-High-Medium-Low-None). This works, this really does help to get the right things done. You know what's important, even if you have hundreds of pending tasks.

Project priorities for on-time delivery

In the work environment, some project methods prioritise to stay on target and on time. The AgilePM method, based on the DSDM Atern variant of Agile, uses MoSCoW prioritisation. The MoSCoW acronym stands for "Must Have", "Should Have", "Could Have", "Won't Have". Using MoSCoW prioritisation, you prioritise your scope (features or needs) both at the project level and also timebox by timebox. This is a powerful technique, which really does help you to get the right things done, and - very importantly - to guarantee on time delivery. (It's an Agile technique which you can transfer to non-Agile projects, using Waterfall methods or methods like Prince2).

Portfolio prioritisation model

At the big picture level, it's important to prioritise too. If you are running a set of projects and programmes, you have a portfolio which you ought to prioritise with care and intelligence, so you can deliver your strategic objectives. If you don’t prioritise, you can end up busy, but getting nowhere.

The best practice approach is to prioritise using a combination of the attractiveness and achievability of each project or programme.

·       Attractiveness should be based on multiple criteria, such as alignment to your high level strategy and expected ROI (return on investment)

·       Achievability is typically based on the delivery risk (probability of success)

Best practice guides like MoP (Management of Portfolios) and P3O (Project, Programme and Portfolio Offices) tell you how to do this. They suggest that you start by getting agreement on a Portfolio Prioritisation Model. Once this is agreed, you can use it to assess both your current portfolio and your "demand" (the pipeline of new ideas and requests which could become lines of your portfolio). This is proven best practice. This works.

So whether you need to get things done at the personal level, the project level or the portfolio level, you need to prioritise. If you don't, you'll probably lose your way. If you do, you may really get the RIGHT things done.

Do it right or do it fast?  There's sometimes a price to pay for "Do it fast". It's called Technical Debt.

Probably the most famous example of technical debt is MS-DOS. Back in 1981, IBM asked Bill Gates for an operating system for its new PC. To deliver on time, he took QDOS, (QDOS stood for Quick and Dirty Operating System) and renamed it MS-DOS. Born quick and dirty, MS-DOS was loaded down with debt from its very conception, with a poor command set and limited features.

In the world of project management, on time delivery is a key measure of project success for most projects. As you rush to meet the deadlines, you may be accumulating debt silently, invisibly... but incessantly.

Technical Debt may appear as

o   No documentation or user guides

o   Low quality programming (unstructured, few comments, hard-coding)

o   Badly structured databases (redundant data, data errors)

o   Poor designs (poor architecture, not modular)  

o   Poor processes (inefficient, waste time, error prone)

Debt is typically associated with software projects, but it's not only about software - all sorts of project can generate debt.

Technical debt is often generated by the pressure to finish on time, but it's not just a question of speed. There are several sources of debt.

• Speed: rushing is probably the number one cause of technical debt.
• Short term view: Patching and mending. Non-architected solutions
• Fire-fighting: Focusing on backlog (not on the future)
• "Bleeding-edge" innovation: Learning as you go along
• Lack of skills: Putting staff with wrong skills (or no skills) onto complex tasks 

Why do we worry about it?

Technical debt is like financial debt... you can ignore it for a while, but the accumulation of debt will come back and haunt you.  As you build up debt, you end up with a mess - a patchwork or spaghetti that's difficult to understand or difficult to change.

That's a potential surcharge on everything you try to do - technical debt can slow down and complicate future projects. You may also end up with premature aging - the accumulation of debt can shorten the lifetime of your solution.

Don't Sprint into debt.

The main cause of debt is speed. Some project management methods focus on speed, notably most lightweight variants of Agile. Lightweight Agile methods such as Scrum can force you into debt if you over-focus on sprints and speed. You may deliver on time, but if you sacrifice other factors of best practice, such as design, planning or quality, then you could be accumulating debt.

There are two ways around this problem for Agile projects. You can try to make your lightweight method more robust (as described in the book "Managing Software Debt" by Chris Sterling) or you can use an enterprise Agile solution

How Enterprise Agile helps

Enterprise Agile methods such as DSDM Atern (sometimes branded as AgilePM) allow you to combine agility with architecture and design. Atern also has a project management toolkit to ensure a long-term approach (plans, business case, etc.) - these help to clarify the trade-off between speed and debt (and therefore to remove or reduce debt).

Whichever way you choose, and whether you use Agile or not, you need to be aware of debt. You probably won't be able to be debt free, but you should apply three golden rules:  

• Start today to pay back old debts (each new project cleans up some previous mistakes and clutter)
• Avoid new debt (do it right in future, balance speed with quality)
•  If a project does have to sprint into debt, clean up the mess ASAP

Need to deliver on time? Then start using time-boxes!

On time delivery is the El Dorado of project management. No one wants to be late for a key deadline. As the deadline approaches, and you’re running late, the project manager and the project team work like crazy to stay on time.  Everyone works late and comes in at weekends. This generates stress, overload, even burnout.

There’s a better way to deliver on time. It’s called time-boxing.

What is a time-box? A time-box has an fixed end date, which is fixed, but the work to be done is variable. If you are running late, you have a clear, pre-approved way of doing less. If you have less to do, you can probably get back on schedule. Before the time-box starts, you need to list the work to be done, and then get agreement on how prioritise it.

Here’s an example, for a simple project to tidy up and repaint a garage.

Without a time-box, you might list the needs in any order, perhaps in order of work
    •    Sort content of boxes
    •    Recycle junk
    •    Install new lighting
    •    Buy new tools
    •    Paint floor
    •    Paint walls & ceiling
    •    Paint woodwork

Without a time-box, if you run short of time, you may have to rush the last painting tasks. If you want to do a good job, you’ll be painting until midnight, and completely stressed out…

By using a time-box, you can keep calm and avoid panic. You will focus on the essentials, and make sure that those essentials are delivered on time.

The trick is, before you start work, you should get the time-box agreed. You need to prioritise the list of needs.

Prioritised list
     -- Must have --
    •    Paint walls & ceiling
    •    Paint woodwork
    •    Recycle junk
    -- Should have --
    •    Paint floor
    •    Install new lighting
    -- Could have --
    •    Sort content of boxes
    •    Buy new tools

 If we are a bit late, we will drop one or more items from the “could have” list. If we are seriously behind schedule, all the “could have” items and one or more “should have” items won’t get done. We will plan our work accordingly, with the the “must have” items early in the schedule and the “could have” items later.

The first time you use time-boxing, you might hit the problem that people can’t or won”t prioritise their needs. Your boss might say that everything is top priority. Nothing is negotiable. That’s normally not true, especially if on-time delivery is important. You may need to “educate” your boss. You may need to help people think through the real priorities.

If you are using a method like Prince2, you can add time-boxing to your work. In Prince2 terms, a stage or a work-package could be a time-box. You commit to deliver on time (zero tolerance on time), but you have a lot of flexibility on what you delivery, using your prioritised list of needs (so you have high  tolerance on scope)

Another choice for methods is to move to an Agile method such as Agile ATERN (with AgilePM certification), which is built around time-boxes and prioritised lists. This method  uses the acronym MuSCoW for Must have, Should Have, Could Have, Won’t Have to help you remember to prioritise.

So if you are always rushing to hit your deadlines, you have a better way forward. You have a way to avoid last minute stress and panic. If need to deliver on time, then it’s time to to start using time-boxes.

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!

Avoid overload: manage your personal and project bandwidth

A trap is waiting for you in today’s busy world, where everyone is under pressure to get things done, lots of things. Do it all today! Get things done now!

The trap is multi-tasking. If you try to do too much at once, you lose focus and become less productive. It’s a trap at the personal level, and it’s a trap for project teams too.

To avoid the trap, you need to recognise your limits. A person has limited “band-width”.  And so does a team, a project or a company.

Multi-tasking sounds attractive. It’s a fashionable term borrowed from the world of computing. But if it’s great for computers, it’s a trap for humans when it overloads you. Overload destroys your focus and your productivity. If a task needs some prolonged concentration, some serious brain-work, then you need to reduce your multi-tasking.

It’s a trap that project managers can fall into. Some project managers abandon good practice and try to run their project using a to-do list. They are inviting overload and burn-out.

There are several easy and effective ways to avoid the trap.

1) At the personal level, and for small teams, Kanban approaches can work well. Kanban is a “lean” technique, where you have a backlog of work (your to-do list) but you limit the work in progress using a visual planner. For example, you may decide that only one task per person can be “in progress”. When the task is finished, start another. If you don’t finish it, put it back on the backlog list, then start another. (Read more about personal kanbans here)

2) At the project level, traditional methods like Prince2 use planning and delegation to maintain focus, while Agile methods use scope management.

    ❑    Prince2 uses planning to focus on your current work: Prince2 breaks the project into stages, and the project manager focuses on one stage at time. Prince2 has a simple and effective planning technique – with a clear and simple stage plan, you know what work needs to be done this week or this month. The plan replaces the to-do list and allows the project manager to focus on a limited number of current tasks.

    ❑    Prince2 uses delegation to sharpen your focus: Prince2 breaks the work into deliverables (or “products”) that are delegated to sub-teams. Each team has its own team manager, and the project manager doesn’t micro-manage the sub-teams. The delegation of work reduces the load on the Project Manager, who can focus on managing the project (rather than on doing the work).

    ❑    Agile approaches often focus on delivering just the right scope. Methods like ATERN (also known as AgilePM) use MuSCoW prioritisation as a way to avoid overload. Business needs are prioritised as “Must Have”, “Should Have”, “Could Have” or “Won’t Have”. If the project manager or the teams are overloaded, they concentrate on the “Must Have” needs. They know how to focus – they reduce their bandwidth, knowing that the “Should Have” and “Could Have” needs can wait.

3) Sometimes the problem is wider than the single project; it’s at the portfolio management level. Companies need to avoid overload, they too have limited bandwidth for change. MoP (Management of Portfolio) addresses this with portfolio prioritisation models, which can take into account both resource capacity (do we have enough people?) and resource capability (do we have the skills?)

So next time you need to handle pressure, don’t just build a to-do list. Don’t try to do everything at once - multi-tasking is a trap that can destroy your productivity.

That glitzy to-do list app on your smart-phone is tempting. It’s perhaps a good tool, but it shouldn’t be the only the only tool in your toolbox. Don’t run your life or your project using a to-do list, you will run into overload and stress. Widen your horizons; add some additional tools to your toolbox, either traditional tools like planning and delegation or innovative ones like Kanban and MoSCoW.

"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.