2020 PROJECT MANAGEMENT BEST PRACTICE. 70+ TIPS FOR [PASSING] PRINCE2 EXAMS

Granted, project management best practice covers a lot of territory. So, let’s narrow it down a bit.

PRINCE2 is project management best practice in its own right.

Then there is also best practice how to learn this PM best practice.

And then there is best practice how to use what you have learned to pass the certification exams.

In this post I am going to share with you a technique that can increase your odds of passing PRINCE2 exams.

I call it the “Gumshoe Technique”.

But that’s not all.

I’ll also share with you my “Crazy Cups Method” of learning PRINCE2.

• So, the “Gumshoe Technique” can help candidates pass the exams regardless of their level of preparation.

• And the “Crazy Cups Method” provides tips that will help you achieve better knowledge of PRINCE2. Which is, of course, another path to succeeding at exams.

And in this post I’m going to show you exactly how to benefit from both of them, step-by-step.

HERE ARE THE TWO STEPS THAT LEAD TO PRINCE2 CERTIFICATION.

• The Foundation exam tests candidates on their understanding of the method’s theory.  And, well, the ability for abductive reasoning.
• The Practitioner exam involves a considerably more taxing experience. It tests the candidates’ ability to APPLY their newly gained knowledge TO A LIFELIKE SCENARIO.

Even natural-born project managers shouldn’t be kidding themselves into believing that is easy. It is not.

The “Gumshoe Technique” can be of a great help here as well. But its application requires some advance preparation.

It involves delving into PRINCE2 linguistics.

Yes, that’s correct. PRINCE2 uses its very own vocabulary, semantics and grammar conventions. Getting a good grasp of these can make the subsequent use of the “Gumshoe Technique” easier. And more successful.

Below is my summary of the main PRINCE2 linguistics canons.

Some are less well-known than the others. Several are based on my own observations.

A SINGLE LIE NEGATES ANY NUMBER OF TRUTHS. HERE IS HOW TO MAKE IT WORK FOR YOU.

1. For a sentence included in an exam question to be true, every statement contained in it must be true.
2. An incorrect phrase in a statement negates all correct phrases before and after.
3. The introduction to an exam question may include a mention that ‘the following are true statements’.
   • Beware that statements may be true but not necessarily relevant for the question context.
   • Or that a statement may provide a true answer to a different question.

LOOK BELOW FOR A SELECTION OF LINGUISTIC KINKS COMMONLY USED IN PRINCE2 EXAM QUESTIONS.

1. An answer option is nearly always wrong if when combined with the question it results in a nonsense.
2. If wording from the question is repeated in an answer, the option is worth considering.
3. Phrases such as ‘avoid’, ‘pass-by’ or ‘circumvent’ are a warning sign to not choose that option. A cardinal strength of PRINCE2 as a method lies precisely in not allowing to cut corners.
4. Words like – relevant, sometimes, often, frequently, ordinarily or generally – usually point to correct answers.
5. Absolute words – should, must, no, never, none, always, every, all, entirely and only – usually point to false answers. Statements that under all circumstances are presented to be 100% correct are not compatible with a real or lifelike project scenario.
6. Words like – may, could and might – suggest uncertainty, i.e. risk. Words like – will, should and have -indicate current or certain events. Therefore they are more likely to describe issues, not risks.

FOLLOW HOW THE “GUMSHOE TECHNIQUE” HELPS SOLVE A QUESTION FROM THE FIRST MOCK PRACTITIONER EXAM.

This is a fair example of a question that can be simplified by the application of a “50-50” filter. Our move is to discard “yes” or “no” options. But instead of attempting to refute each option separately, we aim to refute a whole category.

Tailoring means aligning the project management method with organization’s policies and procedures. In consequence, the right answer will (in all probability) start with a “yes”. Now our task is reduced to identifying the refutable option among the two that start with a “yes” – and discarding it.

A – seems to make sense. At least, no obvious disproving arguments come to mind.

B – includes two statements. “Yes” is one, and an explanation for it is the other. The second statement is true, but it corresponds to the “managing by stages” principle. It means that the second statement contradicts the first one thus making the option as such wrong.

