This may range from being rigid and prescriptive through to allowing the project management team a large degree of freedom as to how they implement each theme.
All seven themes must be applied in a project but they should be tailored according to the risk, scale, nature, complexity or simplicity of the project concerned , always ensuring that any minimum requirements specified in a theme are satisfied.
A tailored PRINCE2 Theme should reflect any tailoring of the processes and terminology.
Tailoring a theme does not necessarily mean rewriting a PRINCE2 theme itself. In most cases, the themes are implemented through the project’s risk, quality, change control and communication management approaches .
These should contain procedures regarding how the themes are implemented in practice for that particular project.
The level of control required will influence the degree of formality and frequency of monitoring, reviewing and reporting.
When applying the themes, take account of risk and any relevant external factors, such as corporate, portfolio, programme and customer policies and standards , and capture them in the project’s management approaches, as shown in the graphic below:
Many of the themes imply that procedures may need to be developed: PRINCE2 does not prescribe how these should be documented or published.
They can range from being a simple set of activities to a fully developed procedure with a flow chart.
PRINCE2 provides a table of responsibilities relating to each theme; these may be reassigned provided they do not introduce any conflict of interest, particularly between the roles associated with directing a project, as opposed to managing a project.
Each theme in this manual contains suggestions for different tailoring options for implementing the theme in practice, together with ideas on how to deal with some common situations.
Tailoring allows the PRINCE2 themes to be adapted to create appropriate procedures and controls, provided that:
Each theme chapter is structured as follows:
The project manager may need to tailor how the project is directed and managed in order to recognize internal and external factors that affects the way in which the project is delivered.
Any deviations from the organizations standard project management approach must be documented and agreed.
There are two management products used as an input to this activity triggered by the authority to initiate a project.
The main output here is the creation of part of the project controls, in this case driven by the tailoring requirements.
It is important to ensure that the risk management approach is appropriate not only to the project size, style and complexity, but also to the projects likely risk impact.
It is important that the risk management approach for a project supports effective decision-making on the project and does not create an undue burden or bureaucracy.
In general, smaller simpler projects will need correspondingly simpler risk management arrangements.
As an example, on a less complex project, the project manager would typically directly undertake most risk management activities.
However, on more complex projects these activities might be delegated to a dedicated risk manager or risk management team.
Similarly, a risk register might be held in a simple list on a White Board, in a spreadsheet, or in a dedicated IT system.
What is important is that the risk management approach is appropriate.
In determining the appropriateness of the risk management approach, it is critical to consider not just the project’s cost, size, scale and complexity, but also the potential scale of risk impact from the project.
It is possible for projects to create impacts that far outweigh their current size, scale and complexity.
For example, a small, simple project to replace core IT network infrastructure can stop an organization working if it goes wrong.
It is important that the approach to managing risk works with and supports the Projex chosen delivery approach. As an example, a risk management approach that includes monthly risk review meetings is unlikely to effectively support and agile project delivery approach where deliveries may be happening every two weeks.
PRINCE2 does not mandate a format for risk management products, nor does it mandate specific timings for risk management activities. What is important, is that they are appropriate for the format and pace of the project.
A risk register may be written on a white board and reviewed as part of a daily standup meeting as part of an agile delivery approach. In this context, it is just as valid as risks stored in a dedicated IT system that is reviewed at a monthly meeting.
It is also important to recognize that the projects delivery approach might work to mitigate or reinforced specific risks.
For example, an agile way of working inherently ensures that customers do not inappropriately constrain all and over specified requirements at the beginning of a project. This can be a risk in a more traditional waterfall approach.
Similarly, even though agile is characterized by a high level of engagement with customers directly involved in the project, it can lead to uncontrolled changes to the agreed baseline if not managed correctly.
More traditional pro cheese tends to reinforce the impression of controlled change, but at a risk of appearing unresponsive. What is important is that the risk management approach recognizes these inherent differences
In a commercial context there may be a need for more than one risk register as some project risks could be unique to only one party, with good reasons for them not to be visible to the other party.
Where a joint risk register is used, care should be taken to establish who’s risk it really is, and the risk owner appointed accordingly.
For example, on a fixed price contract any cost overruns will impact the supplier’s business case, but timescale overruns will typically impact the customer’s business case.
It might be appropriate to identify and rings cents an explicit risk budget within the project’s budget.
This is a sum of money to fund specific management responses to the project threats and opportunities, that is, to cover the costs of any contingent plans should a risk materialize.
The risk budget is based on the aggregate cost of all the projects planned risk responses.
For simpler projects it will usually be enough to add up the cost of all risk responses. For more complex projects care needs to be taken that the aggregation of the factored costs is not skewed by a small number of large risks.
This is where analytical techniques such as Monte Carlo simulation and associated software tools, can help.
As the project progress is, some of the risks previously identified will occur while others will not.
New risks may be identified during the life of the project whose response costs will not have been included within the risk budget. This means that it is prudent to include a provision for unknown risks yet to be identified, within the risk budget.
As the risk budget is part of the project budget, there may be a tendency to treat it as just another sum of money that the project manager can spend.
This culture should be discouraged in favor of the risk management approach defining the mechanisms for control of off, and access to, this budget
I’ll let you into an insider secret. To learn and master PRINCE2 and pass your exams you need a course that lasts two weeks. Not that you’ll find one. Why?
Too darned expensive and your boss can’t spare you away for that long. It’s no accident that those PRINCE2 high learning curve stressful classroom courses cram it all into less than a week.
Like a stampede of cows – if you miss a point in a rushed classroom, you will trip over that memory-fade over and over….
They must cover the entire contents of the PRINCE2 Manual in the first three days – which is why you work late into the night with yet more cramming and stress. Not to mention your boss and family throwing phone calls, emails and texting into the mix.
Want a high-energy and engaging way to hone and tune your PRINCE2 Exam pass-skills?
Why not take your Foundation and Practitioner Exams WITHOUT attending expensive and rushed classroom training, just use my PRINCE2 Primer System and book an Open Center Examination at your convenience.
Did you know my Primer System is Fully Licensed and endorsed by Axelos (the owners of PRINCE2 – and the folks who mark your exams) as an Official PRINCE2 Study System?
Unlike the typical classroom, you can rewind my PRINCE2 Primer videos and watch over as many times as you need, so you won’t miss a thing! And you’ll get me teaching you one-on-one in a friendly conversational tone for easy listening and learning.
In fact, I’ve spent the last 15 years teaching the PRINCE2 methodology, techniques, and principles to literally thousands of people like you, both as downloadable lessons and live training seminars across the world
Each of my 16 Full Colour Handbooks contain full colour pictures of each slide (and plenty of room to mark up and make notes as you watch my individual step-by-step video modules.
They also contain hundreds of lesson-specific Foundation and Practitioner questions, answers and rationale – to nail down the reason for the correct (and wrong) answers – you won’t miss a thing!
Heck! I guarantee you will pass your PRINCE2 Foundation and Practitioner Exam at first try!
I know what it is like. I’ve been in your shoes, that darned Official PRINCE2 Manual is as easy to read as it is to nail jelly to a mirror. To be fair, it is intended just to be a reference – not a training manual.
That’s where I come in.
See, when I used to run classroom courses, I was ordered only to use the “official” presentation slides, and by lunchtime on the first day, panic was setting in. My students were developing the “1000-yard stare”.
But I Had a Cure.
After lunch, I would spend at least an hour talking them through my PRINCE2 Road Map.
I drew this blow-by-blow on a huge whiteboard (or I would stick four or five flip-chart sheets together), and walk them through how the seven processes and key management products worked together to form the backbone of the PRINCE2 Method.
My students used it as their touchstone for the rest of the training, and all agreed it was the turning point for their grasp of PRINCE2 that lead them to passing their exam.
So, I’ve got great news for you in my
– You get me presenting the same Road Map to you a one-hour bonus video along with a large full-colour graphic for you to print out.
Step-By-Step. You won’t miss a thing.
It’s a lot easier than trying to nail PRINCE2 jelly to a mirror!
The sooner you start, the sooner you will become a PRINCE2 Practitioner, so go here:
Timing and critical mass is key here. Like any test exam, you need to “peak” at the right time. Failure and retakes suck the life out of any student.
Fails and retakes are more than double the effort and pain. Not to mention low self-esteem.
Exam failure and retakes are like herding cats – balancing the time needed to properly re-learn/improve, against the risk of forgetting small details from your original training after the passage of time.
How long has it been since you took an important exam? School or university/college?
Picture this. The examiner advises you in writing that you were not successful. And what if your work colleagues DID pass first time. How does that make you FEEL?
Telling your family is also an embarrassment. You put in time, effort, passion and inconvenience – yet you still failed.
Passing first time provides you with office bragging rights.
There is NO second chance – re-takes make you feel second-rate.
Don’t let “if only I had been better prepared” get in the way of First Time Success. You need to proportion your effort 40% to learn and apply the PRINCE2 Method, and 60% on exam familiarity and passing technique. My PRINCE2 Primer blends that exact ratio.
You need to get inside the head of the examiner. I have been a PRINCE2 examiner, marked thousands of papers and set questions for the past two decades. I know the pressure points that can cause failure, and I will show YOU how to side-step them.
The cost or preparing and taking the exams is just chump-change compared to the cost of failure and lost career opportunities.
Time for some facts.
The pace of change is quickening. Today’s organization needs to adapt or die.
Folks who can implement that change are gold-dust to any organization. Sure, operations management is needed, but they just manage what you’ve already got – project managers implement what you NEED.
It’s no accident that the project management industry is set to grow by $6.6 trillion in the next THREE years, and in that timeframe, will NEED 45 million jobs in project management.
Want to get on that train?
Have you noticed how many “managers” let it drop that they are running a “project” (often nothing more than an “assignment”. It gives them instant bragging rights.
Project Management provides the warp and woof of commerce and you will be paid handsomely – particularly if you are QUALIFIED. A recent study showed that a PRINCE2 Practitioner will earn 18% more than their peers.
The earning power of a project manager is into six figures – more than many lawyers and doctors.
But above that, a project manager earns RESPECT both from senior management and customers alike – priceless!
“When you are up to your rear in crocodiles, it’s hard to remember your objective was to drain the swamp”
Project management is never boring – but it is stressful and the responsibility for other people’s money and your team can be intense. They will look to the project manager to provide solutions and put out fires.
Critical thinking is key here, but of no use whatever if the sand keeps shifting beneath your feet.
PRINCE2 gives you back control, explains why you DON’T need to plan in detail at the start, and why the customer is NOT always right. Instead, PRINCE2 gives you a solid reference to manage against, stop “scope creep” dead in its tracks, prioritise and plan options, while building the project products right – in addition to building the right products.
PRINCE2 gives you a controlled System for Success – a project framework instead of project chaos and blame
Peace of mind and confidence in yourself and the project team to deliver …consistently.
Fear, doubt, pressure with trial and error methods are removed, and replaced instead with a process set of friendly checklists tools and templates.
What does PRINCE2 allow you to HAVE?
It’s no accident that project managers earn large salaries (well, good ones do…), they are the lynch pin of change and business success. If not done right, the project manager can end up being the whipping post. Senior Managers are adept at placing the blame on the project manager and the success on themselves.
Make no mistake, projects are just a means to an end – business benefits of whatever flavour are the real driver behind any change initiative.
PRINCE2 gives back control to the project manager and shared responsibility in success.
PRINCE2 won’t give you charisma – (something FAR more valuable than that) – it will give you a solid track record and reputation of delivering successful business outcomes.
You’ll be the Go-to Guy or Gal. The Great and The Good will beat a path to your door.
To the frustrated outsider, they will not be able to see how you do it because the PRINCE2 framework will be hiding in plain sight – yet you can get the job done time and again.
Now, you may already have a project management qualification, and that’s fine, but can you APPLY it? That’s where PRINCE2 comes in. You’ve got the Yin but you need the Yang
PRINCE2 gives you a consistent methodology for delivering project success. All projects are different, yet you seem to have the knack to take anything that management throws you – no matter what their project size, complexity, risk, specialism, or industry.
A project manager, like any professional, is there to manage change and their bag of tricks consists of being able to plan manage and control. Although they are all vital, it is the “manage and control” part where things go awry.
Unlike managing a department or a service (operational management), projects are temporary, once they have bought about the change, they are disbanded. Job Done. Or not.
So a new project has just been thrown at you.
You know all the “stuff” – how to knock up a plan, come up with estimates, manage risks, make sure the products you create are “quality”, manage change, take corrective action, report progress, and so on
So why do 80% of projects fail in some way – from “the customer is not happy” to an outright kamikaze foul-up?
The answer is that ALL project managers need a “project framework” for success. The same way that Gordon Ramsay knows that a successful restaurant needs a structure – food prep and service teams, organized kitchen, right menu, hygiene and atmosphere.
PRINCE2 provides that framework for projects. It sets up success from the get-go. Sure, you’ve got to understand it, how to apply it and tailor it to each specific project, but it provides each project manager with a “system for success”.
The PRINCE2 Principles set out set out the bedrock APPROACH, The PRINCE2 Processes tell you WHAT to do and WHEN, and the PRINCE2 Themes provide the project manager with “Best in Class” practices for aspects such as risk and quality – the HOW.
But there’s more. PRINCE2 shows you the most powerful planning technique on the planet as well as how to “bake-in” quality from the outset.
The Four Mad Dogs of time, cost, quality and scope trying pulling you in all directions – are tamed.
Risks bring uncertainty that may impact a project’s objectives, and this uncertainty may arise from events both inside and outside the organization.
An example here is the risk that an organisation can’t gain common agreement for the scope of the project, possibly risk in timescales or resources.
The purpose of the PRINCE2 Risk Theme is to identify, assess and control uncertainty and, as a result, improve the ability of the project to succeed.
PRINCE2 defines risk as an uncertain event or set of events that, should it occur, will influence the achievement of objectives. A risk is measured by a combination of the probability of a perceived threat or opportunity occurring, and the magnitude of its impact on objectives.
Risk management is defined as the systematic application of principles, approaches and process is to the tasks of identifying and assessing risks, planning and implementing risk responses and communicating risk management activities with stakeholders.
For risk management to be effective, the following aspects need to be considered:
Risk exposure is the extent of risk borne by the organization at the time.
Effective risk management provides confidence that the project can meet its objectives while keeping the business justification valid. Risk management supports decision-making by ensuring that the project team understand not only individual risks, but also the overall risk exposure that exists at a particular time.
This replaces the older “risk management strategy” document. However, the composition of the risk management approach remains the same as the risk management strategy document.
The risk management approach describes how risk will be managed on the project. This includes the specific process is, procedures, techniques, standards and responsibilities to be applied.
The risk management approach is derived from the project brief, business case, and where relevant, any corporate, programme management or customer risk management guides, strategies or policies
The risk management approach format may include a standalone document, a section of the PID, or an entry in a project management tool.
As an absolute minimum, a PRINCE2 project must:
PRINCE2 requires that two products are produced and maintained:
This describes how risk will be managed on the project and includes the specific process is, procedures, techniques, standards and responsibilities to be applied.
The risk management approach should be reviewed and possibly updated at the end of each management stage. It also defines how and when the risk register is reviewed and updated.
This provides a record of all identified risks relating to the project, including their status and history. The risk register is used to capture and maintain information on all the identified threats and opportunities relating to the project.
The risk management approach and the risk register are created during the initiating a project process.
PRINCE2 does not prescribe a specific or detailed approach to risk management. Any approach that meets the requirements described, can be seen to be following PRINCE2.
In this short article, I shall describe how the PRINCE2 Method assists planned closure for your project. I am assuming that you realize that some projects need to be shut down early or prematurely, and I will describe that situation in a later article.
When the project manager identifies at the project end is approaching during the end of the last stage, Then the closing a project process is triggered, and the “Prepare planned closure” activity is started.
This is an unfortunate choice of activity name as shutting the project down in a controlled manner involves a lot more than just planning the closure – Important though that planning is.
Broadly, Shutting the project down involves two broad activities:
Before the project manager states that they have finished a project, they must first check whether everything is done or as a minimum, nearly done.
With a small project, you may know this anyway if you have been closely involved with the team, but even then, sometimes a quick check does no harm at all to make sure that you have not overlooked anything.
As I said above, the project manager will want to check that the project meets the Acceptance Criteria laid down within the Project Product Description
There are broadly three aspects that you will want to check to ensure that you really have finished your project.
As I have advised elsewhere, you really should have been using the PRINCE2 powerful progress measuring tool, the Product Checklist. If so, then you can easily see if the sign-offs are done for most of the project deliverables or products.
The Product Checklist will have been created when carrying out the planning at both the project and stage levels.
The Checkpoint Reports are the progress reports emanating from team managers providing progress advice on the specialist products.
At the end of the project, the project manager will want to inspect the latest checkpoint reports to see how specialist product creation is progressing.
The status information for products, which is part of the configuration management or version controlled information, should be inspected to confirm that the status of all but the final few products is set to “complete”, or “approved”.
It may be that further approval is needed on some or all products – for example some form of user acceptance or operational management sign off.
The completion check is not complete unless you are sure that any necessary acceptances and handovers have been done properly.
Very often, you will not usually get those acceptance is now, but check that none have been left out when things may have been signed off. It may be that such products may have already been taken into operational use, and that this has been occurring throughout the project.
The reason for this is that not all projects are “big bang” with everything delivered in one hit at project end.
When checking through acceptances and handovers, you may need to conserver the following points:
As an example, you may need these when the company lawyers approve key documentation
These may include other organizations signing to say that they agree to the new business interfaces. Some may have legal implications as well, such as signups from building inspectors that certify the structure is safe off to the building works have been carried out.
You may need to manage and others from suppliers. This may be, as in my previous example, the formal handing over of a building from the development company to the customer organization. It may be that a sign-off of satisfactorily completed work, showing that payment to the supplier is now due.
Examples of this include a development team handing a Computer System over to the computer operations department, or passing responsibility for a retail store back to the store manager off to the project team has finished the brand change, refitting and restocking work.
The need for formal acceptance is will have been included within PRINCE2 Product Descriptions and Work Packages setting down the exact requirements for deliverables.
The Project Approach document will have identified any legal requirements and mandatory handovers.
However, the project manager should perform a final check.
A PRINCE2 Work Package is a work assignment given to a team manager to build one or more products. Each of those products is defined on a Product Description.
The Work Package is like an instruction pack describing exactly how products are to be returned on completion, including sign-off requirements.
PRINCE2 has all the right hooks “plumbed in” to ensure a controlled shutdown, but as I have described above, it is important for the project manager to take a proactive action with a degree of common sense, to ensure that all the loose ends have been covered, and that the project has met its full objectives.
The PRINCE2 End Stage Report is the Project Managers report to the project board on the stage that is just finishing. You think through the form and content of the End Stage Report in the initiation stage and record the details of it in the Communication Management Strategy document.
Normally small is beautiful, and informal (such as verbal reporting to the project board), can be attractive for some projects as well.
The contents of the report are predictable – basically, how did the stage go, what did it cost, how long did it take in comparison to the plan, and were the quality requirements met?
In full, the report is very extensive but as always, to cut it down whenever possible for your organization and project.
One problem with the PRINCE2 End Stage Report is that it has a lot of headings and many Project Managers feel obliged to write a fair amount under each heading to show that they’re completed the document thoroughly and so did their job well.
Arguably, rather too many headings are included here for a ‘normal’ End Stage Report. Be careful that you don’t swap your project with excessive documentation.
Having said that, one problem lies with the choice of wording for the headings and the content is simpler than it looks at first sight.
But some sections, not least the ‘review of products’, are overkill for a lot of projects and the project board will not send you for a huge report restating information that they already know.
Project Managers report
How the stage went from the Project Managers viewpoint
Review of the Business Case
This section draws attention to any change, such as projection of total benefits. This action is also for reporting any benefits already realized and a comment on the total risk exposure.
Review of project objectives
How the project currently stands including the six control the areas (cost, time, quality, scope, risk and benefits). It is also useful to comment whether the four strategy documents and the controls contained within the project initiation documentation, are proving effective.
Review of stage objectives
How the stage just finishing, met its objectives. Aspects to consider here would include cost and time.
Review of team performance
Any performance metrics and a ‘mention in dispatches’ for team members who’ve performed particularly well. This could be expanded to include team efficiency and effectiveness, or any other aspect regarding the use of teams to get the work done and create the products.
Review of products
These should consist of:
Any lessons that need to be passed back into the organization at this stage.
Issues and risks
A summary of the position on risk and any current issues
The Project Managers forecast for the project and the next stage for the six control areas. Although aspects like time and cost are largely self-evident from the plans submitted along with the End Stage Report, there may be value in having it stated concisely in one place
The Lessons Log will have been kept up to date throughout the project, which means during the stages.
But having said that, the point at which you write the End Stage Report is a great time and an opportunity to reflect on the stage as a whole. Think about whether any more can be learn from the experience that would be of value to others in future projects. This should include good things that worked well, and bad things to try to avoid if similar circumstances arise.
A mechanism is available for reporting lessons back to the organization at the end of the project, but if something comes up that the organization would benefit from knowing now, it can be reported now.
The Project Manager can prepare a Lessons Report which is then be included in the End Stage Report and which the project board and then passed back into the organization. Again, the Communication Management Strategy document should be referred to for receivers of lessons learned – for example operational managers.
Okay, you heard it first here, watch out for sizzling PRINCE2. it has been eight long years since the last update to the official PRINCE2 Manual and exam syllabus, and during that time it has stood rock solid as the pinnacle of best practice project management methodologies.
PRINCE2 is recognized across the globe as the most used and applied methods for delivering successful projects. The availability of tools and schemes to help project management professionals gain exam success, fast-track their professional roles, and accelerate their careers.
There will be no PRINCE3, but the new PRINCE2 kid on the block has been thoroughly scrubbed, refined and bought bang up to date ready for its launch in the summer of 2017.
Not content with just updating the official Manual and syllabus, the owners of PRINCE2 have also given their exam philosophy and schema a tweak and polish.
So, my little PRINCE2 Argonauts, what has happened over the past eight years to stir the loins of the great and good who hold the keys to the world’s most successful project management method?
As you probably already knew, since PRINCE2 is based on best practice, and feedback from the world’s community of project management practitioners has been constant, the consensus has been that the PRINCE2 house needs a thorough a spring clean.
Two of the key drivers for this is the continuing rate of change of an organization’s working environments coupled with the ongoing push to achieve better for our customers and stakeholders.
Don’t worry, the bedrock of PRINCE2, its Principles, Processes and Themes remain firmly in place. But hold hard and be prepared to see a better step-by-step flow and readability within each theme.
But it doesn’t stop there.
One of the major thrusts of the update is an increased emphasis and focus on how PRINCE2 should be tailored to meet the needs of today’s organizations and the environments that a project must plan manage and deliver within.
The new 2017 PRINCE2 Manual will not feel so isolated within its silos of chapters, as they now link very strongly back to the principles that benchmark the foundations of PRINCE2.
This has resulted in much stronger clearer links between the PRINCE2 Themes and Principles.
So, expect lots more great advice on Tailoring along with how to apply it along with many examples, with ovals of extra hints and tips. The PRINCE2 Manual is moving closer to becoming a “how to” guide and less like an academic reference.
Yep! The Method has always had flexibility at the heart of it, and has the plumbing already built-in to easily tailor an individual project to the needs of any company or organization sponsoring projects…
… It’s now wearing its 2017 “go-faster stripes”
The approach and application of Tailoring now runs like a greased chute throughout the new method guide – and further infects the entire methodology within the PRINCE2 update.
This sizzling update to the PRINCE2 methodology brims with increased and consistent emphasis on the application and tailoring – while keeping the universal principles of the method rock solid.
In the past, many folks of struggled to understand how the seemingly formal PRINCE2 methods could become good bedfellows with the agile approach to project management.
To remedy this, the PRINCE2 spring clean now includes very specific help and guidance on adopting agile, and as you would expect, constant reference to the PRINCE2 Agile Manual.
Better yet, PRINCE2 includes powerful guidance on the absolute minimum use on a PRINCE2 project by carefully selecting and optimizing how the constituent parts should be tweaked to suit the size and complexity of an individual project.
The friendly, loving and caring owners of PRINCE2, AXELOS, who have masterminded this important update, have allowed a crossover period to optimize the transition where both versions will be available from the mid-2017 launch, through to the end of 2017.
However, from the 1st of January 2018, the only English exams available for PRINCE2, will be based on the new PRINCE2 version.
Don’t worry, as the PRINCE2 update does not affect your existing prerequisite requirements, and for Practitioners who studied the older 2019 version, your certificates will remain valid until the end of its five-year period, when any re-certification will be based on PRINCE2.
Interestingly, AXELOS is giving more flexibility to the method used for PRINCE2 practitioners to remain current.
You can indeed, take and pass the re-certification exam as before, but the new option exists where you take an active subscription to PRINCE2 Membership for three years, and complete the required 45 CPD points within those three years.
Now this PRINCE2 Membership is a great idea and keeps practitioners updated with valuable information, and is also a nice little earner for AXELOS.
Here are the details:
AXELOS Membership equips you with a wide range of content, templates, toolkits, online resources and best practice guidance that enable you to succeed. Membership will give you access to resources that you can put to work, whatever the stage of your career.
Here are some of the goodies you can get:
Find out more about your membership, CPD requirements and digital badges in the downloadable Membership Handbook HERE
An annual subscription costs £125 + VAT (this includes a one-off registration fee of £25).
Multi-subscription discounts are available: a second subscription costs £30 + VAT and a third subscription costs £20 + VAT.
Yeah, I was coming to that – here you go:
The exam is now more efficient with a clearer focus on PRINCE2 core elements. These include:
There has been a reduction in the amount of “additional information” included within the scenario which is great news as poor marks can often be the direct result of quickly scanning this under exam pressure.
I’ve saved the best news until last …
Those cursed assertion reason and multiple response questions have been assigned to the trash (Yippee!)
And yes, and because of that, the number of marks has been reduced to just 75.
Be assured, that you can still prepare for both the PRINCE2 Foundation and Practitioner Exams by Self-Study – such as using my world-famed PRINCE2 Masterclass – yes, I will be releasing it this year.
Not only that, any of my customers that invest in my current PRINCE2 Masterclass – will get a FREE upgrade to my new enhanced and more expensive PRINCE2 Masterclass –
Processes and Themes – how do they work together in PRINCE2?
I am often asked that while there are helpful diagrams showing how the PRINCE2 Processes work together, why are there not any similar diagrams for PRINCE2 Themes?
So, to start, just a quick review of the 7 PRINCE2 Processes.
Starting Up a Project and Initiating a Project are done in series with a quick dip into Directing a Project to get authorization for entering the initiation stage.
The Initiating a Project process is used in the first PRINCE2 stage which is always called the Initiation Stage. All remaining stages are ‘delivery stages’.
The Final stage is NOT a separate stage; it is just that after all the specialist products have been completed, then the Closing a Project process is used within that same last stage.
Controlling a Stage and Managing Product Delivery are used in parallel within each PRINCE2 delivery stage.
The Managing a Stage Boundary process is used just prior to the end of a particular stage. This simplified graphic will help make that clear:
Controlling a Stage is the process used within each delivery stage by the Project Manager.
There must be at least ONE delivery stage, but there may be many. The actual number is dependent upon the nature, size, risk, and complexity of the project.
Managing a Stage Boundary is the process used at the end of EVERY stage to prepare for an End Stage Assessment, and covers the creation of the next stage plan, as well as updating relevant documents within the project initiation documentation (PID) and creating the End Stage Report.
Managing a Stage Boundary is also used if needed to prepare an Exception Plan ready for an Exception Assessment because tolerance has been forecast to be exceeded, and the Project Board(using Directing a Project process), have requested an Exception Plan.
This of course, would happen during a stage.
The Team Manager may decide to create a Team Plan as part of accepting the Work Package.
The Project Plan is created by the Project Manager in the Initiating a Project process (within the Initiation stage).
It contains all the information from the start of the first delivery stage (the next stage) up to and including the end of the final delivery stage.
PRINCE2 states that as you get to the end of ANY stage, a Stage Plan is created ready for the Project Board to review at the end stage assessment.
There is not a complete diagram anywhere in the PRINCE2 Manual, so this is my interpretation, and certainly captures most of the key relationships.
Your mind-set should be “while I am using this particular process, what management products do I need to create, and therefore, to which Themes should I reference?”
First, let us look at the major products that would be referenced for the Starting Up a Project and Initiating A Project processes:
Just using this diagram, you can see that Themes such as Plans, Risks, Business Case, Change, and Quality easily come to mind…
Suppose the project is to build a house. Let’s say that Stage 4 is to landscape the garden area. In the Project Plan, I will have estimated at a high level the duration, resources and costs for landscaping as a small part of the complete house build.
My Project Plan has now been approved, and I am delivering the project in the series sequence of PRINCE2 delivery stages….
As I get near the end of Stage 3, I create the Stage 4 Plan. I take the high-level tasks from the Project Plan, and for the first time create it in sufficient detail so that I can manage it on a day-to-day basis during Stage 4.
New or modified Product Descriptions and Configuration Item Records will also be generated. This is my stage 4 Stage Plan.
The Stage Plan for stage 4 will need to be approved by the Project Board (along with the updated PID contents and my End Stage Report showing current progress and forecast information for the remainder of the project.
The preparation for all this is done in the Managing a Stage Boundary process, and is then brought before the Project Board in the Authorize a Stage or Exception Plan activity within the Directing a Project process.
BUT, for the first time in my Stage 4 Plan, I can now create product descriptions and activities for the water feature, the grassed area, the planted trees, the garden pathway, etc….
Why? Because I did not know enough detail nor had yet to make my mind up back at the time when we created the top-level Project Plan….so planning in detail at the start of a project can be a waste of time and often leads to setting the wrong expectations and leading to rework later in the project when details are known.
So in this way, PRINCE2 allows its Plans to be refined as the project progresses through its stages – just like in the real world.
By the way, suppose I have decided to outsource the garden water feature to a specialist local designer/provider. One of the Work Packages detailed in the Stage Plan for stage 4, will now be presented to the external supplier for their agreement (cost, time, materials, resources, etc.).
They then sit down with their experts and do a complete costing etc., this is optional of course, but they are producing YOUR Team Plan (they would see it as ‘their project plan’) and their manager would be your ‘Team Manager’
I have just described the ‘Authorize a Work Package’ activity in Controlling a Stage, and the ‘Accept a Work Package’ activity in Managing Product Deliver process (where the specialist teams live and work!)
View the PRINCE2 processes as your ‘toolkit’ showing the sequence and relationships with each other.
View the Themes as ‘reference manuals’ sitting on your top shelf over your desk illustrating the 7 key ‘approaches’ used in a PRINCE2 project.
As you might imagine there is a lot of interaction between the processes and themes. Don’t worry about ‘memorizing’ the activity names – since you will have access to the PRINCE2 Manual throughout your Practitioner exam…
This diagram shows the most likely Theme references needed in each PRINCE2 Process:
Okay, what is the first thing that you notice?
What is apparent is that almost all the Themes are used in each of the processes!
There is a temptation to think about the individual roles taking part in each process, and frankly, you could argue that all the Themes are used (or are helpful to reference) in ALL the PRINCE2 Processes!
But I’ve tried to pare that down a little. For example, NO planning is done in the Directing a Project, nor in Controlling a Stage processes.
In Managing Product Delivery, if being used by a third party, they may well have their own business case, but it is not the Business Case owned by the Project Board Executive.
Closing a Project. No planning needed here (the Benefits Review Plan does not use product based planning, nor does it need to follow the same structure as a ‘standard’ PRINCE2 Plan.
These PRINCE2 principles are based on years of experience and lessons learned from both successful projects as well as failed projects. To conform to PRINCE2, your project MUST adhere to these principles.
The SEVEN Principles are:
The justification is documented in the Business Case, and this is used to drive all decision-making processes to ensure that the project remains aligned to the business objectives, and that the benefits and Business Case is viable, desirable, and achievable.
The Business Case must be viable to start the project, and remain viable throughout. If the Business Case ceases to be viable, the project should be changed or stopped.
Everyone involved in the project should proactively seek out lessons rather than waiting for someone else to provide them. The lessons are captured in the Lessons Log when starting the project to see if any could be applied.
Lessons should be included in reports and reviews including End Stage Assessments, the aim being to seek opportunities to implement improvements.
When the project closes, the Lessons Report should pass on lessons identified for the use of future projects.
All projects need resources with the right level of knowledge, skills, experience, and authority. These must be assigned required roles within the project. The Project Management Team structure must have these roles and responsibilities agreed plus a means for effective communication between them.
A project must have primary stakeholders, and all three stakeholder interests must be represented on the project:
Business sponsors – ensuring that the project provides value for money
Users – those who will use the project’s products
Suppliers – they provide the project resources including the specialist team who create the products
A PRINCE2 project divides the project into a number of management stages – the minimum being two, the initiation stage and one delivery stage.
These stages are partitions of the project with a control/decision point at the end of each – the Project Board need to approve the next stage plan before work commences.
Shorter stages give more control, and longer stages place fewer burdens on senior management.
There is no point attempting to plan beyond the horizon, as planning effort will be wasted.
PRINCE2 achieves this by having a high-level Project Plan, and detailed Stage Plans that are created for the next stage near the end of each current stage.
The project is released to the Project Manager one stage at a time.
Without a product focus projects can be subjected to “scope creep”. PRINCE2 uses Product Descriptions which are created during planning. These include the quality criteria that each product must meet.
Once the products of a plan have been defined, then the activities and resources can be planned in order to create the products.
Management by exception enables efficient use of senior management time by reducing their time and effort burden – while still having control by ensuring that appropriate decisions are made at the right level within the organization.
It does this by defining distinct responsibilities at different levels for directing, managing and delivering the project with accountability at each level. The situation is escalated to the next management level (up) if the tolerances are forecast to be exceeded.
These levels of authority from one management level to the next is achieved by setting appropriate tolerances (a plus/minus allowable deviation from plan).
The tolerances can be set against the six objectives and constraints for each plan. They are Time, Cost, Quality, Scope, Risk, and Benefit.
PRINCE2 is a universal project management method that can be applied to any project in any industry, organization and culture because the method is designed to be tailored.
Tailoring ensures the PRINCE2 method relates to the project environment, that the project controls are adjusted to suit the project’s scale, complexity, importance, capability and risk
I am often asked how one PRINCE2 Process “speaks” to another in terms of a PRINCE” Process Overview. My following summary will give you a new insight to each PRINCE2 Process, and how they work together:
It would be helpful if you thought of a PRINCE2 process as “Toolkits” or “Toolboxes” Each Process is used when they are needed – some once per project, some re-used several times, and one, Directing a Project, is used continuously after the completion of the starting up a project process.
Here is how the seven processes would be used in a (say), a three stage PRINCE2 project…
Note how some processes are used many times, and the differences between the Initiation Stage (creating and approving the Project Initiation Documentation) and the delivery stages (creating and approving the specialist products).
Also, that the Closing a Project process is used once within the last delivery stage, and is NOT in a stage of its own.
There are many drivers in an organization that may cause the need for change, and hence the instigation of a PRINCE2 project.
These drivers may include a new idea, a customer request, new business objectives, or the need to respond to competitive pressures, changes in legislation, the final report of a feasibility study, or even a recommendation or audit output.
Therefore, the trigger for PRINCE2 could be just about anything and in any form. This trigger is called the Project Mandate, and may take the form of a verbal instruction, the minutes from a meeting, or a direct request from senior management.
The Executive of the Project Board is appointed who in turn will normally appoint or recommend the Project Manager. At this point, the Project Manager will create the Daily Log, which is usually in the form of a diary.
It is used throughout the project to capture any informal issues or risks, and for the Project Manager to use to note any information that may not be captured elsewhere (such as a ‘to-do’ list)
The rest of the management team are also appointed – the Senior User role, Senior Supplier role, and Project Assurance (if separate individuals).
The information in the project mandate will almost certainly need to be further refined and this uses the PRINCE2 process Starting Up a Project to carry this out along with other activities.
The project mandate will be further refined into the Project Brief plus the creation of a Stage Plan for the Initiation stage. The Project Brief contains the Outline Business Case, the project approach and the Project Product Description.
The Project Board will now review these two key documents and make a decision on whether or not to formally start the project.
Their thinking will be “do we have a viable and worthwhile project?”
This is used continually throughout the project by the Project Board, and its purpose here is to use the activity ‘authorize initiation’ activity.
If a decision by the Project Board has been made to proceed further, then this is the trigger to start the Initiation stage, where the project brief will be further refined and expanded to become the Project Initiation Documentation (PID).
The project will now be planned in detail after the various strategy documents within the PID have been determined. These are:
Appropriate Project Board and project management level controls are defined, including how funding for the project is to be obtained.
The outline Business Case contained within the Project Brief is now further refined to become the detailed Business Case as part of the PID.
The initiation stage is completed once all of the information is assembled within the Project Initiation Documentation which will now need to be reviewed by the Project Board to decide whether or not to authorize the project, and to proceed into the next stage (the first delivery stage).
Also during the Initiation stage, the Managing a Stage Boundary process is used to prepare for the End Stage Assessment, including the creation of the second stage plan.
This is used continually throughout the project by the Project Board, and its purpose here is to use the ‘authorize the project’ activity. It does this by approving the PID and the next Stage Plan.
The activity ‘authorizing a stage or exception plan’ within the PRINCE2 process Directing a Project is used to approve or otherwise the second Stage Plan.
Once the PID is signed off, then all remaining stages (there may only be one), need to be authorized, and the Project Board will have delegated day-to-day control to the Project Manager for each remaining stage, one at a time.
The Project Manager will assign work to the Team Manager/Specialist team) via Work Packages and will want to ensure that their progress is in line with the approved stage plan, and that the stage forecast remains within the projects performance targets and agreed tolerances.
To assist in progress control, the Project Manager will use a set of project records (the Daily Log, Lessons Log, Issue, Risk, and Quality Registers, and Configuration Item Records).
The Project Manager will keep the Project Board informed of progress via regular Highlight Reports.
This is used by the Team Managers and specialists team members to execute their assigned Work Packages, keeping the Project Manager informed of progress with regular Checkpoint Reports.
This is the process where the specialist products are created, and as such will normally spend most of the project budget!
At the end of each management stage the Project Manager will use the PRINCE2 process Managing a Stage Boundary process to create the next Stage Plan, update the Project Plan and Business Case, and assess the aggregated set of risks including any current issues.
This information will be presented to the Project Board in the form of an End Stage Report, where they will need to decide what to do next.
The final delivery stage (there can be as many as the project needs, but must have a minimum of one delivery stage), is different in that although specialist products will have been created, when the final products are approved, the Project Manager will use the PRINCE2 process Closing a Project process to prepare for controlled shutdown.
The evidence from this process is used by the Project Board to authorize project closure.
The main deliverables are:
Use this diagram to help visualize the way that the PRINCE2 processes map onto the typical stages of a PRINCE2 project:
PRINCE2 kicks off with the project “trigger” from Corporate or programme management – the Project Mandate.
Then the whole cycle repeats… In PRINCE2, all plans are documents, and the Plans Theme and the product-based planning technique is used whenever a Project Plan, Stage Plan, optional Team Plan, and Exception Plan (if needed), are required
Whenever the Stage/Project is forecast to exceed Tolerance, the Project Manager enters it in the Issue Register, and raises an Exception Report to bring the matter to the attention of the Project Board (along with options to recover/minimize the situation)
The Project Board then makes a decision to ask for a plan on a particular option or order a premature close.
If the Project Board wants an Exception Plan, the Project Manager will use Managing s Stage Boundary to create it, and then update the remaining documents just like an End Stage Assessment.
BUT, the meeting to agree/or not, an Exception Plan is called an Exception Assessment (EXA).
Once approved, the Exception Plan replaces the original Stage Plan that would have not completed within Tolerances, and the Project Manager authorizes new/modified Work Packages against the new Stage Plan
Glad you asked.
A benign alien race whose technology far surpases our own, gave it to us to use for all our peaceful project endeavours ….
Errr ….No, actually
In recent years, organizations have experienced an unprecedented level of change and innovation and have become aware of the inherent risk associated with managing change in their business. To control the risks within IT Projects, Projects IN Controlled Environments was developed by the Central Computer and Telecommunications Agency (CCTA) back in 1989. It was intended as a UK Government standard for IT Project management.
Although PRINCE2 is a new method, it was based on a previous method called PROMPT which was developed in the 1970’s by Simpact Systems and had been adopted by the UK Government in the 1980’s.
Since its introduction, PRINCE2 has become widely adopted in both the public and private sectors and is now the de-facto standard in the UK for project management.
Today, the PRINCE2 Methodology is used in all project industries and in over 50 countries across the world.
The latest version of the PRINCE2 Method, released in 2009, has remained unchanged to the present date. This alone is a sign that it has become a mature and successful methodology.
Despite being originally developed for the IT Industry, PRINCE2 has evolved to incorporate the requirements of existing users and to enhance the methods to a generic project management best practice approach for any type of project within any environment.
PRINCE2 is a process based approach for project management providing a scalable and tailored methods for the management of all types of project. In addition to the process is, there are seven themes showing how the selected aspects of project management are applied, and provides guidance on when and how to use them.
PRINCE2 even has a new offspring. It’s called PRINCE2 Agile and shows in detail how PRINCE2 projects can use the agile approach.
And no, that’s not alien either.
So if your preparation to become a PRINCE2 Practitioner Jedi Knight is giving you a headache, I have the perfect magic pill, and no, it’s not voodoo – just a simple step-by-step set of eyeball-friendly video modules with a whole host of exam tools so you get to pass at your first attempt – check out my PRINCE2 Masterclass HERE!
These are the agreements setting down the resource and timescales for delivery of the products within the Work Package. The Team Manager must then manage the work to deliver it within these limits.
This is a plus and minus variation on late targets, because almost nothing ever goes exactly to plan!
Placing a plus and minus tolerance on some of these delivery requirements, notably time and cost, often makes sense. If tolerances are set to zero, then the smallest deviation needs to be escalated upwards causing an increase in bureaucracy, cost and time.
At the other extreme, if wide latitudes are given for the requirements of a product, then once complete it may be unacceptable to the customer or users, and again extra to spent some time will be used for rework.
It makes sense therefore to set tolerances within the “goldilocks zone” – neither too small nor too large that just right…
The constraints section sets down anything that affects how the Team Manager and the team carries out the Work Package. In some project environments, you may have security considerations that affect, for example who can enter certain restricted areas and the time-frames when this is permitted.
Another example is if building works and taking place, limits may be placed on when builders can carry out more easy work so that the work does not interrupt the operational functioning of the business.
Under the heading “reporting arrangements”, the PRINCE2 Manual refers to the frequency and content of Checkpoint Reports, but there may be other information required.
For example, you may specify the frequency and content of these progress reports in the Work Package and not within the Communication Management Strategy document.
Being able to adjust the content and frequency of a checkpoint report between one Work Package and another is very useful. In a very high risk Work Package, the Project Manager may require checkpoint reports every two days.
Whereas a less critical Work Package my only need a Checkpoint Report once a week. But take care here, as this heading talks about reporting arrangements and this will normally go beyond just discussing Checkpoint Reports.
Other reporting may be needed over and above the progress reports. For example, financial reporting covering when orders are being placed on what money is being committed within a financial year.
Health and safety procedures may dictate daily reports to confirm such things as fire exits or safety equipment have been checked every day.
If a Work Package tolerance is going to be exceeded, this is normally reported or escalated using an issue – not by issuing an exception report which is only done by the Project Manager.
However, if the Project Manager wants the Team Manager to use a different procedure, this is where such a procedure would be stated.
This refers to reference is relevant to other documents, for example security requirements or safety requirements for this type of work.
More common is that this section includes project related information and two management products:
It is usually simpler for the Project Manager to give the Team Manager a copy of the whole stage plan rather than just an extract. But they may be reasons why that would not be appropriate.
As an example, here, parts of the stage plan may be confidential, or share with the Team Manager cost or pricing information. In such a case then sending sections of the stage plan makes more sense.
Where a third party is being used to execute the Work Package, then the relevant parts of the stage plan may have been created by the third-party themselves in consultation with the Project Manager of course.
In which case, only milestone information would be needed. A powerful PRINCE2 document that can be used here is the Product Checklist.
As each product is completed, which means that it has been quality-checked and signed off, the delivery dates are noted on the Product Checklist and the milestone related to that. In effect, the third-party Team Manager (who may be their Project Manager), has pre-advised the Project Manager of when to expect the completed products.
PRINCE2 uses the technique of product based planning, and part of that planning is to write a Product Description to define every deliverable or products to be created within this stage, and hence this Work Package.
The Product Description describes the product together with any quality criteria it must satisfy and details of how to quality check the product. The Work Package may contain more than one product, and hence more than one Product Description will be included within this section.
In these days of electronic documents, the Work Package and the Product Descriptions, and any relevant plans may simply be a collection of files such as PDF documents.
This defines who can approve the products within the Work Package often they have been built and tested. Sign-off is normally very simple, but can involve things like formal acceptance is and even legal acceptance as laid down within a contract.
The section also covers how the completed products in the Work Package are to be delivered and in some cases the Team Manager can simply hand them back physically or electronically to the Project Manager.
The product may need to be returned in a different way such as into an automated configuration management version control system or by delivering direct to a final location such as a customer site.
The delivery of some products may mean installing them and setting them up so that they are operational. In any case, the Project Manager needs to be notified that the product or products included in the Work Package are complete and delivered.
You remember that project communications do not have to be complex. The Team Managers can notify Work Package completion by email or even phone calls. To not make formal communications when simpler and more effective methods are available.
So what next? I’m betting that you will want to pass your PRINCE2 exams at your first try, as well as get the best training your can – so Grab my PRINCE2 Primer and Jump on over HERE!
Within PRINCE2, the specialist products are created using the Managing Product Delivery process. Here, it is the Team Manager who’s responsible for ensuring that the specialist products described within each Work Package are created within the constraints laid down.
For the Team Manager, things are very simple in terms of the PRINCE2 method as there are just three activities:
These are shown in the diagram below and how the Managing Product Delivery process interacts with the Project Manager within the Controlling a Stage process:
A Work Package has several Headings but the concept behind it is very straightforward.
It is an instruction pack from the Project Manager to a Team Manager off king them to build the deliverable, which PRINCE2 calls a product, or perhaps more than one product if it makes sense to develop them together. The Work Package defines what products are involved and sets down any constraints and requirements for the way the work is being done.
This includes the basic obvious things like the requirements for progress reporting.
Do not think of a Work Package as more documentation and bureaucracy, because if PRINCE2 if used properly, is not bureaucratic, and the Work Package is a very valuable document.
If something must be built, someone must define what that “something” is and if things like progress reports are required, it was the makes sense to set down the content needed and specify the frequency required.
Work Packages contained sensibly information, but as always keep to the minimum in balance with exercising sufficient control. In a very small project with only one team, the Project Manager may also manage the team, and although you are using the Team Manager role and responsibilities, both the Project Manager and Team Manager roles are being filled by the same individual.
In such a case where just one person is filling both roles, then the interface between Controlling a Stage and Managing Product Delivery processes now become very informal.
If you can imagine for a moment that you the Project Manager, are giving yourself, the Team Manager, a Work Package, then the whole matter boils down to you agreeing what work needs to be done and managed next and simply capturing it within a Work Package.
The content of the Work Package is logical as you can see from the diagram below, so I will just quickly run through each section of a Work Package here:
This can either be the date on which the Project Manager and Team Manager agree the Work Package, or it may be the date on which the Project Manager issues a Work Package to the team for work to begin. It may be both dates stated here as they are all from different points in time.
This gives names of who will build the products contained within the Work Package and which team the Work Package is going to
This is an outline description of the product or products included within the Work Package.
This describes how we will build a product and in some types of project, organizations and industries, an approaches or standards may be important. Where the Work Package is being given to a third-party, you may wish to leave this section blank.
The interface is mentioned here tends to be communication interfaces where the specialist team must keep in touch with another team. It may be that products being created within this Work Package are closely related to another product in a different Work Package. So, the development interfaces will be of a communication nature, such as keeping information up to date regards progress, issues, problems, change requests, risks and so forth.
If the project is using agile or scrum approaches to the development of products, then it is permitted for the scope of a time box to change if it gets delivered at the agreed point. In such a case, in such scope changes need to be swiftly communicated to the other team.
This sets out the direct fit and function between the products in this Work Package with other products. You may need to specify a procedural interface, data interfaces, electrical interfaces, or even physical interfaces with something must physically fit dimensionally with and of the product.
Use of the same metrics could be important here such as using imperial or metric dimensions.
If the project is being carried out within one organization, then this section need only point to those responsible for configuration management. In such a case, the tools and techniques of configuration management will already be known throughout the organization and its projects.
But this section is of importance when the project involves teams from different organizations as such teams are likely to have different configuration management procedures and product identification systems.
How version control will operate in the project is set down within the configuration management strategy, and so again, the reader of this section need only to be pointed towards that document with a precise details and approach will be recorded.