Which leaves option A as the right answer.

To stay on the safe side it always remains a good idea to quickly check out also the two discarded “no” options. Just in case we erred when making the 50-50 decision.

C – is wrong. From the perspective of the PRINCE2 method, effective project management requires producing information in a format that suites an organisation’s culture. Full stop. In particular, investment of effort is not addressed by PRINCE2 since it is not one of six performance targets (cost, time, quality, scope, benefit, risk).

D – once again, this option includes two statements, “No” and its explanation. The second statement answers a question that corresponds to the “manage by exception” principle and not the “tailor to suit the project” principle. Besides, the “manage by exception” principle does not remove the need for meetings, it just provides for efficient use of senior management time. The second statement thus contradicts the first one making the option as such wrong.

The use of the “Gumshoe technique” is, of course, not limited to helping you pass PRINCE2 exams.

As I mentioned above, disconfirmation belongs to broader project management best practice. And the world beyond.

Feel free to apply abductive reasoning and the disconfirmation method also in both your professional and private life.

Results may surprise you no end.

NOW, IT’S HIGH TIME TO MOVE ON TO MY “CRAZY CUPS METHOD”.

To be fair, the use of the “Gumshoe Technique” offers no guarantee of passing PRINCE2 exams.

But as a matter of fact, nothing does.

The best preparation remains to learn the method well. That means hard and dedicated work before and during the course week.

Enter the “Crazy Cups Method”. 

Why “Crazy Cups”? You know, Crazy Cups is a classical ride in amusement parks.

BELOW YOU’LL FIND MY 70+ TIPS FOR UNDERSTANDING PRINCE2 BETTER.

That’s the stuff that I as a trainer consider to be quite useful for preparing for the exams.

The tips highlight some of the concepts that have proven for my course goers to be particularly elusive or hard to grasp.

I won’t claim all of them belong to the “Hall of Fame” of project management best practice. But I’ve found most to be very, very useful. Also, outof the PRINCE2 context.

Right, let’s dive straight in: PRINCE2 stands on seven principles, seven themes and seven processes.

These are the three dimensions of the PRINCE2 method, OK?

• PRINCIPLES are the method’s SOUL.
• THEMES are the method’s BONES. (Or sticking to my fable, the Crazy Cups.)
• PROCESSES are the tracks along which the project rolls from start to the end.

BUT: REMEMBER – there is also a FOURTH dimension to the PRINCE2 model – the organisational, legal, business, etc. ENVIRONMENT.

Next, I’ll take you on a circuit of detailed tips that relate to different THEMES.

After we are through, a brief detour into PROCESSES will follow.

I tend to believe that  it will help you achieve a better understanding of the PRINCE2 method. And that regardless of the training provider you’ve chosen

SO, THESE ARE OUR ”CRAZY CUPS” – THE SEVEN PRINCE2 THEMES

1. Business Case 
2. Organisation
3. Quality
4. Plans
5. Risk
6. Change
7. Progress

At the start of each section below, you’ll find a) Minimum compliance requirements and b) corresponding responsibilities of different Project Team roles.

These have been taken straight out of the official PRINCE2 guidance “Managing Successful Projects with PRINCE2 2017 Edition”. Slide decks of training providers typically include them, too.

So, what’s the benefit of repeating them here once again?

WHAT ADDED VALUE CAN THIS PART OF MY POST BRING YOU?

There are 4-6 questions about minimum requirements and responsibilities of project team roles in every version of the Foundation exam I know.

Which means, dealing with those quickly and confidently can grow your odds of passing by about a fifth. It also will save you some precious minutes. Role-related questions figure also in the Practitioner exam, albeit in disguise.

A problem is, both themes-related minimum requirements and responsibilities of roles are fairly difficult to memorize.

In the guidance, they are spread over some 300 pages. Course handouts also tend to be pretty bulky.

So, here is YOUR BENEFIT from my post.

Copy-pasting my tips into two pages of a Word document will in a flash produce an aide-memoire. Which literally means, an aid to your memory.

Flex and tweak it in any way. Cut text in pieces and hang these around your place. Print individual tips on cards and flip through them while being on your way. Pat your visual memory the way it likes best. Helps a lot.

BUSINESS CASE THEME – DESIRABLE, ACHIEVABLE, VIABLE

TIP 1. Minimum requirements.

• Create and maintain a business justification for the project.
• Review and update the business justification in response to events.
• Define management actions to ensure outputs are produced, outcomes are achieved and benefits are realized.
• Define and document roles and responsibilities for the business case and benefits management.
• Produce and maintain Business Case and Benefits Management Approach.

TIP 2. Roles and Responsibilities.

Executive – “Owns” the Business Case. May be accountable for the benefits management approach during the project (corporate, programme management, or customer post-project).

Senior User – is accountable for specifying the benefits and desired outcomes by ensuring that the expected benefits are realised.

Senior Supplier – is accountable for the supplier’s business case.

Project Manager – may prepare the business case and benefits management approach on behalf of the executive.

Project Support – may assist the project manager as the business case is baselined and under change management. Responsible for assessment and updating the Business Case and Benefit Management Approach.

TIP 3. BUSINESS CASE is linked to BENEFITS REVIEW PLAN.

The Benefits Review Plan is aligned with the BENEFITS MANAGEMENT APPROACH.

TIP 4. Business Case attributes are – DAVe

DESIRABILITY – overall balance of its justification (Executive perspective).

ACHIEVABILITY – ability of the project to deliver agreed products (Supplier perspective).

VIABILITY – ability of the project products to result in outcomes that will deliver the agreed benefits (User perspective).

In short – DAVe.

TIP 5. PROJECT PRODUCTS are OUTPUTS

OUTPUTS lead to OUTCOMES (change).

OUTCOMES permit to realize BENEFITS.

TIP 6. Business Case content – CIRBORE

Cost over time.

Investment appraisal (viability calculation).

Risks.

Benefits.

Options (minimum, something, nothing).

Reasons.

Executive summary.

TIP 7. Business Case also includes description of the PROJECT ORGANISATION.

TIP 8. Benefits Management Approach is NOT part of the Business Case.

Business Case lapses at project closure. Benefit Management Approach is the only management product that lives on after project closure.

TIP 9. Benefits Management Approach is a road-map for post-project benefit realization activities.

These latter represent business-as-usual.

TIP 10. During project, the ownership of the Benefit Management Approach is often assumed by the Executive (centralised leadership).

After project closure, this ownership passes on to the Customer (corporate, programme, ex-Senior User), as project organisation has been disbanded.

TIP 11. “BENEFIT” means “USER”.

The Senior User/Customer has TRUE RESPONSIBILITY for non-realisation of expected benefits.

They specified and agreed benefits before a project started. If these proved to be non-realizable, it’s their fault.

Incorrect – INFLATED – benefit specifications lead to project failure since such benefits cannot be realised by default.

Tip 12. ANY BENEFIT – both tangible and intangible – needs to be MEASURABLE.

Intangible benefits can be measured by polls.

Happier staff – Index of staff happiness – self-assessment questionnaire.

Institutional image improvement – pre-project baseline stakeholder perception survey – post-project end-state stakeholder perception survey.

WHAT’S THE UTILITY OF ORGANISATION THEME?

Role descriptions are prepared AFTER corresponding roles have been filled. They are best prepared with the participation of appointees.

They describe distribution of responsibilities, NOT skill sets or experience requirements.

Role descriptions are not intended to be used to filter candidates.

TIP 13. Minimum requirements.

• Define project organization’s structure and roles to ensure that all responsibilities are fulfilled.
• Document the rules for delegating change authority responsibilities, if used.
• Define its stakeholder communication and engagement approach.
• Produce and maintain Project Initiation Documentation and Communication Management Approach.

TIP 14. Roles and Responsibilities – Project Board.

• Is appointed in the Starting Up a Project process and confirmed in the Directing a Project process before the start of Initiating a Project process.
• Represents Business, User and Supplier interests. Not necessarily three people (can be more, can be fewer). Not a democracy – the Executive strives to rule by consensus but his decisions prevail and cannot be challenged.
• Accountable for the success (or failure) of the project.
• Provides unified direction and make decisions.
• Provides resources and authorizes funds.
• Ensures effective communications (internal & external).
• Approves all major plans, funding, and authorise any major project deviation.
• Provides visible and sustained support for Project Manager.
• Implements Directing a Project process activities.

TIP 15. ROLES AND RESPONSIBILITIES – EXECUTIVE.

• Appointed by corporate, programme management, or the customer.
• Ultimately accountable for the success of the project they are the key decision maker – only ever ONE person.
• Budget holder – secures funds.
• Responsible for observing the principle of continued business justification. Oversees development of the business case (outline & detailed).
• Ensures that the project is aligned with corporate/strategic objectives.
• Accountable for ‘Business Assurance’ = value for money.

TIP 16. ROLES AND RESPONSIBILITIES – SENIOR USER.

• Represents users’ interests and safeguards users’ requirements.
• Specifies project benefits and after project closure assumes accountability for realising them.
• Defines the scope of the project.
• Monitors products against requirements.
  • Provides the customer’s quality expectations and acceptance criteria.
  • Ensures products are signed off once completed.
• Ensures User resources are made available.
• Accountable for ‘User Assurance’.

TIP 17. ROLES AND RESPONSIBILITIES – SENIOR SUPPLIER.

• Represents the interests of those delivering the project products (suppliers).
• Provides supplier resources.
• Accountable for the quality of products delivered by suppliers and technical integrity of the project.
• Has major input to the definition of Project Approach regarding viability, realism and acceptance methods.
• Briefs Project Manager if non-technical.
• Accountable for ‘Supplier Assurance’.

TIP 18. ROLES AND RESPONSIBILITIES – PROJECT ASSURANCE.

• Responsible for monitoring all aspects of the project’s performance and products independently of the Project Manager.
• Checks out also rumours, whistle-blowers, well-wishers and leaks regarding project progress.

TIP 19. ROLES AND RESPONSIBILITIES – CHANGE AUTHORITY.

• Reviews and approves/reject all requests for change and off-specifications.
• By default is a responsibility of the Project Board. All but the most serious decision-taking is, however, typically delegated to the Change Authority. And this role is routinely vested in the Project Manager.

TIP 20. ROLES AND RESPONSIBILITIES – PROJECT MANAGER.

• Appointed by the Executive.
• Runs the project day to day on behalf of the Project Board.
• Can take on ONLY SELECTED additional roles of Team Manager, Project Support and Change Authority.
• Is accountable for the execution of the Controlling a Stage and Managing Stage Boundary processes.

TIP 21. ROLES AND RESPONSIBILITIES – TEAM MANAGER.

• Ensures production of products through delivery of Work Packages allocated by the Project Manager.
• Takes direction from and reports to the Project Manager.
• Has a reporting line to the Senior Supplier.

TIP 22. ROLES AND RESPONSIBILITIES – PROJECT SUPPORT.

• Responsibility of the Project Manager.
• May be delegated to project support staff:
  • Process or tool expertise.
  • Maintenance of project documentation.
  • Maintenance of Configuration Item Records.
  • Admin support to Change control.
• Project support and project assurance roles must be kept separate in order to maintain the independence of project assurance.

TIP 23. ROLES ARE NOT SAME AS POSITIONS.

• Roles and Responsibilities are described in generic terms.
• Jobs, Job Descriptions, Positions are products of tailoring.
• Assigning Roles and Responsibilities to jobs/positions is organisation-specific.

TIP 24. Project organisation is determined in the Starting Up a project process.

It is included in Project Brief, Outline Business Case and Detailed Business Case.

The contact person of the Project Manager on the Project Board is the Executive. S/He is the entry point for all kinds of reports/requests and informs the Project Manager about the Board’s decisions.

QUALITY THEME: A PROJECT’S PURPOSE IS IN ITS PRODUCT

QUALITY TECHNIQUES PROVIDE A BLUEPRINT FOR STEERING OUTPUT PRODUCTION TO THE DESIRED RESULT.

TIP 25. Minimum requirements.

• Define a quality management approach, covering:
  • Quality control, project assurance.
  • How the management of quality is communicated.
  • The roles and responsibilities for quality management.
  • Explicit quality criteria specified for products in their Product Descriptions.
  • Procedure for maintaining quality records.
  • Recording of quality activities in some kind of a Quality Register.
• Specify customer quality expectations and prioritised acceptance criteria in the Project Product Description.
• Use lessons learned to inform quality planning, quality management, the definition of quality expectations and quality criteria.
• Produce and maintain management products – Quality Management Approach and Quality Register.

TIP 26. ROLES AND RESPONSIBILITIES UNDER THE QUALITY THEME:

Executive.

• Approves the Project’s Product Description (in consultation with Senior Supplier, if appropriate) and the quality management approach.
• Confirms acceptance of the Project’s Product.

Senior user.

• Provides customer quality expectations and acceptance criteria, approves product descriptions for key user products, and provides user resources.
• Provides acceptance of the project’s product.

Senior supplier.

• Approves quality methods, techniques and tools for product development, and provides supplier resources.

Project manager.

• Documents the customer’s quality expectations and acceptance criteria.
• Prepares the Project Product Description and the Quality Management Approach.
• Prepares Product Descriptions.

Team manager.

• Produces the products to the specified quality.
• Assembles quality records.
• Manages quality controls and advises the project manager of the product quality status.

TIP 27. An objective of the QUALITY REVIEW TECHNIQUE is to BASELINE the product for change control purposes.

BASELINE = gain User acceptance.

TIP 28. QUALITY REVIEW TECHNIQUE = QUALITY PLANNING+QUALITY CONTROL.

QUALITY REVIEW + PRODUCT APPROVAL is done against Product Description and Quality Criteria.

PROJECT PRODUCT ACCEPTANCE is done against Project Product Description and Acceptance Criteria.

TIP 29. QUALITY AUDIT TRAIL includes:

• • Customer quality expectations and acceptance criteria (Quality Planning).
  • Project Product Description.
  • Product (including Management Product) Descriptions.
  • Quality Register.
  • Quality Management Approach.

PLANS THEME: THERE’S MORE TO A PLAN THAN SIMPLY A SCHEDULE.

TIP 30. Minimum requirements.

• Ensure that plans enable the business case to be realised.
• Have at least two management stages including an initiation stage and at least one further stage.
• Produce a project plan for the project as a whole and a stage plan for each management stage.
• Use product-based planning for the project plan, stage plans and exception plans.
• Produce specific plans for managing exceptions.
• Define roles and responsibilities for planning.
• Use lessons to inform planning.
• Create and maintain plans, a Project Product Description (in the Project Plan), a Product Description for each product (in corresponding Stage Plans) and a Product Breakdown Structure.
• Product Flow Diagram is optional.

TIP 31. ROLES AND RESPONSIBILITIES UNDER THE PLANS THEME.

Executive/ Board – Approves project, stage, and exception plans with tolerances, and commits business resources to stages (e.g. finance).

Senior User & Senior Supplier – Ensures plans are consistent with their perspectives and commits resources to stages.

Project Manager – Designs the plans, prepares the project and stage plans and, if required, an exception plan.

Project Support – assist the Project Manager and contribute specialist expertise.

Team Managers  – Prepare the team plans (optional).

TIP 32. THESE ARE THE THREE LEVELS OF PLANS:

• Project (costs, stages, controls).
• Stage (products, resources, activities).
• Team (optional).
• Exception plan is not a separate level.

TIP 33. Product-Based Planning.

Includes

• Project Product Description.
• Product Breakdown Structure.
• Product Descriptions.
• Product Flow Diagram (sequence of Project Product assembly).

TIP 34. Project Product Description and Product Description belong in the PLANS theme

TIP 35. Project Product Description is accompanied by Project Breakdown Structure that lists Configuration Items.

Each Configuration Item has its own Product Description including Quality Criteria.

TIP 36. This is the difference between Project Product Description and Product Descriptions.

Project Product Description includes

• quality expectations.
• acceptance criteria.
• acceptance.

Product Descriptions include

• quality criteria.
• quality tools.
• quality review.
• approval.

TIP 37. Types of MANAGEMENT PRODUCTS include:

• Baselines – Business Case; Project Initiation Documentation; Change Control, Risk Control, Quality Control and Communication Approaches.
• Records – Configuration Items Record, Daily and Lessons logs, Issue and Risk registers.
• Reports – checkpoint, highlight, issue, lessons, stage end, exception.

TIP 38. HERE IS WHAT A PLAN INCLUDES.

• Required products (product-by-product configuration of the Project Product).
• Activities, Dependencies, Resources necessary to produce each of the required products.
• Activities that manage Project Product creation – assurance, quality/risk/configuration management, controls, communications.

TIP 39. Updating PROJECT PLAN involves also updating the RISK REGISTER

Producing an EXCEPTION PLAN involves updating CONFIGURATION ITEM RECORDS.

STAGE PLAN is updated THROUGHOUT THE STAGE.

PROJECT PLAN is updated ONLY in MANAGING STAGE BOUNDARY process (regardless whether it is scheduled or triggered by an exception):

RISK THEME: MANAGEMENT OF RISK IS ALWAYS ORGANISATION-SPECIFIC

TIP 40. Minimum requirements.

• Define a Risk Management Approach, minimally covering:
  • How risks are identified and assessed.
  • How risk management responses are planned and implemented.
  • How the management of risk is communicated throughout the project lifecycle.
  • How to assess whether identified risks might have a material impact on the business justification of the project.
  • The roles and responsibilities for risk management.
• Maintain a form of risk register to record identified risks and decisions relating to their analysis, management and review.
• Ensure that project risks are identified, assessed, managed, and reviewed through the project.
• Lessons are used to inform risk identification and management.
• Produce and maintain Risk Management Approach and Risk Register.

TIP 41. Roles and responsibilities under the Risk Theme.

Executive ensures that:

• The risk management approach is appropriate.
• The business case risks are assessed and controlled.

Project Manager

• Creates the risk management approach and the risk register.
• Ensures risks are identified assessed and controlled throughout the project.

Project Assurance

• reviews risk management practices to ensure that they are performed in line with project’s risk management approach.

Team Manager

• participates in the identification, assessment, and control of risk.

Senior User

• ensures that user risks are identified.

Senior Supplier

• ensures that supplier risks are identified.

TIP 42. Risks can be negative – THREATS and positive – OPPORTUNITIES.

Tip 43: ENHANCING an OPPORTUNITY is a separate type of RISK RESPONSE.

CHANGE THEME DEALS WITH PRODUCT CONFIGURATION AND PROJECT BASELINES.

TIP 44. MINIMUM REQUIREMENTS UNDER THE CHANGE THEME.

• Define a change control approach covering:
  • How issues are identified and managed.
  • How to assess whether identified issues might have a material impact on the business justification of the project.
  • The roles and responsibilities for change control, including a defined change authority.
• Define how baselines are created, maintained, and controlled.
• Maintain some form of issue register to record identified issues and decisions relating to their analysis, management and review.
• Ensure that project issues are captured, examined, managed and reviewed throughout a project.
• Use lessons to inform change issues identification and management.
• Produce and maintain Change Control Approach and Issue Register.

TIP 45. Roles and Responsibilities.

Executive

• Determines the change authority and change budget.
• Makes decisions on escalated issues.

Project Manager 

• Creates and manages the change control approach.
• Manages issue/change control procedures.
• Creates and maintains the issue register.
• Implements corrective actions.
• Escalates issues to the Executive.

Team Manager

• Implements corrective action as requested by the Project Manager.
• Escalates issues to Project Manager.

TIP 46. CHANGE MANAGEMENT PRODUCTS

• Configuration Management Approach
• Configuration Item Record
• Product Status Account
• Issue Report
• Issue Register

TIP 47. An ISSUE REPORT is generated from the Issue Register to accompany request for change, off-specification or problem/concern

It is updated FIRST to record DECISION and THEN to record decision IMPLEMENTATION.

TIP 48. FIVE activities included in CONFIGURATION MANAGEMENT PROCEDURE

• Planning.
• Identification.
• Change control.
• Status accounting.
• Verification and Audit.

TIP 49. FIVE steps of ISSUE AND CHANGE CONTROL PROCEDURE

• Capture.
• Examine.
• Propose.
• Decide.
• Implement.

TIP 50. Any “CHANGE” that is not imminent/ongoing means “RISK”.

Only a RISK that HAS OCCURRED becomes an ISSUE.

UNLESS risk action can be implemented within stage tolerance or risk budget.

TIP 51. MoSCoW – Mike-Sierra-Charlie-Whiskey

• Must have.
• Should have.
• Could have.
• Won’t have.

TIP 52. Management of issues

Issues are attributes of change.

There can be ONLY TWO REASONS for taking action on an issue.

1. To introduce a new benefit.
2. To ptotect an existing benefit.

• A REQUEST FOR CHANGE is proactive, it looks into the future.
  • Approve.
  • Defer.
  • Reject.
  • Ask for more info.
• OFF-SPECIFICATION is reactive, happens after the fact.
  • Grant a concession.
  • Defer.
  • Reject.
  • Ask for more info.
• PROBLEM/CONCERN – flagging, does not require immediate action.

TIP 53. Here is the SEQUENCE OF ACTIONS for handling ALL ISSUES.

• • Check Configuration Management Approach.
  • Enter into Issue Register.
  • Categorize which of three types.
  • Assess severity.
  • Assess priority.
  • Assess impact.
  • Document/Report.
  • Update Report with the DECISION and again with the result of IMPLEMENTATION.

PROGRESS THEME assesses if the project stands a chance of staying desirable, achievable and viable.

A purpose is to CONTROL UNACCEPTABLE CHANGE.

TIP 54. Minimum requirements.

• Define its approach to controlling progress in the Project Identification Documentation.
• Manage by stages.
• Set tolerances and manage by exception against these tolerances.
• Review the business justification when exceptions are raised.
• Learn lessons.

TIP 55. Roles and responsibilities.

Corporate, Programme Management, or Customer

• Provides project tolerances that are in the project’s mandate.

Executive

• Provides stage tolerances.
• Makes decisions on exception plans.

Senior User and Senior Supplier

• Ensures progress consistent with their perspectives.

Project Manager

• Authorises work packages.
• Monitors stage progress and produces highlight reports.

Team Managers

• Agrees work packages with project manager.
• Produces checkpoint reports.

TIP 56. PROGRESS theme is all about CONTROL = LOGS and REPORTS.

PROJECT (PROGRESS) CONTROLS are updated in Managing Stage Boundary process.

TIP 57. PROGRESS CONTROLS can be of two types – EVENT-driven and TIME-driven.

• Baselines: Project Plan, Stage Plan, Exception Plan, Work Package.
• Reviewing progress: Issue Register, Risk Register, Quality Register, Product Status Account, Daily Log
• Capturing/reporting lessons: Lessons Log, Lessons Report.
• Reporting progress: Checkpoint Report, Highlight Report, End Stage Report, End Project Report.

TIP 58. “EXCEPTION” means “TOLERANCE”.

Exception is a threat of deviation in excess of tolerance levels.

TIP 59. ESCALATION can also be predicated on an ISSUE REPORT rather than on an additional EXCEPTION REPORT.

The Executive has the discretion of going into an exception on the strengh of an issue report. This decision can save time and help to keep the project on track.

TIP 60. EXCEPTION PLAN is produced by the Project Manager ONLY on request from the Executive.

The Executive has various options for dealing with issues. For example, by adjusting tolerances. Creating an exception is typically not the first choice, it’s more like the last resort.

Preparing an exception plan without a request will infringe on the Excutive’s authority to decide on the preferable response.

TIP 61. Management by exception (a PRINCE2 principle) is expedited by setting the tolerances for SIX key performance areas (targets), at each level in the Organisation.

• Time, Cost, Quality – delivered to required specifications, on time and within budget.
• Scope, Benefits, Risk – TRADE-OFF aspects.

Tolerances	Project level	Stage level	Work Package level	Product level
TIME	+	+	+	–
COST	+	+	+	–
QUALITY	+	–	–	+
SCOPE	+	+	+	–
BENEFIT	+	–	–	–
RISK	+	+	+	–

PROCESSES ENSURE YOU’RE FLYING THE PROJECT BY THE BOOK. AND NOT BY THE SEAT OF YOUR PANTS.

TIP 62. The Starting Up a Project process (pre-project) is triggered by the project mandate.

At the end of Starting Up a Project process, the Project Manager sends to the Board (Executive) a request to authorize the Initiating a Project process together with the plan for the Initiation Stage.

TIP 63. Project Brief (including Project Product Description with Acceptance Criteria, Outline Business Case and stage plan for the Initiation Stage) is approved in the Directing a Project process.

Project Brief describes the project approach for the delivery of a chosen solution.

TIP 64. Outline Business Case responds to a Mandate from Corporate to Executive.

Transformation of the Outline Business Case OBC into detailed Business Case occurs in the Initiating a Project Process. It is approved at the end of the Initiation Stage.

TIP 65. The ESSENCE of the Directing a Project Process is AUTHORIZATION

The Board AUTHORIZES

• Initiation.
• Project.
• Next management stage.
• Exception plan.
• Closure.

TIP 66. The Initiating a Project process STARTS with the definition of tailoring requirements.

This is the correct implementation of the Tailoring principle.

TIP 67. In the Initiating a Project process, the Project Manager prepares Product Descriptions for MAJOR PRODUCTS that are included in the PROJECT PLAN.

In the Managing a Stage Boundary process, the Project Manager prepares Project Descriptions for LESSER PRODUCTS delivered during a stage that are included IN STAGE PLAN.

TIP 68. At the end of the Initiating a Project process, the Project Manager sends to the Board (Executive) a request to authorize Management Stage 1.

The Project Manager NEVER has the remit to deliver the whole project, but ONLY ONE STAGE AT A TIME.

TIP 69. Project authorization issued at the end of the Initiating a Project process means approval of the Project Initiation Documentation.

PID forms a “contract” between the Project Board (Executive) and the Project Manager.

TIP 70. After receiving a request to authorize project, the Board may (for a score of reasons) decide instead on premature closure.

Invoking this procedure is necessary because the project has already started.

A request to authorize project comes at the end of the Initiation Stage that is the first project stage.

And a live project can be closed ONLY by means of planned or premature closure.

TIP 71. INITIATING A PROJECT is BOTH a process AND a stage.

On the other hand, CLOSING A PROJECT is NOT a stage.

It is a PROCESS that comes at the end of the final Management Stage in the place of the Managing a Stage Boundary process.

TIP 72. Three-point estimating involves considering best case, worst case, most likely case.

TIP 73. A Work Package is typically described by activities that belong to responsibilities of the Project Manager and Team Manager roles.

Particularly in the case when the Project Manager assumes both these roles, Work Package can be also defined in terms of management products rather than activities:

Approved WP – Accepted WP – Executed WP – Received WP.

TIP 74. The Controlling a Stage process aims to ensure that:

• Products are delivered without scope creep.
• Products are delivered within tolerances.
• Risk and Issues are kept under control.
• Business Case is kept under review.
• Products are delivered to Time/Cost/Quality performance targets.

Are these tips exhaustive?

No, they are not. But I believe they will still grow your exam readiness.

Here is some more useful stuff. Keep on reading.

For more information about PRINCE2 exams, click here www.peoplecert.org

To answer questions about AXELOS’ online membership service for PRINCE2 users, visit www.axelos.com/professional-development