PRINCE2 Foundation (08-30-2018) Paperback FINAL · PRINCE2 ® Foundation exam is ... may have several right answers, but one is always the most right answer. When in doubt, choose

PRINCE2® Foundation A Time Compressed Resource to Passing the PRINCE2® Foundation Exam on Your First Attempt

JASON DION

DISCLAIMER While Dion Training Solutions, LLC takes care to ensure the accuracy and quality of these materials, we cannot guarantee their accuracy, and all materials are provided without any warranty whatsoever, including, but not limited to, the implied warranties of merchantability or fitness for a particular purpose. The name used in any data files provided with this course is that of a fictitious company and fictional employees. Any resemblance to current or future companies or employees is purely coincidental. If you believe we used your name or likeness accidentally, please notify us and we will change the name in the next revision of the manuscript. Dion Training Solutions is an independent provider of integrated training solutions for individuals, businesses, educational institutions, and government agencies. The use of screenshots, photographs of another entity's products, or another entity's product name or service in this book is for educational purposes only. No such use should be construed to imply sponsorship or endorsement of this book by nor any affiliation of such entity with Dion Training Solutions. This book may contain links to sites on the Internet that are owned and operated by third parties (the "External Sites"). Dion Training Solutions is not responsible for the availability of, or the content located on or through, any External Site. Please contact Dion Training Solutions if you have any concerns regarding such links or External Sites. Any screenshots used are for illustrative purposes are the intellectual property of the original software owner.

TRADEMARK NOTICES

PRINCE2® is a registered trademark of Axelos Limited in the United States and other countries. All other product and service names used may be common law or registered trademarks of their respective proprietors.

PIRACY NOTICES

This book conveys no rights in the software or other products about which it was written; all use or licensing of such software or other products is the responsibility of the user according to terms and conditions of the software owner. Do not make illegal copies of books or software. If you believe that this book, related materials, or any other Dion Training Solutions materials are being reproduced or transmitted without permission, please email us at [email protected].

Copyright © 2018 Dion Training Solutions, LLC.

www.DionTraining.com All rights reserved. Except as permitted under United States Copyright Act of 1976, this publication, or any part thereof, may not be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, storage in an information retrieval system, or otherwise, without express written permission of Dion Training Solutions.

Manuscript edited by Mr. John Himes

ISBN: 9781983369216

DEDICATION

To the best wife, friend, and supporter a husband could hope to have, for her enduring patience with me as we continue on our non-stop journey through life together.

CONTENTS

Acknowledgements i Chapter 1: Introduction 1 Chapter 2: Fundamentals of PRINCE2® 5 Chapter 3: The Seven Principles 13 Chapter 4: The Seven Themes 41 Chapter 5: The Seven Processes 77 Chapter 6: Conclusion 95 Chapter 7: Practice Exam #1 97 Chapter 8: Practice Exam #2 111

Appendix A: Answer Key to Practice Exam #1 125 Appendix B: Answer Key to Practice Exam #2 137 Appendix C: Glossary of Terms 149

PRINCE2® FOUNDATION

i

ACKNOWLEDGEMENTS

This book is written for my community of students worldwide who have allowed me to continue to develop my video courses and books over the years. I truly hope that you all continue to love the Cram to Pass series and the method to my madness as you work to conquer the PRINCE2® Foundation certification exam. I wish you all the best as you continue to accelerate your career to new heights.


BONUS CONTENT

This book comes with an accompanying video course and an additional 480 practice exam questions. To access this bonus content, please register your copy of this book at http://www.diontraining.com/pages/prince2cram


1

CHAPTER ONE Introduction

OBJECTIVES

• Understand how this book is designed to help you quickly pass your certification exam

• Understand how the exam is designed and how to take the certification exam

• Understand some tips and tricks for conquering the PRINCE2® Foundation exam

In this book, you will receive a crash course that will introduce you to everything you need to know in order to pass the PRINCE2® Foundation certification exam. This book covers just the essentials with no fluff, filler, or extra material, so you can learn the material quickly and conquer the certification exam with ease.

This book assumes that you have no previous experience with PRINCE2® and will teach you the bare minimum you need to know in order to take and pass the PRINCE2® Foundation certification exam on your first attempt.

This book will NOT teach you everything you need to know to be efficient or effective in implementing the PRINCE2® Methodology in your organization. Instead, I leave that to the official PRINCE® manuals written by Axelos. This text is singularly focused on getting


2

you to pass your certification exam, not to make you an expert in PRINCE2®.

Due to the design of this text, we will move at a very quick pace through the material. If you read this entire book and take the practice exams located at the end of the text (scoring at least a 75% or higher), you will be ready to take and pass the PRINCE2® Foundation certification exam on your first attempt!

Exam Basics

The PRINCE2® Foundation certification exam is an entry-level

certification for project management personnel interested in understanding the PRINCE2® methodology and its associated terms. This foundational certification covers a general awareness of the Principles, Themes, Processes, and how they are tailored to the project environment used by your organization.

The target audience for the PRINCE2® Foundation certification is:

• People requiring a generalized understanding of the PRINCE2® methodology

• People needing an understanding of how PRINCE2® can be tailored to conduct project management within their organization

• Professionals who will work inside of a project team that is using the PRINCE2® methodology to conduct project management

The certification exam consists of 60 multiple-choice questions which must be completed within 60 minutes. A minimum score of 33 out of 60 questions is required to pass the certification exam, equating to a score of 55% or higher. The exam is a closed book exam, with no notes or study materials allowed during your examination.

As of January 1, 2018, PeopleCert has been granted the exclusive rights to conduct the examination of all candidates for the PRINCE2® Foundation certification. You can sign up to take the exam through their website located at https://www.PeopleCert.org. The exam is conducting over the Internet using a virtual proctor who monitors you while you take the exam, allowing you to sit for the exam in the comfort of your own home or office.


3

The current cost of the exam as of the publication of this book is between $300-350 USD, as PeopleCert has been utilizing variable pricing based on the current demand for the certification, the examination candidate’s country of residence, and various other factors.

Dion Training Solutions (www.diontraining.com) is an Authorized Training Organization for the PRINCE2® Foundation certification exam. You can purchase your exam voucher through the website and save $50 USD or more by purchasing your voucher through them instead of directly through PeopleCert. This discount voucher is then used to schedule your exam through PeopleCert’s web proctoring service.

Exam Tips and Tricks

Before we dig into the content of the PRINCE2® Foundation exam, it is important for you to understand some exam tips and tricks. This will help you to grasp exactly how to study for the exam as you read through the rest of this book and will help you to focus your efforts to get the most out of this material.

The most important thing to remember when taking the PRINCE2® Foundation exam is that there will not be any trick questions on test day. Every question is precisely worded to match the material you have studied. You should read the questions multiple times to ensure that you understand exactly what the question is asking you, and that you are answering the question being asked. Anytime you see the words ALWAYS or NEVER in an answer, think twice about selecting it. In project management, just like life, rarely is there a case where something ALWAYS or NEVER applies to a given situation!

As you read the questions and answers, always be on the lookout for distractors or red herrings. Generally, there is at least one of these listed in the possible answer choices to try and distract you from the correct answer.

If you see a question with bold, italics, or in all uppercase, you should pay close attention to those words because the test writers have decided that those are keywords that are very important when selecting the correct answer.

It is important to remember what concepts in the PRINCE2® methodology are principles, which are themes, and which are


4

processes. We will cover all of these throughout this book, as these are the building blocks of PRINCE2®. If a question asks about a theme, make sure that you don’t select an answer that contains a principle or process.

Also, remember that you must answer the questions based on your PRINCE2® knowledge and studies from this textbook, not your personal workplace experience. Your workplace may not be implementing PRINCE2® correctly in their project management, or worse, they are utilizing PRINCE2® in name only and not actually following the methodology, principles, themes, or processes. You should always select the book answer when answering a question on the certification exam.

On exam day, you should select the BEST answer. Each question may have several right answers, but one is always the most right answer. When in doubt, choose the answer that is correct in the most number of situations!

On test day, you don’t have to memorize the terms from the PRINCE2® methodology word for word, but you must be able to recognize them from the choices given. During certification exams, you will choose your answer from a multiple-choice style question instead of a fill-in-the-blank or essay question. This is an essential difference in certification testing and the tests you may have taken in high school or college. In the certification world, you just need to be able to recognize, not regurgitate, the information.

As you study the material in this book, keep these objectives in mind:

• Know terms associated with the principles, themes, and processes

• Be able to differentiate between a principle, theme, or process


5

CHAPTER TWO Fundamentals of PRINCE2®

OBJECTIVES

• Understand the evolution of PRINCE2® • Be able to list the three key areas of PRINCE2® • Be able to define projects and project management • Understand the difference between PRINCE2® and PMP® • Describe the functions not covered in PRINCE2®

PRINCE®, short for Projects In Controlled Environments, is a project management methodology that was first put together in 1989. PRINCE® underwent a major evolution in 1996 and that updated version became what we use today. Since then, PRINCE2® became the de facto standard in both the United Kingdom and throughout the United Nations. The method has undergone only slight alterations as some exam objectives were updated, such as a name change in 2009 to Projects In A Controlled Environment, and the most recent update in 2017 provided the addition of some Agile and DevOps concepts. (Note: Agile and DevOps are not covered by the PRINCE2®

Foundation exam and are therefore not covered in this book.) Although you will not be tested on the history of PRINCE2®, it is important to understand that it has developed over decades by observing and incorporating the best practices of project management from a diverse range of industries. This methodology has evolved over


6

time to allow organizations who implement it to perform project management more effectively. PRINCE2® is one of the world’s most popular project management methodologies because it has proved itself time and time again through the completion of more projects within their planned time and budget constraints.

Key Areas of PRINCE2®

PRINCE2® focuses on three key areas: principles, themes, and processes. These core concepts each have seven distinct items, all of which we will cover in detail throughout the remainder of this book. The principles, themes, and processes form the basis of the methodology which can then be tailored to the specific parameters of a project’s unique circumstances. Whether you’re working on a massive, multimillion dollar project (like building a skyscraper) or working on a relatively small project (like building an e-commerce website for a local retailer), PRINCE2® can be used because it can be expanded or contracted to fit the needs of your organization and your particular project.

The seven principles that form the foundational building blocks of the PRINCE2® methodology are:

• Business justification • Learn from experience • Define roles and responsibilities • Manage by stages • Manage by exception • Focus on products • Tailor to the environment

The seven principles will be covered in depth in Chapter Three. In addition to these principles, there are seven themes that are the project management areas that must be continually addressed during the project. From the beginning of the project, until it is closed out, you will be continually looking at the following themes:

• Business case • Organization • Quality • Plans


7

• Risk • Change • Progress

These seven themes will be covered in depth in Chapter Four. In addition to the Principles and Themes, PRINCE2® relies on seven processes that describe the who, what, when, where, why, and how of any given project. These processes are:

• Starting up a project • Initiating a project • Directing a project • Controlling a stage • Managing product delivery • Managing a stage boundary • Closing a project

These seven processes will be covered in depth in Chapter Five.

Throughout the remainder of this book, we will focus on going through each of these three sets of seven principles, themes, and processes in order for you to achieve a firm grasp on the importance of each concept and how it is utilized inside of the PRINCE2®

methodology. You will be ready to start your career in the world of project management by becoming a valuable member of a PRINCE2® project management team once you can fluently discuss these concepts and their associated terms.

What is Project Management?

Project management is the practice of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and to meet specific success criteria within a specified timeframe. This may sound like a lot of words to explain what could be considered common sense, but it is important to understand. Having a good framework and methodology for project management helps everyone, including our managers and us, know what we should be doing and when we should be doing it. That is the crux of project management: being efficient in our efforts so that we can save time, spend less money, and minimize the overall risk in a project.


8

What is a Project? A project is defined as a temporary organization that is created for the purpose of delivering one or more business products according to an agreed upon business case. The concept of a business case will be discussed more thoroughly in later sections, but, for now, consider the business case as the reason why a project should be undertaken. Projects are temporary in nature; they are not everlasting. Projects must have a defined beginning and end. If we use the example of an ecommerce website, that is our project: to build the website. We have to conceptualize it. We have to code it. We have to test it, and we have to field it. But, once we field it and the site is open for business, then it stops being a project and becomes an operation. At that point, we transition this product (the new ecommerce website) to the people who are going to run it on a daily basis.

In this example, the project had a beginning and an end. The end was defined at the very onset of the project with the agreed upon business case. Once the project team and the development team had finished creating the website, it was transitioned into operations and the project is considered complete. Remember, a project is always temporary.

Why Choose PRINCE2®? As a project management methodology, PRINCE2® provides us with best practices that have been refined from over 30 years of practical experience and research. These best practices have been collected together to form the PRINCE2® methodology, which can be used to manage the processes to run a project and create its deliverables. PRINCE2® is not designed to be used instead of other methodologies, but in coordination with them, such as the Project Management Professional, the Information Technology Infrastructure Library (ITIL®), Agile, and many other methodologies and frameworks.

PRINCE2® is a mature and proven methodology that provides us with a common lexicon, or terminology, that we may use to discuss a project. This ensures that the entire team understands what is being discussed and makes accomplishing the project’s goals easier.


9

When I discuss PRINCE2®, students often ask, “What about the Project Management Professional (PMP®) certification?” PRINCE2®

and PMP® are both project management certifications, but they have a different focus. PRINCE2® focuses on what to do, while PMP® focuses on how to do it. PRINCE2® is a methodology that uses processes, while PMP® is a standard and a knowledge base. Again, these certifications aren’t in competition with each other; instead, they can be used alongside each other for even greater benefit.

Many students wonder which certification they should work towards. I am assuming, since you are reading this book, you already decided to work towards your PRINCE2® certification. If you’re brand-new to project management, PRINCE2® is a great place to start.

Many students are drawn to PRINCE2® over PMP® because the certification does not mandate any educational or experience requirements. PMP® requires you to prove that you have at least 4,000 hours of experience working on projects prior to attempting the PMP® certification exam. PRINCE2®, on the other hand, does not have a similar requirement. Therefore, many students take the PRINCE2® Foundation certification, begin work on a project management team, gain the relevant experience, and then later attempt the PMP® certification exam.

Benefits of PRINCE2®

In addition to providing team members a common lexicon,

PRINCE2® also explicitly states the responsibilities assigned to each team member’s role. The methodology is also customer-focused by design. It assumes that there is a customer-supplier relationship, but that doesn’t necessarily mean that the customer is outside of your organization.

For example, as someone who works in the information technology field, I am often placed in the role of the supplier in relation to other departments across my organization. It is my role to provide them with servers, databases, and various other technology services. In the relationship, I am the supplier and my customers might be the sales, marketing, or accounting departments. Further, PRINCE2® provides many repeatable processes. Every project will proceed through the seven processes during the project’s lifecycle. If these processes are completed in the same manner every


10

time, then the process becomes very predictable and reduces the risk in the project.

Additionally, PRINCE2® delivers on business needs because it is focused on products and is a results-oriented methodology. It ensures that if the desired result of a project is a newly built website, then at the end of the project the customer should receive a website that is in production and ready to be used.

Finally, PRINCE2® is extremely useful due to its adaptability and ability to be tailored to specific projects. PRINCE2® is not a one size fits all methodology, but it can be scaled up for large projects or scaled down for smaller projects. This scaling occurs based on the size or scope of any given project.

What is Not Covered by PRINCE2®? While PRINCE2® is an excellent methodology and a great choice for organizational project management, it does not provide everything you might need to run your business. The methodology specifically neglects to cover topics that concern the specialized aspects of a business. For example, PRINCE2® does not touch on concepts such as acquisition, procurement, legal, financial, or human resources processes. This is done intentionally by the developers of PRINCE2® because these aspects must be specifically designed to support each individual organization. Therefore, they will not be covered in the generic PRINCE2® framework. Instead, it is left up to your organization to decide how best to handle these specialized aspects within your own business processes. Another area that is excluded from the generic PRINCE2® framework is personnel management. If you come from a project management background, this may seem a little strange. After all, PMP® is heavily focused on the management of people, timelines, Gantt charts, and more.

Nonetheless, PRINCE2® doesn’t worry about those type of issues. Instead, it focuses on the products and the processes to ensure that things get done. Yes, as a project manager you will almost certainly need to manage people to accomplish the project. The PRINCE2® methodology, though, leaves the specific method of managing those people up to your organization.


11

It is important to understand that the PRINCE2® methodology doesn’t require the use of specific techniques or dictate procedures. For example, in PRINCE2® you must have a valid business case for a project to continue forward. This requires a business case to be created. Yet, PRINCE2® doesn’t specify the requirement for how your organization chooses to have business cases written or what those products look like. The level of detail required in a business case is decided upon by your organization. PRINCE2® instead focuses solely on the processes and the products by requiring only that you have a business case and that it is used throughout the project’s processes.

A final example to drive this point home is that PRINCE2® states that the project must have a requirements document. The framework, however, doesn’t say how to create the requirements document or who should be consulted during its creation. Instead, the organization must decide how to answer these questions for itself, all the while using PRINCE2® as a framework for its processes to create its products.


12


13

CHAPTER THREE The Seven Principles

OBJECTIVES

• Be able to list the principles in PRINCE2® • Understand each of the seven principles in PRINCE2® • Be able to apply the seven principles to a given scenario

The seven principles are the fundamental building blocks of

PRINCE2®. These principles were designed to answer one basic question after reviewing numerous thousands of projects over a period of 30 years: “Why did one project succeed when another project failed?” As the creators of PRINCE2® considered this question, they found that successful projects had seven things in common, and these were collected to form the seven principles. The researchers developing PRINCE2® found that if the seven principles were employed during a project, then a successful outcome was more probable. The researchers also found that if a project was missing any one of the seven principles, then failure was more much more likely to occur. These seven principles make up the core of the best practices for project management:

• Continued Business Justification • Learn from Experience • Defined Roles and Responsibilities • Manage by Stages


14

• Manage by Exception • Focus on Products • Tailor to the Environment

Throughout the rest of this chapter, we will explore each of these principles in-depth. It is important to understand these principles, as we will refer back to them in subsequent chapters when covering the seven themes and seven processes.

Principle: Continued Business Justification Are the benefits worth the risk? This is the question asked by the principle of continued business justification. Before a project is undertaken, and continually throughout its development and execution, it is important to determine if the project is going to be worthwhile for the organization to conduct. If the project is determined to be too risky or hold too little value, then the project should not begin. If a project has already begun and is now determined to hold too little value to complete, it should be terminated prematurely. This evaluation should be conducted prior to the project being started, while the project is in development, and during project execution. Anytime a project doesn’t maintain a continued business justification, it should be terminated and closed. Continued business justification means that a project must always remain desirable, viable, and achievable. If a project remains desirable, it means that that the potential benefits outweigh the costs and the risks. In short, is the project a good value for the organization? If a project remains viable, then it is within the capacity of the organization to successful deliver the products.

For example, my company is primarily an online training organization. Students exchange their money for our services in order for us to help them pass their certification exams. Our organization has a very good track record of helping students successfully pass their certification exams. Therefore, if we were asked to participate in a project to design and deliver certification training materials for a new certification that was being released, we could accept this project because we have the capability to deliver the desired products. But, if you wanted to hire our organization to build a skyscraper, I would not


15

accept that project. Even if you offered our company a large sum of money to work on that project, we would not accept the contract because it is outside the scope of our capabilities and the project would be doomed for failure. In short, the project would not be viable. The last component of the continued business justification principle is that the project must always remain achievable. Achievability is defined as whether the use of the project’s products will result in the expected outcomes and benefits. For example, every four years the Olympics are held. The Olympics are essentially a very large and complex project that is initiated so that countries around the globe can come together into a neutral area and compete in various sporting events. During the Olympic games, athletes from around the world compete to determine who is the fastest runner, the quickest swimmer, or the best basketball player in a truly competitive event.

What is the desired goal of this complex project? Some might say that it is to encourage good-will between nations and comradery towards our fellow human beings. Do the Olympic games achieve this goal? Are the large costs required to produce these games worth allocating in order to pursue this desired outcome?

The Olympic Games Committee certainly believes so, because they continue to fund the games every four years. In terms of being a project, the Olympics is a desirable, viable, and achievable project with a continued business justification. The outcome of this project brings entertainment and joy to millions of people all around the world. In short, the project is achievable. Throughout the project’s lifecycle, we must continually evaluate it to ensure that it remains justified. What happens if, during one of these evaluations, it is determined that the project is no longer desirable, viable, or achievable? If this occurs, then the project should be prematurely terminated and closed. When determining the continued business justification, it is considered normal to use a sunk cost analysis. During this type of analysis, the organization doesn’t consider how much has already been spent towards the goal, but instead only looks at how much more will have to be spent to reach the desired outcome. During the housing crisis in the 2008-2010, for instance, it was common to see many houses and condominiums left partially finished in areas of Florida and California. Many developers began these projects at a time of high home prices, making the projects viable and


16

desirable to begin. By 2009, the home prices in these states plummeted, causing many of these construction projects to grind to a halt. These projects no longer had a continued business justification. As I drove through southern Florida one day in 2011, I still saw numerous neighborhoods left with unfinished homes and unoccupied condominiums. The original project owners had stopped working on the houses because they realized that they weren’t going to see a return on their investment during the housing crisis and its deflated housing prices; there was no longer a continued business justification.

This past year, I drove through that same area of Florida, and all of these homes had been completed and their new owners were living happily inside. What had happened here? During those intervening years, another company bought the abandoned, half-built homes and condominiums from the previous owners. As the housing market improved, these terminated projects were now found to be once again desirable and viable.

It is important to remember that even if your organization determines that the project no longer has a continued business justification, the project may find new life in another organization. In this case, the project assets could be liquidated to another organization to regain some of the sunk costs expended so far on the project. In the house example above, this is exactly what occurred. As an organization, we certainly do not want to waste money, therefore we often seek to find a project that has a good return on investment. But, it is also important to realize that the benefits of a project are not solely monetary. You may work on a project that produces good-will towards your organization, increases your brand recognition, or some other intangible asset.

An organization may choose to expend lots of money on advertisements with no direct return on investment simply to make their brand more recognizable. This is often true during a start-up tech company’s formative year. Regardless of the project, the business case must be defined at the beginning in order to ensure that all stakeholders and supporters know what the expected outcome should be. If your project is on track to complete that outcome, the project will likely be funded and approved to continue forward to the next stage.


17

Business Case

As the project progresses throughout its lifecycle, the project’s continued business justification is considered by comparing it back to the initial business case. A business case is a product that provides the justification for the project. The outline of the business case is developed during the pre-project phase and is utilized to determine whether or not the project should be initiated.

Often, during a brainstorming session, executives come up with dozens of ideas. Not all of these ideas, though, should become their own projects and have resources invested into them. For each idea, a basic business case containing the functionality that will be created, the rough costs associated with executing the idea, and the basic timeline for execution is created. This is then presented to the senior executive or resource sponsor, and, if they approve the business case, the idea will receive the funding and resources necessary. Then, a project team will be established to add more details and structure to the original idea during the project initiation phase.

This is just the first version of the business case, though, and it will be updated several times during the lifecycle of the project. It then becomes the reference document to evaluate the continued business justification against throughout the project to ensure that the project remains desirable, viable, and achievable. Creating a business case is always mandatory, and it is a required product under PRINCE2®, even if your project is compulsory, regulatory, or dictated by an executive.

It is inevitable that some problems will arise during the lifecycle of the project. When these problems occur, the project team will need to provide the executives and resource sponsor with choices of how to proceed, known as courses of action. Multiple ways of solving a given problem are presented and the executive then decides which course of action to implement based upon the business case. For example, when my organization was designing our online training platform for our video-based courses, we had a requirement to test students during the training to determine if they were retaining the information being presented. We considered multiple courses of action: using an electronic quiz, providing an online survey, or offering a downloadable text document for the student to answer questions offline. My team created an initial business case to describe the functionality we needed to obtain and their proposed course of action:


18

a quiz app for iPhone and Android users. The team provided the resource sponsor (me) with a list of potential features for the app, the rough cost of developing it, and an estimated timeline of when the app could be available to our students. The executive then considered all the options presented, weighed the cost, benefits, and risk, and determined that there was a business justification to proceed forward. That is an example of what it looks like to develop and get a business case accepted in the real world. A business case has six key components.

• Reason for the project • Expected benefits and dis-benefits • Timeline • Cost • Risks • Underlying assumptions

In the case of the app, the reason for the project was to give students a way to take practice quizzes and to monitor their progress toward retaining the information presented in the video-based courses. After this, the expected benefits and dis-benefits are listed. These are the good things and bad things that you expect to happen during the project. This listing can also be used to help determine at what point the project should be terminated (if the dis-benefits outweigh the benefits).

As part of the business case, a basic timeline for the project should be created with a rough estimate of cost. During the creation of this timeline and cost estimations, you are not required to be exact. When creating a timeline, it may be sufficient to state it will take 6 months to deliver the product after approval to initiate the project has been granted, for example. In terms of creating the cost estimate, you need to have a rough estimate of the budget that will be required. At this stage, you don’t need to say it will cost us $10,134 to create the app, but you should be able to say that it will be between $10,000 and $12,0000.

The business case must also include a description of the risks involved in undertaking the project. These risks will be made based on your underlying assumptions for the project. In the app example, our organization made an underlying assumption that 75% of our customers were iPhone users. As our team


19

was determining what type of quiz app to develop, we considered four possible solutions: an iOS app, an Android app, a Windows mobile app, and a web-based application. Our underlying assumption drove us to prioritize the development an iOS version of the app before even beginning a subsequent project to develop an Android variant. Unfortunately, that assumption had turned out to be incorrect, and, once we launched the app, we discovered that we did not get the traction in the marketplace and the return on investment that the organization expected. This caused use to reevaluate our underlying assumptions; we learned from our mistakes, and quickly focused our efforts on accelerating the development timeline of an Android version. All of this information was presented in the business case, which allowed us to revisit it as we decided whether to continue development, change direction, or terminate the project. The first business case created is just an outline. It should be short, no longer than a couple of pages. The actual format and length of the business case will be determined by your organization and its preferences. Some organizations prefer a longform report style business case, whereas others may simply accept a PowerPoint brief.

Principle: Learn from Experience

One of the most important principles is to learn from experience. As the old axiom states, “Experience is the best teacher.” PRINCE2® asks the question, “How can the project team learn from both its successes and failures?”

When working on a project and something is successful, it is important to learn why that project produced the expected outcome. Conversely, when a project fails, it is important to learn why it failed. This allows us to capitalize on our strengths, while avoiding the pitfalls that caused failure in previous projects. It is important to learn both: what works and what doesn’t. In addition to learning from our experience, it is important to learn from the experience of others too. Everyone makes mistakes at some point; therefore, PRINCE2® includes mechanisms to learn from the mistakes of others in order for use to avoid those same mistakes. To capture this experience for others, lessons reports are created both during and at the conclusion of the project.


20

If you were tasked to conduct the software rollout of Windows 10 to every desktop computer in a multi-national organization, it would be a great idea to review the lessons learned from the last few projects that were similar in size and scope. For example, the organization has probably conducted similar software rollouts over the past decade when they upgraded from Windows XP to Windows 7, or from Windows 7 to Windows 8.1. While the projects won’t be identical, many of the problems experienced may be similar and reviewing the lessons from that project team could save you a lot of time and effort, as well as help to minimize project risk.

Lessons Learned

As a project manager, it is important to always capture the lessons learned during the execution of the project. Many project teams wait until the project is being closed out to begin documenting their lessons learned, but this is not considered a best practice. Our memories fade over time, and the crisis you faced during the first month of the project may seem like just a minor issue by the time you begin to close the project a year later. Therefore, always write down the lessons learned as you work through a project, while the issues and events surrounding them are still fresh in your mind. These lessons learned will be valuable not only to your future self, but to other project managers, as well.

It is the project manager’s responsibility to identify, document, and disseminate lessons to the project board who oversees them. That board can then take that information and pass it along to other project managers and enable the horizonal information flow between different projects across the organization. This hierarchy of information transfer ensures that lessons are continually passed up, across, and down the organizational chart to aide different project managers in learning from each other’s issues and challenges. Hindsight is 20/20 and it is easy to look back on a project and ruminate on things that you should have done differently. As project managers, we are constantly attempting to manage risk to the project and it is impossible to know what will happen in the future. Mistakes will happen, and organizations should adopt a culture of learning from those mistakes instead of simply chastising project managers for those mistakes. Also, it is important to note that lessons don’t always have to be negative. When something occurs on the project that was very


21

successful, it is important to also capture that as a lesson so that others can know what works well for certain types of projects, too.

As lessons are identified, they should be captured in the lessons learned log. This log is created during the startup phase of the project, which will be discussed in detail in Chapter Five. At the end of each stage of the project, the lessons learned log should be summarized and a lessons report should be created by the project manager. This report is then submitted to the project board for distribution to other projects and to the organizational lessons learned database, if one exists. A final lesson report also should be created during the closing a project phase. This final report provides a fully retrospective look at the project and can help identify patterns or trends that occurred in the project. If your organization submits to auditing to ensure compliance with the PRINCE2® methodology, the lessons learned are crucial. Assurance auditors will ask for evidence that your organization not only captures and reports on the lessons, but that they are actually learned. Some organizations have a bad habit of collecting lessons, but never implementing any changes. So, instead of lessons learned, I like to call these lessons observed.

In this case, the organization’s personnel saw an issue or problem, wrote it down, and then immediately forget about it. The lesson was never really learned because there was no implementation to prevent the same problem from occurring in the next project. For this reason, auditors look for proof that lessons are actually used to improve the process and prevent future mistakes. Lessons learned are not the same as lessons observed; taking action makes all the difference.

How Are Mistakes Prevented During a Project?

A project manager should always review the existing lessons report

prior to starting a project, as this will help them avoid mistakes already made by previous teams. These lesson reports should be stored in some type of repository. Whenever a project manager provides a lesson report for their project to the project board, that report should also be entered into an electronic database or collection system in order for its contents to be searchable by other teams.

Another key to preventing mistakes is to recruit experienced members to your project team. I work with a lot of students who are trying to break into the cybersecurity field. They are often frustrated


22

because it is hard for them to get their first job due to lacking experience. But, they also can’t get experience because so few employers want to take a risk by hiring someone new to the field.

Why is there such reluctance to bring new people into the field who don’t have experience? Simply put, a lack of experience tends to breed more mistakes. To minimize project risk, you should have team members who have expertise and experience in the area that the project concerns. For example, if you are developing an iOS app, you should probably have some people on your project team that have built an iOS app previously. If not, your team is going to make more mistakes and increase the risk of project failure.

Now, we have to balance this with creating a sustainable project team for future projects and increasing our organization’s capacity for conducting these types of projects. To do that, we need to bring in new people. If your organization finds itself in this situation, I would recommend you bring in a few junior, less experienced personnel and pair them with more senior, experienced personnel. By working closely with the experienced personnel, the junior personnel will gain valuable experience and the risk is mitigated due to oversight by the senior personnel.

Principle: Defined Roles and Responsibilities

It is crucial that each team member knows exactly what is expected of them during every phase of the project and how they are to go about their duties. The principle of defined roles and responsibilities ensures that each person involved in a project knows what functions they are fulfilling and what work is expected to be performed by each job function. To ensure this is understood, the project manager should provide each team member with the common terms of reference and role descriptions for each role or job function. This ensures that if an employee is told that they will be serving as the senior supplier, for example, they will understand everything that the position entails. Each team member must be given the the correct level of authority to perform their role and ample time to dedicate to the project. If a person does not have the time and resources to dedicate to a particular project, then they won’t be able to adequately fill their defined role, which could cause project failure. Project managers


23

should always consider time constraints when deciding who has which role and associated responsibilities. Moreover, proper leadership ensures a higher likelihood of success. The project manager is responsible for leading the project team members and determining the appropriate organizational structure for the project. This structure may be horizontal or vertical. A horizontal organization tends to be flat, where each team member is empowered to talk to any other person working on the project. In a vertical organization, a stricter hierarchy is used to ensure information flows up and decisions flow down the organizational structure. PRINCE2® doesn’t specify that your project must use a horizontal or vertical structure for use inside the project team but recommends that you have a defined structure that is communicated to the team. The details of that structure are left up to the project manager to design and execute. When considering the organization above the project manager’s level, though, PRINCE2® does recommend a vertical management hierarchy. At the top of this structure is the project board. The project manager is underneath the project board, reports to the board, and receives decisions from the board to execute. Under the project manager, it is suggested to have team managers who can focus on specific parts of the projects in detail.

This basic structure allows the project board to direct multiple projects at once, each with their own project manager. Each project manager can then have a team manager working underneath them on specific areas of concern, as shown in the figure below:

Corporate or Program Management

Team Members

Project Board

Change Authority

Senior User(s)

Project Support

Team Manager(s)

Project Manager

Business, User, and Supplier Project

Assurance

Senior Supplier(s)Executive


24

As shown in the organizational chart, the top of the organizational structure is vertical, but the project manager is empowered to decide what the composition of the team, team management, and project should be.

Project Board

The project board is a team consisting of three distinct roles: the executive, the senior user, and the senior supplier. These roles can be filled by one or more people, with the exception of the executive, which can only be filled by a single individual. The executive is the person appointed, either by the corporation or by program management, to oversee the project board. They act as the final decision-maker and have overall responsibility and accountability for the projects that the project board oversees. The executive develops and owns the business case, from the first outline and throughout the execution of the project. The project board is not a democracy. The senior user and the senior supplier are empowered only to make recommendations, whereas the executive has the final determination for any decisions because they are solely responsible for the project’s ultimate success or failure. The senior user role represents the end user’s needs in the creation of the project’s final product. They serve as a liaison between the project board, the project manager, and the end users. It is the senior user’s responsibility to supply the benefits review plan, which is a document that outlines all of the good things that we expect as a result of the project.

The senior user role can be held by one or more people. On larger projects, the board may have multiple senior users. On the other hand, if the project is small then the executive may simultaneously fulfill this role in addition to their original role. For example, let’s assume an organization wants to create an automated log analysis program. The benefit of this program might be listed as saving money on labor costs by reducing the hundreds of man-hours currently utilized to review log files from the servers and hosts manually. This new automated log analysis program (the outcome of a project) must be capable of swiftly identifying issues and highlighting those in order for cybersecurity analysts to more rapidly perform remediation actions. Even if you


25

aren’t in the cybersecurity field, you should understand that this example is trying to solve some problem in order for the organization to save time and money. The senior user’s role is to ask questions of the project board, such as:

• What project outcome will the end user receive? • How does it help the end user? • Does the end user want this outcome?

The third role is that of the senior supplier. This role is responsible for representing the interests of the people or organizations that will be designing, developing, and implementing the project’s outcome or final product. This role can be fulfilled by one or more people, like the senior user role.

Returning to the example of the quiz app, the senior supplier would represent the design team, the graphics team, the programming team, and the app development team. Whereas the senior user represents the students who will be using the app, the senior supplier instead represents the interests of the people or organizations who are building the app.

The senior supplier is responsible for supplying resources for the project, such as people, tools, and expertise. The senior supplier may come from within the organization (IT director, purchasing manager, etc.) or they may come from an external vendor, subcontractor, or supplier. If an organization initiated a project to design, build, and move into a new corporate headquarters, they would have numerous suppliers involved: architects, general contractors, plumbers, electricians, roofers, not to mention all the suppliers associated with outfitting a server room with the proper information technology equipment. In this example, this is a large and complex project, so numerous senior suppliers may be involved at different stages of the project. Your project board may opt to have a representative from each supplier directly involved, or may have a singular senior supplier that represents the organization’s contracting office who in turn interfaces directly with the underlying suppliers. PRINCE2® assumes a customer-supplier relationship in its methodology. In this context, however, the customer is not necessarily your organization’s paying customer. This customer-supplier relationship is represented by the relationship between the senior user (the customer) and the senior supplier (supplier). If a project’s outcome


26

(the product) is being created, the customer is the end user. This end user may be a part of your own organization, depending on the project undertaken. In the example of the new organizational headquarters, the customer is the employees who will be working inside the headquarters, not a paying customer. While the executive, senior user, and senior supplier are the only three required roles in the project board under the PRINCE2® methodology, there is often a fourth role that is added in many organizations: the stakeholder. A stakeholder is any person or organization that has an interest in the outcome of the project. Stakeholders may be involved in the building of the product, using of the product, or managing the product. These people may or may not be given a voice during the planning and execution of the project, though.

For example, a student may be a stakeholder for the outcome of a project being conducted by my company. Once the product is complete and the project is closed, the student will become the end user. Often, though, the end user is not consulted directly; instead, the senior user represents their interest and may not have directly consulted the stakeholder (the students) to determine their exact needs.

Principle: Manage by Stages

When an organization initiates a project, a high-level project plan is required that covers the overarching list of tasks and a rough timeline or schedule. This high-level project plan is then broken down into smaller, more manageable stages. These smaller stages are used to allow the project to be more accurately planned and executed over a shorter period of time. This aims to reduce risk and makes the project more manageable on a day-to-day basis. The concept of breaking down a larger project into smaller portions is the principle of manage by stages. There is a limit to how accurately a project team can realistically plan when dealing with a large project. Consider the example of creating a project for a family vacation from Washington D.C. to Disneyland. Our business case was presented, and the course of action selected was to drive across the country to our destination in California, some 3,000 miles away. Our project was estimated to take


27

three weeks with one week allocated to enjoying Disneyland while the other two weeks are reserved for the drive to and from California.

As we begin to plan the trip (our project), we can determine at least three different stages: the drive to California, enjoying Disneyland, and driving back to Washington, D.C. If we were to plan the entire trip today, from end to end, we simply cannot be accurate in our schedule and cost estimates because we can’t know what traffic will be like along the entire route because it’s going to change on a daily basis. Similarly, we don’t know exactly what the cost of a gallon of gas will be next summer since that is controlled by influences outside our control. Instead, we should develop a detailed plan that is added stage by stage.

Before the next stage is begun, the generalized plan must become more specific, though. For example, a few days before our team begins the project (gets in the car to drive to California), we can look at Google maps and see what traffic patterns will be like for the specific route we plan to drive. This information can then be used to determine how many hours per day we will need to spend on the road, how much gas will need to be purchased, and what type of restaurants will be available for the team to purchase food during the trip. Because we have broken the larger plan down into more manageable stages, we can now create more accurate schedules, tasks, and costs for each stage.

The same thing holds true for all projects. Managing by stages allows an organization to plan more accurately by the project board to postpone the agreement of specific details until closer to the beginning of each stage by waiting until the end of the previous stage. This allows the project board and the project manager to more accurate assess the costs and timeframe of the next stage than if the entire project was planned out from the beginning.

Stages

How many stages are needed in a project? PRINCE2® states that

at least two stages are required to be used: the initiation stage and the delivery stage. The project board, though, can dictate the use of additional delivery stages, as desired.

The initiation stage is used to plan the overall project from a broad perspective to create an overview of the project plan. A delivery stage is used to execute and deliver the project’s outcome or products using the detailed stage plan.


28

The initiation stage ensures that all costs and timescales are considered before work on the project delivery is ever started. During this stage, a Project Initiation Document, or PID, is created and is used by the project board to determine the project’s viability to continue to the next stage. The PID every item that must be completed prior to moving on to the next stage, and it provides this level of detail for every stage in the project. It is used as a project outline and overview.

In the cross-country road trip vacation example, the initiation stage would occur prior to beginning the vacation and provide the overall route, timeline, and budget. Then, the delivery stage could be approved and begin execution. This would manage the day-to-day activities (where to eat, where to sleep, how far to drive). If the project board wanted to provide tighter controls, multiple delivery stages could be used. For example, one delivery stage could be created for each day of the vacation, providing the detailed plans for each day. Then, along the way, before we enter a new stage (before we go to sleep for the night), the executive could approve the plan the next stage (the activities planned for the next day).

Planning Horizon

The planning horizon is the length of time that a project

manager or project planner can accurately and realistically accurately plan ahead. Shorter projects have a relatively longer planning horizon and can therefore be created with an increased level of detail. Larger more protracted projects have a relatively shorter planning horizon and therefore must be separated into more delivery stages to reduce the risk to the overall project.

For instance, if you are tasked with a project to build a custom home, it may take 12-18 months to design, build, and deliver the desired outcome. To reduce risk, this project shouldn’t have only an initiation stage and a delivery stage, but instead should have multiple delivery stages. This creates breakpoints in the plan and execution where the project board and the executive can ensure that everything has been accomplished in a stage before moving to the next stage. If someone installed the drywall in the home before the plumbers installed the water pipes, that would be a big issue. By creating these end of stage checkpoints, this type of issue can be avoided.


29

PRINCE2® suggests three levels of plans: a project plan, a stage plan, and an optional team plan. Project plans are not detailed; they are broad and specify things like the timeline, overall cost, and number of stages to be utilized. Project plans are developed by the project board. The stage plan, on the other hand, is built by the project manager and is more detailed. Lastly, the team plan is incredibly detailed.

Using the example of the custom-built home project, the project plan might describe that the house will cost $500,000 to construct, will take 15 months, and is broken down into four delivery stages. During one of those delivery stages, the project manager would provide the details of when the plumbing, heating and cooling systems, and electrical will be installed. Next, the team manager in charge of the plumbing installation might create a team plan or work package for the different types of plumbing that will be installed. The team manager in charge of the electrical would create a similar team plan. The Project Plan is broken down into Stage Plans, and those are broken down into manageable Team Plans or work packages, from a larger, broader plan to a more detailed plan.

Stage Boundaries

Stage boundaries occur at the end of the current stage of the

project. Prior to moving from the initiation stage to the delivery stage, for example, the project manager submits an end of stage report in order for the project board to make a Go/No-Go decision on whether to continue the project and move into the next stage. These stage boundaries create decision points that provide the project board with focused cancellation points for the project. Each time a stage boundary is reached, the continued business justification is once again considered.

Back to our Disneyland vacation example, let’s pretend that we arrive at the hotel on the first night (our stage boundary). Our original stage plan stated it would take us eight hours to drive to Columbus, Ohio, but it actually took ten hours because of the traffic. Now, the project board (Mom and Dad), need to assess the continued viability of this project (vacation). Will we still get to California on time? Do we even still want to go?


30

Our project board figures, we are only two hours behind schedule, and the project still has a continued business justification. The project board reviews the stage plan for the next stage (day two). Stage Two is approved and everyone goes to sleep for the evening. The next morning, the entire family gets back into the minivan and start driving west again.

The family drives all day and it takes 18 hours to get to our next hotel due to some horrible traffic. Getting to the hotel that evening, the project board again assess the progress made during stage two. All of the objectives were completed for stage two (they made it to their hotel), but the delay was tiring, and they are questioning the continued business justification. Is this trip really worth it now? The project board looks at some traffic forecasts and decides, it isn’t. Instead of continuing into Stage Three, the project board cancels the project. The vacation is over, the project was a failure. The No-Go decision has been made.

Now, that is arguably a silly example, but it should make the concepts easier to understand because the same things occur in projects every day. At the end of each stage, the project manager updates the project plan with a comparison of the forecast against what actually happened. Perhaps we thought that a project would cost $10,000 and then, at the end of the stage, we have already spent $12,000. These type of cost overruns are common reasons that projects fail, they simply run out of money or the senior executives in the organization might decide to cancel the project.

The project board controls the project using the project plan and the stage boundaries. Every time a stage boundary is approached, the project board must decide whether the project should be continued. The project manager must update the project plan as part of their end stage report. This is then used during the stage boundary decisions by the project board and allows for effective management by exception.

Principle: Manage by Exception

How can we manage a project more efficiently? The answer is to manage by exception. This principle empowers personnel to make decisions within an allowable and agreed upon tolerance. By embracing this principle, the executive, the project board, and even the project


31

manager can get more work accomplished without focusing on the in-depth day-to-day details.

When an organization utilizes this principle, the project manager only requires decisions from the project board and the executive when a stage boundary is reached or a significant deviation from a budget or an approved plan is expected to occur. The project board doesn’t have to concern itself with the day-to-day progress of the project and instead trusts the project manager to handle those details within the agreed upon tolerances.

Manage by exception eliminates a lot of meetings and micromanagement. This creates a more efficient project and reduces the amount of overhead involved in the execution and management of a project.

It is important to create agreed upon tolerances in the creation of the project plan, the stage plans, and the optional team plans because projects are fluid and change is constantly occurring. If the project board estimates that a project will cost $10,000 to complete a particular stage, but due to changes that might be required during the stage the actual cost might end up costing $9,000 or even $11,000.

How will the organization deal with these changes that may occur in the project? Should the project manager consult the project board every time there is an issue and get approval? If the organization is using the manage by exception principle, then tolerances are built into each project objective or stage to handle changes that are necessary during a stage.

If a stage is expected to cost $10,000 with a 10% tolerance is authorized, the project manager can handle any and all changes to the stage as long as the cost for the stage remains between $9,000 and $11,0000.

During the execution of the project, the project manager submits a highlight report at regular intervals to inform the project board on the progress of the project. If a tolerance for any stage is forecast to be exceeded, then the manager must submit an exception report to the project board.

In our previous example, if the forecast for the cost of the stage was $12,500, then this is a 12.5% increase over the target and outside the 10% tolerance allocated by the project board for this stage. The project manager will submit an exception report to the project board detailing the issues, potential solutions, and a recommended course of


32

action. The project board will then make a decision that could involve increasing the budget for the stage, reducing spending in a different category, or even eliminating some user requirements for this stage to bring the project back into tolerance.

Tolerances in projects are not just set for cost, but also for quality, and time. Often, a project board may allow for additional time in order to save on cost. At other times, the project board may add additional monetary resources to spend in order to meet a faster timeline.

The Project Objectives

There are six project objectives for which tolerances are set: time,

cost, quality, scope, benefits, and risk. These objectives are balanced and set forth during the initiation stage by the program initiation document. This document sets forth the initial tolerances that are agreed upon by senior management and the project board. All six objectives have tolerances created by the program or corporate management (senior executives) when the project plan is approved and become the target levels that the project board must use to control the project.

If the program or corporate management provide the project board with a tolerance of 10%, then the project board must control the project and keep it within tolerances. In this case, the project board would likely only give the project manager a smaller portion of that tolerance, such as 7%, and retain the other 3% of the tolerance for their own ability to authorize changes. The project manager may then take their 7% tolerance and provide their team managers with a tolerance of 4%.

This narrowing of the tolerances allows for each level of management to conduct their own manage by exception by regulating the project deliverables through controlled tolerances. If a tolerance is forecasted to be 5% (1% higher than their tolerance) by the team manager, then they would raise the issue to the project manager who can then act prior to the issue exceeding their own 7% tolerance. If the tolerance would be higher than 7%, then the project manager would raise the exception to the project board who can act before their own 10% tolerance is exceeded. If their 10% tolerance is exceeded, then the project board would raise the exception all the way up to the program or corporate management for action.


33

These tolerances layer upon each other and allow the lowest level of management to deal with the issues early before raising an exception to the next higher level. This allows a project to be executed efficiently and allows progress to keep moving forward.

The manage by exception principle’s biggest benefit is that is free

up the time of senior management. This allows them to focus on strategy without becoming overburdened by the daily decisions of a particular project. The United States military has embraced the concept of manage by exception during their global operations. For example, a Navy ship might be given a mission. The senior leadership at the Fleet headquarters might dictate that the ship must go from California to Australia for a mission, but they don’t dictate the route the ship must travel. Instead, they provide the Captain of the ship the overall plan and provide him with a tolerance to execute that plan. The Admiral might tell the Captain that the ship must be in Sydney, Australia within 35 days (within a 2 day tolerance). At that point, the Captain is free to chart his own course, but if bad weather is experienced and the ship will not arrive in port on time (within tolerance), then an exception would be reported up to the Admiral and permission requested to be late for arrival.

But the manage by exception doesn’t stop with the Admiral or the Captain, because the Captain needs to eat and sleep. So, the Captain also delegates down the plan a few days at a time (like a stage plan). The Captain would tell the Lieutenant to chart the course from point A to point B (within a smaller tolerance). Now, it becomes the navigator’s


34

responsibility to ensure the watch teams who are driving the ship make the correct amount of progress from one point to the next.

Manage by exception relies on manage by stages, as the delegation downward requires smaller and smaller portions of the plan. Personnel are given leeway to execute their portion of the plan autonomously as long as they stay within the tolerances set for them. They provide highlight reports up to the next higher management level when things are progressing on track, and exception reports when tolerances are forecasted to be exceeded.

There is no longer a need for regular progress meetings because we have the highlight reports and exception reports. This is according to PRINCE2®, of course, but your organization may feel differently about meetings. I have worked in many organizations where weekly progress meetings were the norm. Everyone gathers around a table, they sit around talking, and often it is a complete waste of time as everyone reports that everything is progressing as planned. If those organizations had used management by exception, though, those meetings could be entirely eliminated and hundreds of man-hours a year would be able to conduct productive work for the organization. If you provide well-established tolerances for your project stages and empower your personnel to make decisions as long as they stay within those tolerances, you will have a more efficient and successful project.

Principle: Focus on Products

The principle of focus on products ensures that we always

successfully deliver products that lead to the realization of the product’s benefits. It begs the question, “Are we delivering the required quality which has been tasked of our project?”

If we want to deliver an app, then the app needs to work and provide the approved level of quality requested by the end user (through the senior user). If the project seeks to build a house, then success would be defined by whether or not the homeowner is happy with the house upon delivery. This is the foundational idea of the focus on products principle. PRINCE2® is always focused on the end product and the processes that are utilized to create them. It is all about successful delivery, so that the stakeholders’ expectations are met throughout the product delivery. The three key stakeholders are the executive, the senior user


35

(representing the end user), and the senior supplier (representing the suppliers). If the three stakeholders have their expectations met, then we have a much great chance of having a successful completion to the project. When focusing on the delivery of a product, it is imperative that the product delivered meets a certain quality threshold. This quality level is agreed upon by the stakeholders during the project inception.

If the project manager is tasked with installing a computer network, then the stakeholders should levy the requirement upon them for a certain level of uptime, for example. Assuming that the network will require a 99% uptime, then the quality of the network could be measured by the amount of uptime, and conversely downtime, that is experienced by the network under normal conditions over the first 3 months of usage.

If after a year, the network is shown to only achieve 95% uptime, then the project did not deliver the agreed upon quality and the project is deemed a failure. If instead, the product (the network) achieved a 99.2% uptime over the past 3 months of usage, then the product exceeds the minimum level of quality (99%), and this is considered a large factor in the successful delivery of the product. In addition to the delivery of quality, a product must achieve what is referred to as fit for purpose. This means the product meets the agreed upon requirements for the level of utilization for which it was designed. Does the product fulfill the customer’s needs?

If the project was chartered to build an electric car that could travel over one hundred miles prior to requiring a recharge, but upon test driving the car it was found to only travel seventy-three miles before running out of energy, then the product of the project (the car) would be deemed as unfit for purpose. Simply put, the car did not meet the customer’s needs and is not fit for purpose.

PRINCE2® always focuses on the end result in a project: the products. For this reason, even if we were able to deliver the electric car in our example for half of the budgeted cost and within two-thirds of the budgeted timeline, it would still not be considered fit for purpose because the car couldn’t meet the needs of the customer, namely to be able to drive one hundred miles on a single charge. To ensure a project remans fit for purpose, it is important to utilize product-based planning. While some other project management


36

methods such a PMP will focus on activity-based planning (how to do things), PRINCE2® focuses instead on the end result (the products).

Products are identified early in the project planning process. By using product-based planning, the project manager and the project board detail exactly what needs to be accomplished prior to work beginning. This provides the project manager and those working on the project with a checklist of items that will need to be created and reduces the likelihood of any kind of scope creep. It also increases the likelihood that the final product will be accepted by the user since it will be designed to meet their requirements. This also helps to prevent customer dissatisfaction.

Product Descriptions

But how does a project manager know exactly what the customer wants delivered? This is done through the use of product descriptions. Product descriptions act like a blueprint and contain the purpose, composition, specifications, quality criteria, tolerance levels, and acceptance criteria for any given product. These aspects are discussed, and concurrence is reached prior to work beginning on the project in order to help the project team in estimating the amount of resources that will be required to meet the delivery criteria. Returning to our real-world example of designing and building a custom home. The future homeowner would review the blueprints with the general contractor and then decides where the light switches should be installed, the type of heating, ventilation, and air conditioning (HVAC) that should be utilized, the type and color of the tile floors for the bathroom, whether hardwood floors or carpet should be utilized, and hundreds of other details.

All of these details are drawn into the plan and written down as part of the product description. After the meeting, both the general contractor (project manager) and the home owner (senior user) will agree upon the product descriptions and finalize them in writing.

A few months later, the happy homeowner, though, is not happy with the house that was delivered. They call the general contractor to complain because there is lime green carpet in their master bedroom. The general contractor (project manager) and the homeowner (senior user) sit down to discuss the issue. The project manager pulls out the product description from their briefcase, showing the homeowner the


37

details that describe this lime green carpet in the master bedroom. At this point, the homeowner (senior supplier) has no recourse but to accept the delivery of the product or issue a change order (complete with additional funding) to have the carpet replaced with a more appropriate color.

If instead, though, the product description stated beige carpet, then the project manager could be at fault for the error and be required to replace the carpet using their change or risk budget since this was an implementation issue on their part. The product description documents help us to avoid much of the conflict that could occur during a project, since it is the agreed upon requirements from the customer’s perspective. It ensures that all parties are in agreement prior to the spending of large amounts of time and resources on the project. Principle: Tailor to Suit the Project Environment

Tailor to suit the project environment is a principle that

modifies or adapts a project based upon on its size, scope, or complexity to meet specific goals or needs. There is no one-size-fits-all solution in project management, and PRINCE2® doesn’t attempt to become all things for all projects. The methodology is highly adaptable to each and every project’s unique specifications.

Projects can occur in many different contexts: • Cultural • Geographical • Complexity • Scale • Risk

Every project is truly different, but PRINCE2® uses tailoring to ensure that it can efficiently and effectively work with any project. But how can PRINCE2® be adapted to meet the needs of all projects? When tailoring to suit a project, things can be added to the project framework to help it fit into any organization. For example, under the manage by exception principle, it was determined that there is no longer a need to conduct weekly progress meetings with the project board because they are replaced by the highlight reports and exception reports. While this still holds true, many organizations nonetheless still desire those regular progress meetings. This is a simple


38

example of using the principle of tailor to the environment because the PRINCE2® methodology is adapted to a particular organization’s procedures and standards.

A key concept of the PRINCE2® principle of tailor to the environment is that things can always be added to the framework, but they cannot be removed without breaking compliance with the framework. For example, adding the weekly meetings is perfectly in line with the tailor to the environment principles, but removing the highlight reports or exception reports from the process would remove this part of PRINCE2® and not be considered tailoring. Instead, this removal would be considered a fundamental change. Any tailoring that the organization performs during the implementation of the PRINCE2® methodology must be documented as a change to the methodology in the Project Initiation Document (PID). Remember, the PID is created at the beginning of the project during the initiation stage and provides an audit trail and evidence that the project is compliance with PRINCE2® methodology. Therefore, any changes or tailoring that occur to the methodology must be documented by the organization. By doing so, an external audit could be conducted and verify that PRINCE2® is being followed by the organization, even if some various components have been added by the tailoring principles. Remember, every change made to the standard methodology must be documented in the PID.

What Should You Do for a Small Project? What should the organization do if a project is considered extremely small? Should they simply ignore PRINCE2® and conduct project management without the common methodology or structure?

Of course not! Even with small projects, they should still go through each theme and process in the PRINCE2® methodology. If not, the organization might be performing project management as PRINCE2® in name only and missing out on the benefits and efficiencies that are gained by using PRICNE2®. If the organization doesn’t formally use PRINCE2®, then they are not eligible to gain certification or accreditation for its proper use of the methodology, which may be required as part of some business contracts the organization is attempting to acquire.


39

When using PRINCE2® with a small project, however, the project team could speed up or scale down different processes for more efficiency. Still, each theme and process must be considered during the project lifecycle, even if it is only performed for a relatively short amount of time.

Let’s consider that you and I want to bake a pizza. We can make any type of pizza we want, from a 6” personal pan pizza to an 18” extra-large pizza, or even a 36” party pizza. Regardless of which pizza we decided to bake (small, medium, or large), we will be using the same set of ingredients, just in different amounts. For example, if we wanted a personal pizza, we would use much less cheese, dough, and sauce. If we left out one of these ingredients, then regardless of the size, our pizza will not taste quite right. It would not be fit for purpose.

PRINCE2® is performed much the same way—you still need to use all the all of the ingredients to make it work properly. This means using all of the principles, themes, and processes. Even if you move through a process very quickly, you still need to consider them all. While a full-scale PRINCE2® implementation may focus on a process for days or weeks, in a smaller project a project manager may only consider a particular process for a few hours.

Components by Another Name

Another aspect of tailoring the PRINCE2® methodology involves

changing the names of various parts of the methodology. This is considered an acceptable and quite common form of tailoring to the environment. No rules are broken when renaming items inside the methodology. In fact, much of the PRINCE2® terminology can be considered difficult or confusing by employees, and therefore it is often changed to something more user friendly. While the specific name being utilize for a certain item is not important, it is important that everyone working on the project within the organization uses the same consistent wording. It doesn’t matter if it is the PRINCE2® term or simply one assigned by the organization, as long as everyone uses a common lexicon. Many organizations, for example, don’t use the PRINCE2® term product description in their documentation. Instead, many organizations opt instead to refer to it as a requirements document. This change in terminology is completely acceptable as long as


40

everyone knows that the change has occurred and understands the meaning of the term. A requirements document will still meet all the requirements for a product description and therefore still meets achieves compliancy with the PRINCE2® methodology. To ensure everyone in the organization understands a common vernacular, it is important to include a glossary of terms, especially when the organization chooses to use specialized language instead of the default PRINCE2® terminology. Every part of the PRINCE2® methodology was created by studying and implementing best practices for over thirty hears. It is important not to ignore any part of the methodology. All seven principles should be considered, as should all seven of the themes and processes. These principles, themes, and processes can be scaled up or compressed down, as long as they are considered during your project planning and execution. The final consideration with the principle of tailor to the environment is the addition of additional themes, as appropriate, for a project. Themes such as human resources, communications, legal, procurement, or anything else that will best serve our organizational needs can be added to the project while remaining true to the PRINCE2® methodology. As long as the original seven principles, seven themes, and seven processes are not abandoned, then this tailoring is not only considered acceptable but encouraged. Adapting PRINCE2® is a wonderful thing because it focuses on the decisions made by the executive, the project board, and the project managers instead of the documents, templates, and meetings that overrun bureaucracy in our organizations. This is the true power of PRINCE2®: adaptability and tailorability.


41

CHAPTER FOUR The Seven Themes

OBJECTIVES

• Be able to list the themes in PRINCE2® • Understand each of the seven themes in PRINCE2® • Be able to apply the seven themes to a given scenario

The areas of project management that must be continuously addressed throughout the project are called themes. Whether you are initiating the project, directing the project, executing the project, or closing out the project, the seven themes provided by PRINCE2®should always be addressed. The themes are built upon the foundation of the seven principles, which are then in turn applied throughout the seven processes (covered in Chapter Five) in order to successfully, efficiently, and effectively complete the project. According to PRINCE2®, there are seven themes:

• Business Case • Organization • Quality • Plans • Risk • Change • Progress


42

Theme: Business Case

A business case is a required document that provides the justification for a project, and it is considered the first theme. As a theme, the business case requires project management professionals to put systems into place that will assist executives and decision makers in determining if a project is worthwhile to pursue. Simply put, the business case requires the executive present their reasoning for the project and its presumed benefits and dis-benefits. The business case, as a theme, is the implementation of the PRINCE2® principle of having a continued business justification. Each project should have two business cases developed: one for the customer and one for the supplier. Each business case considers a different vantage point and a different perspective in determining if the project is worth pursuing. The reason two distinct business cases are created is because the senior user will present one from the customer’s perspective and the senior supplier will present the other from the supplier’s perspective. Each of their higher-level managers must agree that the project should be supported and undertaken prior to the project board initiating the project. Remember, PRINCE2® always assumes a customer-supplier relationship. The customer specifies the products that they will require from the project since they will ultimately provide the monetary resources for the project to move forward. As such, they expect to receive distinct benefits when the project is concluded and its products are delivered.

The supplier is the person, team, or organization that delivers the products of the project to the customer based upon the agreed upon level of quality. Therefore, the supplier must decide if it is in their best interest to be involved in the project. The supplier may choose to support the project because there might be money to be made, a better reputation to be built, or some other benefit to their company or organization. For example, if my company wanted to have a website created, then I might serve as the senior user (the customer). To have the site created, though, the project will need a supplier to build it. This supplier might be external to my organization, such as an outside firm to which we outsource the development.

While my company may have created a business case and determined it is within our best interest to initiate the project because


43

the website will earn us revenue and increase our reputation, the supplier will also create their own business case. If the supplier determines it is in their best interest to build the website, then they can determine how much money they will charge, how long it will take them, and whether they might get more business from my organization in the future. All of these factors are considerations for the external vendor to ponder when developing their own business case. Also, the supplier doesn’t have to share their business case with my organization. In terms of PRINCE2®, the project needs to have a business case, which is a document owned by the executive. This combined business case is one of the management products that is produced throughout the PRINCE2® processes. An acceptable business case must always exist, otherwise the executive should terminate and close out the project. If both the customer and supplier cannot agree on the proper balance of resources and quality, then again, the project should be terminated prematurely.

Sunk Cost Analysis When the executive is determining if the project should continue into the next stage or be terminated, they should always consider the project using a sunk cost analysis. Using this type of analysis, the executive must ignore the amount of money already spent on the project and instead focus on how much more must be spent to successfully complete the project. The executive should always look towards the future when working with the business case in order to avoid being blinded into making bad decisions. Consider this example from a game of Texas Hold ‘Em, a popular variation of poker. You just bet $5 on the small blind, but then it comes around to you again. It will cost you another $5 to call to see the flop, which is the next three cards. You decide to call. The flop comes and the betting increases to $50. You call, and then comes the turn. Another round of betting ensues, and you call for another $20. Finally, the last card, the river, is flipped over. You have a weak hand at this point, but the other player bets another $10. You stop and think for a second, “Well, I already put in $80, I might as well put in another $10 and see if I can win.” This is effectively the exact opposite of using a sunk cost analysis.


44

If instead, you utilized a sunk cost analysis, you wouldn’t even consider the fact that you already bet $80. Instead, you would only decide if it was worth betting another $10 based on your current situation. Looking at your cards, you realize your hand is weak and you should probably fold. In project management, this would be the equivalent of terminating the project prematurely.

So, when considering a business case as an executive, you should always use a sunk cost analysis approach. You must ignore what has already put into the project and only think about what else will be required to get the project back on track and successfully towards completion. If it will require too much time, money, or resources, then it may simply be time to terminate the project.

The Business Case Document

At the beginning of the project, the executive produces the first business case. This version is only an outline or draft. In some organizations, this version of the business case may even be handled by the corporate or program management board instead of the executive because the executive for the project has yet to be chosen. For example, if an organization wanted to build a new iPhone app, the program management may create an outline of what the applications benefits might be, what functions it should perform, and the rough cost to develop it. However, once the program or corporate management decides to turn this into a project, the outline of this business case will be given to the chosen executive who will be responsible for its detailed development moving forward. This first draft or outline of a business case is then updated with additional levels of detail as the project moves through the initiation stage. To get started, only an outline is required, but to leave the initiation stage a complete business case must be created by the executive and approved by the corporate or program management. At every stage boundary, this business case will be updated. The Go/No-Go determination at each stage boundary will weigh the costs, benefits, and risks of moving forward with the project against the business case. If a continued business justification exists, the project can be approved to move into next stage. The business case can also contain some specialist products. These outputs are found at the end of the project by the users in the


45

customer’s organization and should change the way the users conduct their business as usual. For example, if a project was started to create a new filing and storage system for the organization, when the project is completed there should be a better way of filing documents than before the project begun. This is the realization of the project’s benefit. This is called an outcome and should have a measurable improvement over the previous way of conducting business.

Example of a Business Case For example, several years ago I was asked to build a business travel approval system for an organization. It was a rather low-budget project with a small scope, but it provides a great example of how a project can provide a benefit to the end user of the project’s product. When I began working for this organization, all travel approvals were handled by having an employee fill out a piece of paper with their personal details, the reason for their trip, and the estimated cost details of the trip for things like the hotel, flights, and rental car. Once this paper was filled out, the employee would then have to track down five different supervisors and approvers to physically sign this piece of paper before the plane tickets, rental car, and hotel could be booked. This process would often take four to five days to get every signature needed before booking could occur. When I arrived, the senior executive (corporate management) asked me to design an electronic system to replace this cumbersome system in order to speed up this travel approval process. This served as the very rough draft outline of the business case. Next, I was tasked as the project board for this project, serving as the executive, senior user, and senior supplier.

In the role of senior user, I interviewed the end users and asked them what they desired from this new automated travel system. Many users described the need to not have to leave their desks to get approval and for the process to be easier and quicker. From these interviews and discussions, I created the benefits that would need to be realized form the project, and these formed the basis for the project’s requirements.

In a project, the senior user should come from an area of the organization that is likely to be impacted by the outcomes of the project. In this particular example, I also often had to travel for work,


46

so I well understood the pain points associated with using the old-fashioned travel approval system. However, if you are not directly involved with the end result, then you would need to get someone involved as a consultant from the area affected. For example, if I was instead instructed to build an accounting system, I would want to embed an accountant on my team to make sure that they would get the benefits needed for their area of expertise. Next, I needed to add more details to the business case. I integrated the benefits and dis-benefits provided from the senior user, and I worked with the senior supplier, myself in this case, to ensure the business case was fully developed. Once the business case was ready, I went back to corporate management and asked for approval to initiate the project, asked for a specific budget, and recommended a timeline. Over the next two weeks, we created the automated system, beta tested it, and delivered it to the end users who could then realize the benefits of the project. In this case, the benefits were to minimize the amount of time it took to get travel approved. By the end of the project, the end user was able to log onto a website, input the location of their travel destination, calculate how much it was going to cost, and then the system would automatically route the approval through email from supervisor to supervisor to get the necessary approvals. This system was more efficient, and it was able to decrease the time for approval from four or five days into just a couple of hours. The end user was thrilled, the supervisors loved it, and the corporate management was pleased that we delivered the project on time and under budget. While this was a simple project, it demonstrates how the business case is developed to consider the needs of the senior user and the senior supplier.

Benefits Management Approach The senior user assigned to the project board is responsible for specifying the benefits and ensuring that they are realized upon completion of the project. This is often done through the creation of the benefits management approach. This is one of the PRINCE2® management products that is created during the project. This document specifies how, when, and by whom the benefits are measured.


47

Appropriate metrics should be created in order to determine if the benefits are actually achieved. In the travel system example, one of the benefits was to minimize the time it required to get a travel request approved. There was a goal metric set for this approval of less than four hours and the system was able to achieve this goal in the first two weeks of operations. During the product delivery, the benefits management approach was checked to ensure that the process was completed within the four-hour window before turning the management of the travel system over to the information technology operations department. The important thing is that the product delivery included a way of measuring the success of the system by updating the benefits management approach.

Minimum Requirements

There are three minimum requirements within the business case theme. First, the roles and responsibilities for the business case and the benefits management approach must be defined. Second, the business case must be written and maintained. Third, the benefits management approach must be created and maintained.

Theme: Organization

Organization is the second theme in PRINCE2®. Organization involves defining and setting up a project management team structure. This theme seeks to dictate accountability and responsibility for the project by implementing the defined roles and responsibilities principle to better organize the management and oversight structure within the project. If the roles and responsibilities are not clearly defined when beginning a project, then it is more likely to fail. In PRINCE2®, all projects operate under a customer-supplier environment where the customer specifies the end result of the project and pays for the project in order to ultimately realize the project’s benefits. The supplier, on the other hand, is the people, team, or organization that supplies the product that the customer requested.

Even if the project is conducted entirely within your organization, there is still a customer and a supplier. In this case, the customer and supplier may just be from different departments within the same


48

organization. For example, if the web development team in the information technology department builds a website for the sales and marketing department, then they are the supplier and the customer, respectively. These roles are in turn represented on the project board.

Project Board

In this example, the project board may consist of an executive

(assigned by the program or corporate management), the senior user (from sales or marketing department), and the senior supplier (from the information technology department). The project board is empowered with the authority to approve the plans, the deviations, and the resources needed for the project. The project board should be a small team, though, and not larger than five to seven people. If the project board is too large, then it may become too difficult to manage and effectively make decisions. But, in the end, the project board is not a democracy. Instead, the executive has the deciding voice because they are ultimately responsible for the success or failure of the project. Conversely, the senior user and senior supplier roles are focused on informing and advising the executive in conducting the decision making. When working on a project, remember that it is more of a benevolent dictatorship than a democracy.

The executive is the only role on the project board that cannot be represented by more than one person. The executive is solely responsible for representing the business and the organization that is paying for the project. Returning to our example of building a website using our internal staff, the executive should probably be from the sales or marketing department because their department will likely be paying for the project. Therefore, their executive should be ultimately responsibility for the project’s success or failure. While the executive should listen to the advice of the senior user and senior supplier, the decisions will remain theirs to make. The senior user is a role that specifies and realizes the project’s benefits. This role will dictate what end results and products the project should achieve. Again, returning to the web design example, the senior user should be someone from sales or marketing since they will ultimately be using the website. Therefore, they should be responsible


49

for making sure that the project meets their requirements in order for their department to realize the benefits. Even if the executive is chosen from outside the sales or marketing departments, the senior user should not be, in this example. The senior supplier is the person who is accountable for bringing together the required resources and skills to the project. The senior supplier is also responsible for the project’s quality. In the web design example, the senior supplier should be assigned from the web development or information technology department because they have the skills and required resources to design and build the desired website. It is important to have clear roles and responsibilities. This makes it easy to know who (role) is in charge of what (responsibilities). If something goes wrong, then it also becomes simple to know who is to blame. The real goal is for the entire team to work harmoniously together. But, realistically there might be a need for clearly delineated lines in the sand to ensure that the project continues to run efficiently.

Project Assurance

Another role is that of project assurance, who is responsible for making sure that the project manager is properly performing their job and to assure the project board that everything is running smoothly. This role cannot assist the project manager, but instead serves as oversight of the project manager. For this reason, the project assurance personnel cannot be directly involved in the delivery or execution of the project itself.

The role of project assurance can be filled by a project board member (such as the executive, senior user, or senior supplier), or the role may be delegated to a third-party within the organization. This person advises the project manager as needed and reviews documents before they are sent to the project board. They serve as the quality assurance check within the project.

Project Manager

The project manager is the person who performs the work and is responsible for the day-to-day project management activities as well as for reporting progress up to the project board. The project manager


50

creates the highlight reports and the exception reports. These two reports are double-checked by project assurance and are submitted to the project board in order to decide whether the project has a continued business justification or if tolerances are forecasted to be exceeded. This is the system of checks and balances created in the PRINCE2® methodology, ensuring that the project can go on successfully without any single person becoming a single point of failure.

Team Manager

Team managers serve beneath the project manager in the organizational structure. These team managers manage specialists with the required skills to design, enable, and produce the specified products desired in the project. Again, returning to the web design example, there may be a graphics team, a coding team, and a team working on the servers and infrastructure. Each of these three teams has a team manager who reports to the project manager. These team managers are responsible for delivering their products on time, within tolerances, and based on the team plans or work packages that have been approved by the project manager. The project manager will then receive their reports, consolidate them into their own highlight or exception report, and submit those reports to the project board at the agreed upon frequency.

Change Authority

The change authority is responsible for making decisions and granting approvals regarding requests for change, RFC’s, and off-specification requests. Changes either cost or save money, as well as change the requirements for the end product. Therefore, it is important to have another checkpoint and decision maker in place before a change is approved. Pretend that you are working on a project that requires a house to be built that was designed as a three-bedroom, two-bathroom house. All of a sudden, the homeowner decides they now want an extra bathroom added. It would certainly require numerous changes to the project to make this third bathroom a reality. Maybe the designs would need to be redrawn in order to eliminate a closet because there simply


51

won’t be enough square footage for it anymore. What about the additional plumbing that will be required to be run to support the new sink and toilet? Someone is going to have to approve all of these changes, and that person is called the change authority.

Project Support Another optional role is called project support. This person assists the project manager and team managers with daily administration, report generation, progress monitoring, and other necessary tasks. During small projects, there is not often the need for a dedicated project support person. Instead, these duties are fulfilled by the project manager themselves. If the project is large enough, though, then a full-time project support person is often necessary.

Stakeholders

There are a variety of roles that PRINCE2® recommends for project management, including the executive, the senior user, the senior supplier, the project manager, the team managers, the change authority and project support. Any of these roles can have more than one person assigned to them ,except the executive. Also, one person may also fill more than one role simultaneously, with few exceptions. It is important to remember, though, that the project assurance role cannot be combined with the project manager, team manager, or project support roles since the project assurance role conducts oversight of these roles. All of these roles are considered stakeholders, because they all have an interest in the successful outcome of the project. The people filling these roles all care about the products that will be created as a result of this project. While all of these roles are considered stakeholders, they are not the only stakeholders.

The end users of the project are also considered additional stakeholders, and there is no clear limit to the number of stakeholders in any particular project. Instead, anyone with an interest in the project may be considered a stakeholder. It is then up to the executive to decide which stakeholders should be consulted when making decisions about the future of the project.


52

Communication Management Approach

PRINCE2® requires the creation of documentation within the organization theme. The communications management approach is a document that outlines how communication should occur with the stakeholders by identifying their information needs. This document dictates the frequency and format with which communication will occur: a meeting, a report, an email, or something else entirely. For example, a project board may require a monthly or a weekly highlight report from the project manager; this information is drafted into the communications management approach by the project manager and submitted to the board for their approval.

Putting the Organization Together The organization theme is focused on creating a coherent organization structure. The project is ultimately approved by corporate or program management, at the top of the organizational structure. They select and empower the executive to lead the project board. The project board must also have a senior user and a senior supplier represented. Underneath the project board, there is a change authority and the project manager. The project manager, in turn, has team mangers placed underneath them. Finally, there are the team members at the bottom of the organizational structure. The organizational structure may also include some intermediaries, like the project assurance and the project support roles, as well.


The organization theme contains a few minimum requirements. First, the organizational structure must be clearly defined. This is usually done by creating an organizational chart that outlines the structure and includes the required roles. Second, the roles must be clearly defined, and the responsibilities determined for each role assigned. When a new person joins the project, they should be given a clear role and documented responsibilities outlining what is expected of them. Finally, the organization theme requires the communication management approach document to be created along with the product initiation document during the initiation stage of the project.


53

Theme: Quality

The third theme, quality, defines and implements the mechanisms in the project to determine if the products will be fit for purpose and if the project can provide the benefits which the customer expects. Does the product meet the agreed upon requirements? If not, the expected quality is not met.

Acceptance Criteria To determine if the project meets the quality requirements, acceptance criteria is developed. This criteria measures and defines the attributes for a set of products that the key stakeholders will consider acceptable. Acceptance criteria establishes the level of quality that must be achieved for the product and project to be considered acceptable and successful.

For example, consider an organization that is designing and building a car that has acceptance criteria set as “accelerates from zero to sixty miles per hour in under 4.6 seconds.” The first prototype is produced, and the car is taken out for testing. The car is placed on the test track and begins to accelerate. After 5.3 seconds, the car finally reaches sixty miles per hour. In this case, the project did not meet the acceptance criteria and the car must be reengineered to accelerate faster prior to being considered to have achieved the desired quality. Unfortunately, customer requirements are often vague. It is the job of the project board to ensure that well-written requirements and acceptance criteria are developed in conjunction with the senior user. In a previous career, I used to design and build websites. I would often have customers who would ask for the website to be faster, cheaper, or more user friendly, but these are not measurable criteria. Instead, I would have to work with the customer and ask questions like:

• How fast do you want it? • Do you want your load time to be less than two seconds? • How do you define user friendly?

If the project manager is provided with those detailed acceptance

criteria and measurable metrics, then it removes the guesswork of what is expected for the deliverables. Having proper acceptance criteria is


54

critical to ensuring a smooth and simple close out of the project at the end of development. The acceptance criteria should be documented in the project’s high-level requirements documents. This ensures that even before the project is initiated, the stakeholders have signed off on the criteria and understand what the project will deliver and to what quality level. Remember, always describe the acceptance criteria in measurable terms, so that you can determine if the products met those terms by the conclusion of the project. If at any time the project board or the project manager doesn’t think that the acceptance criteria can be met by the conclusion of the project, then the project board should consider the termination of the project.

Quality Management Approach The quality management approach is used to document the method of quality control used inside the project. Quality planning is the responsibility of the project manager. The quality register is a document that is used to summarize all the quality management activities that are planned or have taken place. This allows the project manager to ensure that the project remains on track and is meeting the quality requirements that have been set forth by the project board. The organization should utilize a quality management system that contains quality policies, procedures, and standards expected within the organization. The same system will be used across all projects in the organization and is enforced by the quality assurance role. This role is always filled by somebody outside of the current project, and they should review each project to ensure that it is being operated within the framework developed by the quality management system in order to pass any possible quality audits.

The quality assurance role may seem similar to the project assurance role that was covered in the organizational theme, but these are two distinctly different roles. While the project assurance role sought to determine if the project was being handled appropriately, the quality assurance role is only concerned with whether a project is complying with the corporate standards, policies, and procedures. This form of assurance is used as part of the larger system of checks and balances throughout the project management methodology.


55

It is also important to note that quality assurance is not the same thing as quality control. Whereas quality assurance focuses on how the work is performed, quality control is focused on determining if the result or the end product is fit for purpose. Returning to our car building example, quality assurance determines if the procedures used to build the car are of an acceptably high quality. Conversely, quality control is focused on determining if the car itself is of high quality and that the functions, such as the air conditioning, the stereo, and the drive train are all working properly. Quality control is responsible for maintaining the quality and assurance records for the product in order to gain the customer acceptance at the end of the project. The quality record document the details of any quality tests performed on the product during the project. The project manager builds a number of tests into their quality plan to determine if the product is fit for purpose. Based on the results of these tests, the product is either approved or not approved. If approved, an approval record is created inside the quality record.

The approval record can be a formal or informal document which states that a product has met the required level of quality. This approval record might be a printed document with formal signatures required, or it could simply be an email from one level of management to another that states, “We accept the product, take ownership of it, and agree that it passes the quality test.” Smaller projects tend to use informal documents, while larger projects generally rely on a more formal method. But, of course, this all depends on how your organization wishes to employ quality records in your quality management system.

Baseline Once a product is approved, it becomes the official baseline and

may be designated with a version number (for example, v1.0). Once this initial version is created, all additions or modifications to the baseline are considered a change and they must go through the change management process, change control, and versioning. A user can submit a request for change (RFC) in order to apply funding to support any alterations to the baseline.

In both the software development world, as well as in the world of physical products, creating baselines and utilizing RFCs is a common practice. Returning to our earlier car building example, let’s assume we


56

have a production ready vehicle that has gone to market and we designated it as version 1.0. Later, it is determined that there is a fault with the airbag, therefore an official RFC is submitted and a newer version (v1.1) is now produced and shipped to the dealerships. Once the RFC was approved, the new baseline became version 1.1, and the older version 1.0 is no longer part of our authorized baseline.

Failure to Meet Acceptance Criteria

Inevitably, you will one day work on a project where your team is

unable to meet the agreed upon acceptance criteria. In this case, the supplier is contractually obligated to continue to build the product until they meet the required level of quality. The product will not be accepted by the project board until it meets the level of quality initially agreed upon in the acceptance criteria.

What happens when your product continually fails to meet the quality control standards and you simply cannot meet the acceptance criteria that was defined during planning? What happens if the level of quality required is simply too high to achieve? Imagine that you are working on a project that is responsible for building the next smartphone. One of the acceptance criteria is that the device must be able to be dropped from two feet above the floor without the screen cracking on impact. Months of development have gone into the design of the device, and finally the team receives ten prototypes of the new device in order to conduct the quality tests. The tests begin and every time the device is dropped from two feet, the screen cracks. The engineers go back to the drawing board and determine that the current glass technology being used simply cannot withstand the impact from two feet. The project will need to develop a new technology that simply doesn’t exist yet in order for this device to remain unbreakable under the stress of the two foot drop.

The project manager now has to go back to the project board and break the news to them. The team simply cannot meet the requirements: the requirements must be changed (lessened) or we need to cancel the project. In this case, the project board and program or corporate management must decide to either change the requirements to a smaller drop height, to allocate more funds to develop the new unbreakable glass technology, or to terminate the project due to the inability to meet the current quality requirements. Those are the three


57

options: make the requirement less specific, add additional money and resources to development, or stop the project completely.

Remember, everything that has occurred so far must be documented. When the product passes an acceptance test, it should be documented in an acceptance record. When the product is accepted by the stakeholders, it should receive a formal acceptance. If the product’s acceptance criteria are changed, that should also be documented. This documentation is critical to ensuring that the desired level of quality is achieved in a project, and that the final product is accepted by the senior user at the end of the project.


PRINCE2® contains a few minimum requirements that must be

met in regard to the quality theme. First, the quality management approach must be clearly defined and documented. This ensures that both quality control and project assurance are properly conducted and documented. Second, the quality records and a quality register must be created in order to document quality throughout the project according to the customer’s quality expectations and acceptance criteria. Third, the acceptance criteria for the project must be clearly defined and agreed upon by the relevant stakeholders. Finally, the project manager should review previous projects and their lessons learned in order to incorporate those findings into their own quality planning for the current project.

Theme: Plans

The plans theme helps facilitate communication and control by defining the means of delivering products. Plans are developed so that work can be conducted to achieve a final outcome. These plans define the how, when, how much, by whom, and where of the project in order to ensure that the final products and outcomes are achieved successfully.

There are three levels of plans: the project plan, the stage plan, and the team plan. The project plan is used by the project board to describe the project level costs, timescale, and control points. This plan outlines the number of stages that the project contains, when those stages should occur, and the plan is updated at the end of each stage to reflect the actual progress achieved by the project to date. During the end of


58

stage assessments, the forecast and budget for the project plan can be adjusted or modified, as appropriate. The project plan is the broadest of the three types of plans.

Nestled underneath the project plan is the stage plan. A unique stage plan should be created for each stage of the project, as defined in the project plan. The stage plan is used by the project manager for the day-to-day management of the project. It also contains the project manager’s budget and tolerance for the current stage.

The team plan is created underneath the stage plan. The team plan is also known as a work package in some organizations and is used by the team managers to manage their day-to-day tasks. The team plan details the work that is required to be done by the team and more than one team plan can exist simultaneously.

For example, if you are working on a project to build a custom home during the construction stage, there might be a team plan for the work to be conducted by the plumber, another team plan for the electrician’s tasks, and a third team plan for the team responsible for installing the floors. These work packages are all a part of the same stage plan, but each team plan focuses on an individual team’s tasks instead of the entire stage.

Exception Plan

An exception plan is utilized when a deviation from the project plan, stage plan, or team plan is required. Exception plans are generally used as a result of something going wrong in the project, such as a budget overrun, an adverse risk being realized, or some other negative event. An exception plan is created as a new plan to replace the current project plan, stage plan, or team plan. The existing plan is not updated, but instead it is replaced when the exception plan is approved by the next higher level of management.

If a team plan requires an exception plan to be created, then the project manager would approve it. If a stage plan requires an exception plan to be created, then the project board would approve it. If the project plan requires an exception plan to be created, then the program or corporate management would approve it.


59

Budget Planning

When planning the budget, there are many factors to consider. Of course, there is the cost to develop and produce the actual product that the project is trying to create. Additionally, the cost of management and overhead should also be factored into the budget. While management and overhead may seem like an extraneous line item in the budget, there are real costs associated with overseeing the project successfully. The project manager, the executive, the senior user, and the senior supplier all have salaries that must be paid. There is also office space, electricity, and water bills that must be covered. All of these expenses are items that must be accounted for in the budget in addition to the costs of product development.

A change budget should also be provided as part of the overall budget because no project will ever run perfectly, and changes will need to occur. A change budget allows for the funding of authorized changes to the product’s baseline. If a request for change is submitted under the change management process and the change authority approves the change, then the change budget can be used to pay for the approved change. Risk is also inherent in every project and there will be activities that must be taken to respond appropriately to these risks. A risk budget is a dedicated amount of money that is controlled by the project manager in order to fund actions necessary to respond to the realization of an unexpected risk.

For example, in my neighborhood a new house was being constructed. During the excavation phase, the builder had a contractor dig out the basement for the new home. The builder scheduled the concrete basement to be poured a few days later, but unfortunately a large rain storm came through the area. The excavated hole that was soon to be a poured basement had become a small pond due to all the rain. The builder had to rent several water pumps to drain the hole before the basement foundation could be poured. This additional cost of renting the water pumps had to be paid for somehow, and this is exactly what the risk budget is designed to cover.

Unfortunately, budgeting isn’t an exact science. While the budget may seem perfect on paper, there are always cost overruns, such as the water filled basement example above. To compensate and plan for these variances, cost tolerances are used. This allows the project


60

manager to have an approved budget from the project board with some room for variation to occur.

For example, if the planned cost to pour the basement was $10,000 with a 10% cost tolerance, then the water pump rental could be covered by the cost tolerance if the cost was under $1,000. But, if the cost of the rental was $1,200, then the extra $200 would come from the risk budget as this was an unforeseen and unplanned expense during the execution and delivery of this stage of the project. If the cost remains within tolerance, the project manager does not have to consult the project board, nor submit an exception report for the issue.

Project Product Description

A project product description defines exactly what the product

must deliver. Whether it is a house, a car, a website, a network, or any other product, an incredibly detailed description of the end product should be written and agreed upon during the project initiation stage. For example, if your project was to build a car, you should be given a project product description that details the kind of car. If you are told to plan to build a red car, that isn’t enough detail to create a well thought out plan. Instead, you should be given additional details, such as that car will be a red four-door sedan that can go from zero to sixty miles per hours in under 4.6 seconds.

Using the details project product description, the project manager will then create a product breakdown structure. This document will provide a list of all of the sub-products that are required to be completed in order to have the finished outcome of the project. Returning to our car example, the product breakdown structure lists all the parts that must be manufactured in order to create the car, such as the airbags, seats, upholstery, gauges, wiring, engine, braking system, and every other part that makes the car work. Then, a product description will be written for each and every major product that is used to create the final product. Again, considering our example of a car, one of our product descriptions would be for the airbags and it would detail the size, shape, deployment mechanism, the amount of pressure to be exerted against the passenger, and other critical details.


61

Planning the Timeline The most common depiction of the timeline of a project plan or

the stage plan uses a product flow diagram called a Gantt chart. This diagram shows the product breakdown structure in a graphical format. This graph details the sequence in which the work must be performed in order to create maximum efficiency. For each product listed in the Gannt chart, the resources allocated to the line item is provided and the estimated time to complete the line item is detailed.

Using the example of building a custom home, the foundation of a house must be poured prior to the walls being built. The walls must be built before the electrical and plumbing can be installed, but these could both be installed simultaneously. Next, the drywall must be installed, it then must have time for the mud to dry on the drywall, and then painters can begin their work.

It is the responsibility of the project manager to appropriately sequence all of these jobs and tasks in order to get the most work done in the least amount of time. This period of the least amount of time is termed the critical path. The product flow diagram visually displays all this work and allows the project manager to determine what tasks must happen before other tasks. With a draft of the Gannt chart created, the project manager can begin bundling products and work together in order to plan for each stage in the project. The project board should have already determined how many stages the project will require and roughly how much time is being allocated to each stage.

According to PRINCE2®, there must be a minimum of two stages. Smaller projects may only have the initiation stage and a delivery stage. Larger projects, though, will have the initiation stage and multiple delivery stages. In fact, I previously worked on a very large project that had fifteen separate delivery stages over an eighteen-month period. When deciding how many stages the project will include, the project board will consider their comfort level with the project manager, the size and scope of the project, and the amount of risk involved in the project. Each stage that is added provides the project board an additional opportunity to determines whether the project still has a continued business justification and should be continued or terminated.


62

Planning Horizon

When designing a plan, it is important to consider the planning horizon, or how far out the project manager can realistically plan. If the project manager has a longer planning horizon, then the board may allow for less stages in the project. But, if the project is particularly risky, then there will likely be more stages required by the project board.

If you wanted to build a house and you chose a contractor who has built hundreds of houses before, then their experience all but guarantees that the project is low risk. Therefore, the project board might be more comfortable with using less stages. If, on the other hand, you hired a brand-new contractor who has never build a house before, then you might want more stages in order to have decision points built-in more often.


There are a couple of minimum requirements for the plans theme according to PRINCE2®. The project plan, the stage plans, and the team plans must all be created to enables the realization of the overarching business plan. The concept is to go from an idea to a product, and to do that proper plans are needed. PRINCE2® requires that a project plan and at least two stage plans are created at a minimum. While team plans or work packages are not required, they are highly encouraged and recommended. Exception plans are required to be produced when a plan is forecast to exceed tolerances or deviate from its planned and approved course of action. These exception plans are used to get the stage back on track or to cancel the project entirely. Finally, the project product description, product descriptions and product breakdown structures must be created in order to provide the project with the timing and tempo of the different stages.

Theme: Risk

The risk theme seeks to identify, assess, and control uncertainty in order to improve the project’s likelihood of success. Everything entails risk, but by considering the uncertain events that may affect the project’s objectives and its products, the project manager can work to


63

minimize negative outcomes and the chance that the project will have to be canceled due to unforeseen circumstances. There are two major components to risk: the event and the effect. The first component, the event, may or may not occur, and therefore we cannot even know if it will become an issue that a project manager will have to address. The second component, the effect, has a causal relationship to the event and is what occurs if the risk is realized. When considering a particular risk, people tend to immediately think of the negative effects such as being injured during a car accident. But there is the potential for positive effects from risk, as well. For example, there is a risk that I could be walking down the street tomorrow and find a $100 bill laying on the ground. This risk would have a positive effect. In terms of a project, your supplier might deliver a product earlier than expected causing a positive effect. When dealing with risk in the PRINCE2® methodology, remember that a risk can have either a positive or negative effect. There is also a difference between a risk and a project issue. A project issue is an actuality that must be dealt with during the project, whereas a risk is just the uncertainty that might lead to a project issue. The main distinction is that risks have not yet occurred or been actualized. For example, if the project manager hired someone to lay the tile in a new bathroom and after two days of their working on the project it is discovered that the wrong tile was installed, this is a project issue. The risk was that the wrong tile might be installed by the contractor, but once that installation occurred this now became a project issue and something that must be dealt with by the project manager. Now the project manager must spend some of their risk budget in order to get the wrong tiles removed and the correct tiles installed. Positive risks must be properly addressed as well. If a positive risk is realized and the project was unprepared, it could cause a negative outcome to occur. For example, if a project was developing a new e-commerce website and expected 10,000 people a day to visit the site, there is always a positive risk that 1,000,000 people may visit the site on the first day. If this positive risk is realized, but the project manager didn’t plan for this excessive load on the website then a self-imposed denial of service or a server crash could occur. This would then turn the positive risk into a negative effect. If the project accounted for this positive risk and decided to build the site on an elastic cloud


64

infrastructure, the positive risk could have been realized and all the visitors could have received the proper level of service. The risks involved in a project, both positive and negative, must be weighed and considered in order to minimize any negative effects and maximize the possible benefits for the project. This is done by mapping out the possible threats and opportunities. Threats are the causes that create a negative impact, while opportunities are the causes that create a positive impact. When the project adequately addresses risks, it is ready to manage threats and take advantages of opportunities.

Risk Budget The risk budget is an amount of money that is budgeted to fund any necessary risk responses that might be required during a project. Returning to the example of the incorrect tile being installed in the bathroom, the project manager may need to purchase new materials and additional workers to correct the project issue. The cost for these actions would be funded through the risk budget, since the realization of a risk has occurred.

Risk Appetite An organization’s risk appetite is defined by how much risk the organization is willing to accept. Some organizations are risk adverse and have a very low risk appetite. Project managers who work for one of these organizations will go to great lengths to ensure that there is little or no risk in the project. Conversely, other organizations may have a high-risk appetite and are willing to accept more risk in a project in order to save money on redundancies that may be created in a lower risk environment, or to speed up the delivery of a project. Like most things in PRINCE2®, there is no definitive answer to how much risk should be accepted by the organization or at what level an organization’s risk appetite should be set. Risk tolerance is the risk threshold that must not be exceeded without submitting an exception report to the next higher level of management. When the project board creates and defines the risk tolerance for the project manager, it allows the principle of manage by exception to be effectively utilized in the project.


65

Dealing with Risk To mitigate risk down to an acceptable level, the project manager must plan for uncertainty that could be realized. As each risk in the project is identified and assessed, the project manager will determine the best course of action to take in regard to the risk. Risks can be accepted, mitigated, transferred, or avoided. Again, depending on the risk appetite of the organization, it will help the project manager to determine what action and controls to put into place through the risk management approach. The risk management approach is a document that details how risk will be managed in a project and is created during the project initiation stage. This document defines the risk tolerance levels, the risk budget, and the methods that should be used to deal with risk as it is identified. A risk register is established and lists every risk that arises through the project’s lifecycle. The project manager uses the risk register to appropriately capture all the potential risks, notate the controls that were chosen to minimize each risk down to an acceptable level based on the organization’s risk appetite, and record what response was taken if a particular risk was realized. A five-step procedure is utilized to deal with risks during a project: identify, assess, plan, implement, and communicate.

First, the risk is identified by listing the threats and opportunities. This should include the potential sources of the risk such as the event or area of the uncertainty that may happen and the effect or impact. During this step, everything that could possibly go right or wrong is identified and documented.

Second, each of the risks listed in the identification step is assessed. The project manager will estimate the probability or likelihood of a risk being realized, its potential impact, and the proximity, that is when it is likely to occur. Then, each risk is evaluated for its net overall effect. For example, if you are building a house, there are a lot of negative and positive things that could occur during the project. Each risk is considered, such as the risk that a contractor might install the wrong light fixtures or that the electrician might install faulty wiring in the home and cause a fire. As each risk is considered its likelihood is determined. It may be assessed that it is more likely that


66

the contractor will install the wrong fixture than for the house to burn down due to faulty wiring.

The third step is to conduct planning. As each risk is considered, the project manager can determine the best course of action to mitigate, transfer, or accept them. For example, the project manager might consider purchasing fire insurance in order to transfer this risk to a third-party. As plans are created for each risk, this creates contingency plans and ensures that the project manager is ready to respond to a risk if it were to be realized.

The fourth step is implementation of the plans. If the project manager determined that is was highly likely that a contractor might install the incorrect light fixtures, they may institute a system of a quality control check prior to the fixtures being installed. This system would require a risk owner and a risk actionee. A risk owner is responsible for managing the quality control check program, while the risk actionee will be the person who actually conducts the quality check. This ensures that for each risk, we will have a mitigation and a person responsible for that mitigation.

The fifth and final step is to communicate. Risk should be measured throughout the project and its status reported to management and stakeholders using the highlight reports and exception reports. If a particular risk is realized, then the project manager will need to communicate what happened, how it was dealt with, and the impact to the project. If the risk was within the risk tolerances set, then it would be communicated using the highlight report. If it was outside the risk tolerances set, then the exception report should be utilized instead.

Risk Responses

There are two types of risk responses: responses to threats and

responses to opportunities. Threats, or negative risks, can be avoided, reduced, accepted, transferred, shared, and have contingency plans created for them. Opportunities, or positive risks, can be exploited, enhanced, rejected, transferred, shared, and have contingency plans created for them. Notice, that the last three options are the same for both threats and opportunities.

This makes it easier on test day, because you will just need to remember the first three risk responses for threats and opportunities


67

since they are different. Consider this question that you might see on exam day, “Which of the following is not an appropriate risk response to threats?” If the options presented are avoid, reduce, accept, transfer, share, and reject, then knowing that reject is only used for opportunities, you can easily answer this question.

Risk responses are used to address the primary risk. But, even after the primary risk is addressed, there may be some residual risk that still must be address with some kind of action. For example, a project might involve installing hundreds of new workstations on a computer network. The project manager might decide to reduce the threat of a cyber-attack by having a vulnerability management project created in the organization to catch all known vulnerabilities. While this mitigates the risk of a cyber-attack, it will not completely eliminate the risk because vulnerability management cannot stop a newly created piece of malware from causing damage. To deal with the residual risk of attack, the project manager may choose to simply accept the risk, or they may choose to transfer the risk by purchasing cyber insurance. Because our risk can never be reduced to zero, there will always be some residual risk to consider and a risk response chosen.


There are a few minimum requirements that must be met in PRINCE2® to satisfy the risk theme. First, the risk management approach must be defined and created during the initiation stage of the project. This describes the risk management procedures that will be utilized during the project, and identifies the risk budget, the risk appetite, and the risk tolerance. The project manager must also create a risk register to record and mange each risk that may occur in the project. Each risk should then be identified, assessed, managed, and reviewed throughout the project because risks change over time.

Roles and responsibilities must also be defined to address risk management. Additionally, any lessons learned from previous projects should be reviewed prior to initiating the project, as they are an excellent place to find risks that must be considered and addressed for a successful project.

By documenting the risk management approach, implementing the risk management procedures, and carefully considering the risks and the risk responses to them, the project manager is well positioned to


68

manage risks as they occur and minimize the negative effects of threats as they are realized.

Theme: Change

The change theme seeks to identify, assess, and control any potential or approved changes to the project baseline. A baseline is an official version of a product that cannot be further modified, altered, or changed without going through he official change management process. It is a product that has been approved by those in authority and has been deemed fit for purpose. Essentially, it is a finished product that is ready for the next iteration. The change theme must be considered anytime the baseline is changed and the change management procedures must be utilized.

Uncertainties may arise during a project in the form of risks, and these risks may be realized to create a project issue. Because these issues were not properly planned for, they require management action to overcome and keep the project moving forward. This is often done by creating a request for change to modify the baseline of a product in the project. If the original specifications or designs for the baselined product aren’t sufficient, then a new version or an off-specification will need to be created through an RFC and approved by the change authority. An off-specification request is a type of change request for a product to provide some functionality that is not currently provided nor forecasted to be provided by the project. The third type of change is a problem or concern, which usually manifest themselves as project issues.

If a project issue exceeds a tolerance, an exception report is created, and the project board is notified. This project issue is then resolved through either a formal process or an informal process.

A formal process requires formal advice from the project board. First, the project manager logs the project issue in the issue register. Then, they create an exception report that contains the issue in an issue report and submit it to the project board. At this point, the project board will then decide whether to make a change or to create an off-specification. The informal process is an easier way of handling a project issue. The project issue is recorded within the project manager’s daily log. If the project manager has enough funds in their budget or if there is


69

enough of a tolerance, then it can be corrected without having to report to the issue to the project board.

Change Control Approach The change control approach is dependent on your organizational procedures and how the approach is defined within the project. Each project must document how changes will be requested, approved, and actioned. The PRINCE2® methodology does not dictate how this change control process must be performed, but merely requires us to have a well-documented change control approach. If your project is audited, this is one of the documents that will be requested by your auditors to ensure that you are implementing the PRINCE2® methodologies correctly. Just like risk management, the change control procedures consist of five steps: capture, examine, propose, decide, and implement. First, the change must be captured by recording the issue either in the project manager’s daily log if using the informal process, or by recording the issue in the issue register if enacting the formal process. Second, the change is examined to determine the impact on the project’s objectives of cost, time, quality, scope, benefits, and risk. Each of these objectives must be considered any time a change is sought because it could affect the objectives and tolerances set forth by the project. A change may require more time or provide less quality, for example. A proper impact analysis will determine how the proposed change will affect these variables in order to determine if project success is still obtainable. Third, the change is proposed and alternative options for responding to the project issue are determined. There is always more than one way to solve any given issue or problem, so determining your alternatives is crucial. For example, there might be an issue with installing a new computer network if the routers and switches aren’t expected to arrive from the supplier on the date they were promised. There are many ways this problem could be solved. One way could be to spend extra money from the budget to expedite the shipping of the devices. Another option might be to choose to buy from a different vendor. A third option might be to let the project schedule slip by a week and deliver the project a week later than originally scheduled.


70

During this step, we propose the various options to management to determine which course of action to choose. The fourth step is to decide on one of the proposals. The best option is determined based on the best value for investment. It is important to note that the best value does not always mean the cheapest option, though. Often, a project will accept a higher price for a higher quality or for a shorter delivery timeline. It really depends on the goals and objectives set forth by the project. The fifth and final step is to implement the recommended course of action to solve the issue. This is where the work to overcome the project issue is performed and the issue can be considered fully resolved.

How Are Changes Approved? Changes are approved by the change authority role. This person is responsible for reviewing any proposed changes, the impacts of that change, and then either approves or denies the request for change or off-specification request. This role may be fulfilled by the project board, but in larger projects the role is usually delegated to another person.

The change authority is allocated a change budget. Much like the risk budget was used to deal with risk mitigation and risk actions, the change budget is used to fund any approved changes to the baseline. The project manager must be careful when dealing with the change budget and risk budget, because people will often try to use the wrong one at the wrong time. Often, someone will try to use the change budget to pay for a risk response or risk action. Or, they might try to use the risk budget to pay for an approved change to the product baseline. It is important that the project manager is honest about which money is being spent on which one. Otherwise, the wrong budget will be charged and it can make proper forecasting for future projects more difficult.

Configuration Management

Configuration management is used to identify the different versions of products created during a project. In software development projects, this is usually denoted as v1.0, v1.1, v.2.0, etc. However, even


71

if the project is building a physical product, like a car or a house, it is important to create a good configuration management system and version control your product. Once the approved baseline is created, this baseline is known as the “as-built” configuration, and everything afterwards becomes a change that must go through the change control process and be tracked in the configuration management. For example, if an office building is being built based upon the approved blueprints (v1.0), but the owner now decides they want an interior wall to be removed from the design. This change should be required to go through the change control process as a request for change and is then recorded in the configuration management as v1.1 of the blueprints once approved. Configuration management consists of two documents: the configuration item record and the product status account. The configuration item record is a document that records the status and version of a given product. The configuration item record can exist as an electronic record in a database or as a paper item in a card catalog. The product status account is a report that contains the status of one or more products.

For instance, when a project creates a large piece of software, there might be dozens of different functions being programmed as different products. For each of these functions, we need to know if they have been approved or are still being coded. The product status account maintains the current status for each of these functions (products) in order for the project manager to determine the current status of the overall project, the software in this example.


There are four requirements that must be met for the change theme. First, the change control approach must define and describe the change control procedures that will be used in the project. Remember, PRINCE2® does not dictate how the change control must be performed, just that the project has a defined procedure that will be utilized. Second, an issue register must be maintained for any formal changes and a daily log for any informal changes. This ensures that project issues are recorded and managed as they occur within the project. Third, the roles and responsibilities for change management must be defined, including the designation of someone to the change


72

authority role. Finally, it is important that the project manager review the lessons learned from previous projects to determine what worked well and what didn’t in their change processes. This will allow them to apply corrections to those change procedures during the project initiation stage and prevent issues throughout the project.

Theme: Progress

The progress theme is concerned with establishing mechanisms for monitoring and comparing the actual versus planned achievements within a project. By accurately measuring progress, the project manager is able to provide a forecast for the project’s objectives and its continued viability. Progress also ensures that the project manager can control any unacceptable deviations for the planned activities within the project. Controls are put into place to monitor and compare the realities of the project’s accomplishment with the original expectations. This reality is then forecasted forward into the future in order to determine if the project is still on track for a successful completion by using effective progress controls. Progress controls rely on the delegation of authority from one level of management downward to the next. This allows managers to handle issues at the lowest possible level and enforces the principle of management by exception. The project is divided into stages and each stage is authorized one at a time. This allows the project board to provide a Go/No-Go decision prior to moving from one stage to the next in the project.

Another progress control is time-driven or event-driven reports. Time-driven controls are useful for monitoring and reporting on time-driven issues. They occur at a regular, agreed-upon frequencies, such as a highlight report being submitted to the project board by the project manager every two weeks. An event-driven controls happen when a specific event occurs. For example, during the construction of a house, an event-driven report might be submitted once the foundation has been poured or the drywall has been hung.

These reports allow management to review the current progress against the planned progress and make more accurate Go/No-Go decisions. The project initiation document (PID) documents each of


73

the progress controls that will be established and utilized within the project.

Documenting Progress Controls

In order to implement progress controls, a few different

documents are utilized. A lessons log is used to capture and review the lessons learned during a project by the project manager. From this lessons log, a lessons report is created that contains a collection of lessons to be used to aid in the development of forecasts in the future. For example, if a certain vendor is always late to deliver supplies, this could be captured in the lessons log and the lesson report so that other project managers will not rely on this vendor for future projects.

An end stage report is a document written at the end of each stage that enables the project board to make their Go/No-Go decision. The project board uses this document to assess whether the project is still viable by determining if it still has a valid business case based upon the project that has been achieved versus the progress that was forecasted to be completed.

The end project report is created after the entire project is completed. This report serves to close out the project and allows the project team to evaluate the project as a whole, whether the project can now be closed, and if there are any outstanding items remaining to be completed for this project. While these controls are mostly used by the project board to oversee the progress made by the project manager, the project manager has some controls that they can also utilize. The project plan, stage plan, exception plan, and work plan are all commonly used to create baselines and to measure progress. The project manager can also review progress by consulting the issue register, the risk register, the quality register, the product status account, and the daily log. All of these documents help the project manager to better understand the current status and progress of the project. Using all of this information, they create checkpoint reports, highlight reports, end stage reports, and the end of project report. Using a combination of these various progress controls allows the project manager to keep their thumb on the pulse of the project as it moves forward towards a successful completion.


74

Tolerances

One of the most important progress controls is the setting of tolerances. Tolerances are the permissible deviation from a plan before an issue must be brought up to the next higher level of management. If a team manager is responsible for a work package with a 2% tolerance given by the project manager, they only have to report an issue upward to the project manager if the tolerance is exceeded. For example, if a problem arises that will cause the schedule to vary by 3%, then the team manager must notify the project manager.

The project manager receives their tolerances for the stage from the project board. Assuming the project manager was given a tolerance of 5%, the project manager does not need to inform the project board of the issue with this particular work package since it is only a 3% variance in the schedule. But the project manager is managing the entire stage, not just this one work package, and so if another work package exceeds its tolerance, then this may drive the project manager to exceed their 5% tolerance for the overall schedule. In that case, the project board would have to be notified through an exception report.

Even the project board has their own set of tolerances. If those tolerances are forecast to be exceeded, then the project board submits an exception report to their higher-level management, which is the corporate or program management. Therefore, the lowest, tightest controls should be at the work package level, the mid-grade controls should be on the stage tolerances, and the widest should be at the project level.

Minimum Requirements The progress theme has a few minimum requirements that must be met. First, the project’s approach to progress control must be defined in the project initiation document in order for there to be a standard by which to measure progress in the project. Next, the project must utilize the manage by stages and manage by exception principles through the use of well-defined tolerances. The business case should be reviewed whenever an exception is raised to the project board to ensure that the project still remains viable. Finally, the project manager must review the lessons learned from previous projects, implement those lessons inside their own project, capture any lessons learned


75

while executing their project in the lesson log, and create the lessons report to share those lessons with the project board and other project managers.


76


77

CHAPTER FIVE The Seven Processes

OBJECTIVES

• Be able to list the processes in PRINCE2® • Understand each of the seven processes in PRINCE2® • Be able to apply the seven processes to a given scenario

Thus far in the book, we have covered both the principles and

themes of PRINCE2®, but in this chapter we will dive into the seven processes. It is through these seven processes that the principles and themes are applied, allowing our project to proceed from an idea to a final product with realized outcomes. Each process is controlled, overseen, and executed by different roles throughout the project management team. The executive, the senior user, the senior supplier, the change authority, and the project manager are each responsible for certain decisions throughout the process and throughout different periods of time during the project lifecycle.

The seven processes are: • Starting up a project • Directing a project • Initiating a project • Managing a stage boundary • Controlling a stage


78

• Managing project delivery • Closing a project

Unlike the principles and themes, the processes are performed

sequentially throughout the lifecycle of the project. This is referred to as the process timeline and it forms the skeleton or backbone of the project. Every project has a pre-project portion, an initiation stage, the optional subsequent stages, the final stage, and the post-project portion. As a project moves through these phases, it utilizes the seven processes to control the project and the creation of its desired outcomes.

Process: Starting Up A Project

A project must answer one simple question prior to be started: “Do we have a viable and worthwhile project?” After all, it is cheaper to determine the answer to this question during the pre-project phase that during project execution. So, it is important to take the time to determine if the organization should even dedicate the time, money, man-hours, and other resources to performing a project before the project is begun.


79

At the onset of the project, when the idea is first formed, the organization should dedicate some minimal resources to properly analyze the objectives and determine if the project is indeed worthwhile. This occurs during the initiation stage. During this stage, a small team or people, possibly even just one person, will work to provide some additional details to the project, such as how it might be conducted, a very rough determination of the size, scope, and cost of the project, and if the project is achievable by the organization. During this initiation stage, the organization seeks to put in the minimal number of hours and labor necessary to make these determinations, because the project’s occurrence is not a forgone conclusion at this point. Once the program or corporate management believes that they have enough details to make an appropriate decision to invest additional resources into this project idea, they need to appoint the significant project board roles, such as the executive. Now, it becomes this executive’s responsibility to show whether the project has a worthwhile business case and whether it should move forward in development outside of the initiation stage.

Once the program or corporate management board has made the decision to initiate the project based on the business case that the executive created, the real work begins. The executive must now create an initiation stage plan as the project attempts to work through the Starting up a Project phase because, at that point, the organization has approved the project and decided to move it forward from an idea into an actual project. At this point, the project’s scope, duration, and timeline are defined. Additionally, the project’s acceptance criteria and constraints are agreed upon and documented. As the plan begins to take form, the limitations of the project are further detailed, such as how much money the organization is willing to spend and how long it will take to deliver the product is considered acceptable for the project to remain viable, achievable, and desirable. This entire process begins with a project mandate. This often occurs because some senior execute has a “great idea”. I’ve been in the board room numerous times when a senior executive utters those famous words, “Wouldn’t it be great if…”

This is the first sign of a project mandate, and usually hundreds of hours of labor will be needed to determine if the great idea actually


80

makes a good business case. In order for the idea to become a project, though, we have to find out if the project is going to be viable, achievable, and desirable.

The goal is simple during the pre-project phase and the starting up a project process: find one idea out of the hundreds that an organization brainstorms that is worth pursuing. People offer many different kinds of ideas as part of the brainstorming process, but because organizational resources are limited not every idea can be turned into a project. Instead, the organization has to determine which ideas should be implemented as a full project. When that determination is made, the project mandate is drafted.

The project mandate can come from the customer’s organization, their corporate offices, their program management office, or directly from the customer themselves. This project mandate provides the reason for undertaking the project.

In my business, we have to prioritize the numerous ideas for projects that we have all the time to determine which ones to pursue. We have customers, our students, who ask if we will create a course on a certain topic. For example, you may finish reading this book, take the PRINCE2® Foundation exam, and write to me to ask if I will make a PRINCE2® Practitioner level book or course. The answer is…maybe. The truth is that it is one of a hundred different ideas for projects that I am considering for the future. For each one, I have to invest some resources to determine if it is a good fit for our organizational goals. I have to ask if we have the capability to produce the end product (outcome), and if so, when is the best timing for us to do that project. There are a few minimum requirements that must be met inside the Starting up a Project process. First, the key roles and responsibilities must be identified so that the project can move forward. This includes the identification of the key project board members (executive, senior user, senior supplier) and the project manager. These roles are necessary so that someone is identified as the responsible role for writing the business case and the project plan. The executive is usually, but not always, responsible for writing the business case because they are ultimately in charge of the project’s funding. While the executive is responsible for creating an outline of the business case, they do have the option to turn it over to somebody else to fully write out the document with all the details.


81

The Starting up a Project process has two distinct outputs. The first output is the project brief that ensures that the project is agreed upon and has a well-defined starting point in order to ensure that everyone understands what to expect as the outcome or end product. The project brief is presented to the key stakeholders to gain their concurrence with the project.

The second output is the creation of the initiation stage plan. At this point in the project, the entire project hasn’t been planned out yet. Instead, we have just been granted the permission to move forward and further develop the idea into a full project. The majority of that work will occur in the initiation stage, but before the project board can enter the initiation stage it must have a plan for how that stage will be executed. This plan will detail all the work to be done during the initiation stage, and this plan will be approved by the corporate or program management board.

Finally, the project manager reviews the lesson learned from similar projects that have occurred in the past, so that they can use these lessons to create better controls inside the initiation stage.

Process: Directing A Project

While you may expect that the next process would be Initiating a Project, it is important to first considered how a project is directed because this is where a decision to proceed and move forward is made. Directing a Project occurs throughout multiple phases of a project and gives accountability for the success of a project to the project board by making key decisions and exercising overall control. The day-to-day management of the project is delegated down to the project manager, but the direction of the overall project remains with the project board. In PRINCE2®, it is important to implement the principle of manage by exception, which requires that authority to make minor decisions is pushed down to the lower levels of management by providing well-defined tolerances. This allows the senior management and executives to have their time freed up from the minor decisions, and only requires them to get involved in the decisions at critical points during the project or when the project begins to veer outside the tolerances set. For this reason, the directing a project process spans across the initiation stage, subsequent stages, and the final stage. The


82

directing a project acts as a bridge across the timeline of the project lifecycle. During the directing a project process, authority is provided to initiate the project, to deliver the products of the project, and to close the project. The directing a project process is utilized whenever the project is going to move from one stage to another. Management direction and control is provided throughout the lifecycle of the project to ensure that the project remains viable by retaining the Go/No-Go decision at the upper management levels.

The directing a project process also provides the corporate/program management or the customer with an interface to the project through the project board. This ensures that these critical stakeholders have the opportunity to manage and review the post-project benefits and make sure that the final products of the project have met the agreed upon standards. But what triggers the directing a project process? In the starting up a project process, the trigger was the receipt of a project mandate. Once the mandate and the request to initiate documents are received, the directing the project process is initiated because the key roles on the project board are identified. This project board now has the responsibility for ensuring the existence of a business justification throughout every stage of the project. They will also utilize the principles of manage by exception to direct project, allowing the project manager to do their job on a day-to-day basis and deal with any minor issues that may arise. However, anytime an exception report comes up to the project board, this requires interaction through the directing a project process in order to receive a decision from the project board. The directing a project process has five key actions or decisions that occur during the lifecycle of the project. The first key decision that is made by the project board authorizes the initiation of the project and ensures that the investment in the project is considered worthwhile.

The need to authorize the project itself through granting the approval of the project initiation document is the second key decision or action. This acts as the confirmation from the project board that they believe the project has a firm foundation and a solid business case.

The third key action or decision is the authorization of the stage and exception plans throughout the project. The project board is


83

responsible for creation and approval of the overall project plan, but the project manager creates the stage and exception plans. These plans must be approved by the project board before they can be executed to ensure that the project remains on track and synchronized with the overall project plan. The directing a project process is not used solely for when things are going wrong in the project, but instead is used continually to review the performance of the current stage and approve the next stage before proceeding forward. Part of reviewing the stage plans also includes the approval of the product descriptions, thereby creating the agreed upon specifications for the end product. The project board also reviews the lessons report submitted by the project manager at each end of stage report, and then determines if they should be shared with another project board or another project manager.

The fourth key action or decision is to provide ad-hoc direction to the project manager. This entails reviewing the highlight reports, issue reports, and exception reports. The project board will also make decisions about the issues, risks, and changes necessary in a project. Based on the information they have available and their experience, they can best advise the project manager on how to proceed before communicating these decisions up and across to the various stakeholders involved in the project.

The fifth and final key action or decision is to authorize the closure of the project. The project board will review and approve the end project report and the lessons report that were created by the project manager. The project board will also compile all of that information available on the project in order to approve moving into the closing a project process. This will be covered in detail later in this chapter.

Process: Initiating A Project

With the project having gone through the starting up a project and directing a project processes, it is ready to move into the initiating a project process. The sound foundations for the project will now be established and the organization will seek to become well-poised to better understand the work that needs to be done to deliver the end product before committing a significant investment of time, money, and resources.


84

During the pre-project phase, someone in the organization had a good idea and it was eventually turned into a project mandate. Then, the project started up to support this project mandate because it was determined that there might be a valid business case associated with the original idea. The project board was established and will be responsible for directing the project throughout its lifecycle. The project board was given the responsibility of creating the project initiation document, as well, which was mentioned previously. A valid project initiation document is created to outline the expected benefits, time, and scope of a project. It is required to be created before the project can start and it must be approved by the project board using the directing a project process. But, in order to create an effective project initiation document, the project management team must understand the objectives of the project. During the initiating a project process, it is important to identify the reasons, time scale, cost, scope, major products, expected benefits and dis-benefits, and any risks associated with the project. The quality requirements and standards that will be employed in the project will need to be identified. The specifications for the baseline product and how change management will be controlled is also documented in the project initiation document. Finally, the communications plan is documented inside the project initiation document to ensure that the communication needs of each of the stakeholders will be properly met by the project management team. Many of the principles and themes from across the PRINCE2®

methodology are brought together during the initiating a project process and are captured as part of the project initiation document. This document contains the project plan with the number and type of stages identified, as well as a detailed business case. The communication management approach in the document also dictates who the team is going to talk to, at what frequency, and using which method. A risk management approach is included in the document to codify the risk theme. The quality management approach is included to document the application of the quality theme. The change theme is codified by documenting the change control approach that the project will utilize. The principle of manage by exception is covered, as well, by including the tolerances that are set for the overall project. Finally, any tailoring of the PRINCE2® methodology is also identified in this project initiation document. At this point, I am sure you can begin to


85

see why the project initiation document is considered one of the most important products inside a PRINCE2® project. While the project initiation document is the most important output of the initiating a project process, it is not the only product. A benefits management approach is also created during this process. The senior user is responsible for the creation of this document and it is used to describe how the benefits of the project will be measured by specifying both the frequency and the roles responsible for taking those measurements. The senior user ensures the benefits management approach is updated at the end of project, as well. This updated version will be passed to the corporate office, the program management office, or the customer as it becomes an active document used in the operational lifecycle of the product. For example, in a previous project that I was responsible for leading, the end result was a large-scale computer network. The senior user had decided upon numerous metrics and measurements that would be used to define success for the project. One of these metrics required that the uptime of the network be measured every week by the service operations team. The benefit had a metric (the amount of uptime) associated with it, a frequency (measured weekly), and a role associated with performing this measurement (the service operations team). As the network was designed, our engineers were careful to ensure that methods to measure uptime were built into the design, since this case considered a key metric that had to be captured.

Because all of these foundational documents are created during the initiating a project process, this process creates a roadmap that can be consulted for the duration of the project.

Process: Managing A Stage Boundary

The managing a stage boundary process enables the project manager to provide the project board with sufficient information for them to review the success of the current management stage. This empowers the project manager to run the stage, but ultimately the Go/No-Go decision comes from the project board. The project board will then approve the next stage plan, review the updated project plan, confirm there is still a valid business case, and accept any outstanding risks in the project.


86

This process occurs both inside the initiation stage and then again during each subsequent stage or stages. In fact, the only stage that does not utilize the managing a stage boundary process is the final stage because it instead uses the close a project process instead. Essentially, the managing a stage boundary process must be completed before the project can move from the current stage and progress into the next stage. There are several objectives that must occur during the managing a stage boundary process. First, the project board must be assured that all the products in the current stage are complete and approved. For example, if a project is developing a piece of software that contains twelve individual products in it, then those products might be scheduled for completion during different stages, such as three in the first stage, five in the second stage, and four in the third stage. At the end of the first stage, the project manager will need to prove to the project board that the first three products have been completed and approved by the senior user. The project manager then creates the next stage plan, review and update the project initiation document if needed, and provide an end of stage report. This is provided to the project board for their verification. The board then will determine if a valid business case exists so that we can get the Go decision to move into the next stage. If the scheduled products for the stage are delivered and accepted, and the project still has a valid business case, then the project board will review the second stage plan and approve its execution. This then allows the project manager to move into the next stage. If, on the other hand, the project board determines that there is no longer a valid business case, then the project should be terminated prematurely to avoid the continued investment of resources in the failed project. The project manager should also be recording any lessons or information during the project execution that might assist the organization during later stages of this project or on some other future project. If the project begins to veer off-track, then the project manager must submit an exception report and draft and exception plan for approval. Even if the project is off track, there may still be a valid business case to complete the project. The level of management approval required for an exception plan will largely depend on the severity of the tolerances breached. An exception plan can replace the project plan or a stage plan in order to get the project back on track


87

and towards a successful completion. Exception plans that replace stage plans are approved by the project board, whereas exception plans that replace project plans are approved by corporate or program management. The project manager must also create an end stage report that provides an assessment of the current progress of the project and compares the progress forecasted to the current reality. The project manager might meet with the project board to conduct this assessment, as well as to update the business case and project plan. In some organizations, this is done as an in-person meeting, while others this is done through the use of reports and other documentation. Again, this end stage report helps the project board to make the Go/No-Go decision to progress onto the next stage, to cancel the project, or create an exception project or stage plan. Finally, the project manager must also complete a lessons report during this process. As the project approaches the end of the stage, the lessons report is used to document any identified lessons that will help prevent issues in the future of this or other projects. These lessons can then be incorporated into the next stage plan or an exception plan. The lessons report should also include recommended changes to the quality management, risk management, or issue management approaches in order to prevent future issues or problems.

For example, if a house was being constructed and it was assumed that there would not be any snow during the project, but a large snowstorm came and created a delay in the timeline, then there is a lesson to be learned here, such as ensuring that some extra time is built into the future project schedules to account for the possibility of inclement weather. This would then improve the accuracy of both future stage plans and our project plan.

Process: Controlling A Stage

The controlling a stage process is the responsibility of the project manager and is considered a managing level process. This process ensures that work is assigned to be performed, that the work progress is monitored, that issues with the work are dealt with, that action is taken to keep the stage within the allocated tolerances, and that the project manager reports progress back to the project board using a


88

highlight report. This is considered business as usual for the project manager and is work he is required to perform on a daily basis. The controlling a stage process has many objectives. First, the process seeks to ensure that the project manager is focused on delivering the product within its given tolerances. All risks and issues should be kept under control and within tolerance, but if that isn’t possible, then an exception report must be submitted. The business case is reviewed to make sure that the product being delivered is what the customer wants. The project manager should seek to ensure that the agreed-upon products are delivered within the cost, effort, and time constraints allotted by the project board. Finally, the project manager must report their progress to the board through the use of highlight reports and, when things go wrong, through exception reports. The controlling a stage process is triggered and begins when the project board approves the project in the initiation stage. Once the project is started, and each time a new stage is approved, the controlling a stage process is restarted. Throughout this process, the project manager focuses on the product delivery for each of the products required for the current stage and any deviations must be detailed in the stage plan and agreed upon by the project board prior to the beginning of the stage. The project manager is responsible for the assignment of work packages to their team members. In a small project, a project manager might deliver the products themselves, but in a large project this is almost never the case. Instead, the project manager retains accountability for the quality of the work, but delegates downward the responsibility for the achievement of that work to their team managers. These team managers, in turn, may even have sub-team managers working underneath them on very large projects. This is a case where utilizing the principle of manage by exception is critical to success and efficiency. Reporting is crucial and is used to keep all levels of management updated on the progress of the project, its products, and associated work packages. The team managers provide the project manager with a checkpoint report, which functions similarly to a highlight report. The project manager collects these reports from all of their team managers and consolidates them into an executive summary called the highlight report. Using these checkpoint reports, the project manager monitors the schedule and makes sure that all product delivery required for the


89

stage remains on track. Any cost overruns must be documented in these checkpoint reports, because it is the responsibility of the project manager to submit an exception report to the project board if any overruns occur outside the tolerances provided. The project manager continually updates the project board on the status of the project’s progress and provides updated forecasts for the remainder of the current stage. This ensures the project board and the project manager both understand if the project is operating according to agreed-upon budget and schedule. The project plans and business cases, though, are not updated continuously during this process. Instead, those documents are updated only during the managing a stage boundary and as part of the end stage report.

Process: Managing Product Delivery

The managing product delivery process is the link that is controlled between the project manager and the team managers by agreeing on the requirements for acceptance, execution, and delivery of certain products required for each stage. Where controlling a stage is the primary responsibility of the project manager, the managing product delivery process is the main responsibility of the team manager. The team manager is responsible for coordinating an area of work to deliver one or more of the products for the project. Returning to the example of a custom-built house, there are numerous team managers involved, including a plumbing team manager, an electrical team manager, and an air conditioning team manager. Each of these team managers are responsible for the delivery of certain products in the house, such as the plumbing, the electrical wiring, and the heating and air system. The managing product delivery process has a few key objectives that must be considered during its execution. First, products must be allocated to specific teams and be approved by a project manager. After all, if the project manager does not approve the work, then nothing will get accomplished. The project manager is responsible to authorize the work packages or team plans. These may be created by either the project manager or submitted by the team manager.

The team managers and suppliers must be clear about what is expected of them in terms of the cost, schedule, time, and effort for a


90

given product. In the example of building the house, the plumbers must understand how many days the project manager has allocated to installing all of the piping. If the project manager has allocated only two days and two thousand dollars to run all the piping in a three bedroom, two bathroom home, but the plumbing manager estimated that it would take three days and four thousand dollars, then there is going to be a problem. The project manager and the team manager must agree on the total cost before work begins.

The managing product delivery process is also concerned with delivering products within the given tolerances. In our plumbing example, if the project manager allocated two days with a 50% tolerance for the schedule, then if the plumbers finished in one day or three days it is still within the agreed-upon tolerance. Project managers will usually give a tighter tolerance to the team manager than the project managers themselves have been given because the project manager needs to manage the combined tolerance across the stage and keep all products from exceeding the stage level tolerance.

Finally, the team managers must provide accurate progress information to the project manager at agreed upon frequencies. These checkpoint reports are the method that team managers use to provide updates and progress reports to the project manager, which includes the realized schedule and costs up to the current point in the stage. Essentially, it is a lower level highlight report, though often not as formal. Team managers should also raise any product issues to the project manager any time that a work package or team plan tolerance is exceeded or is forecast to be exceeded. This allows the project manager to submit an exception report to the project board if required.

What does your organization do if a supplier you are working with doesn’t actually use PRINCE2®? Most suppliers actually do not use the PRINCE2® methodology, because it is mostly used by project management professionals. The managing product delivery process is designed to act as the interface between the PRINCE2® methodology and the supplier. The supplier is simply given the work packages to perform and provided with the frequency of updates required or the events that would cause an out-of-cycle progress update to occur. The, the project manager and the organization can still operate according to the PRINCE2® methodology.

As the project plan is converted into a stage plan, the stage plan is then divided into work packages. These work packages are assigned to


91

individual suppliers and are completed regardless of that team’s understanding of the PRINCE2® methodology. After all, the plumber or electrician working on building a house does not need to understand the project management framework, they just need to understand the product description and the cost, schedule, quality, and tolerances that their team is expected to meet.

Process: Closing A Project

The closing a project process provides the project team with a

fixed point of confirmation for the acceptance of the project’s outcomes and products. At this point in the project, either the objectives set out in the original project initiation document have been achieved, the project has nothing more to contribute and is considered a failure, or the organization decided it no longer had a valid business case for the project. In either of these three cases, the project should now be ended and closed. Closing a project is a process, not a separate stage in the lifecycle. While the final delivery stage is occurring, the closing a project process begins. Of course, if the project is being terminated early, the closing a project process would occur during the current stage of the project instead.

The closing a project process is necessary in order to clearly define an end to the project. This is because projects are time constrained and form a temporary organization that should achieve something before being dismantled. By closing a project, the products are transitioned to the customer. The project team has successfully made a product, transitioned it to the customer, and once the customer accepts it, then the customer can operate the product. Additionally, by utilizing the closing a project process, the project management resources used during the project can now be released. As the project was being run, numerous people were assigned to various roles, such as the executive, the senior user, and the senior supplier. Now that the project is being closed, those people are released back to their own jobs or their next project. This guarantees the organization that no more costs will be incurred by this project. If the project wasn’t properly closed out, there may still be a line of accounting which could accrue additional charges and waste organizational resources.


92

When closing a project, it is important to document any outstanding items that were not completed during the project. Maybe the project team didn’t get to them because they were minor things that were not required for completion of the project or maybe the project was terminated early and not all the requirements and products were built. Either way, these items should be document so that others can restart them, if desired, and understand what happened during the project. Also, if there were any changes requested and not implemented during the project, these should be documented and passed on to the operational customer during the transition of the project’s products to operations. Any risks that may still affect operations should also be disclosed to the customer. This includes any risk mitigation techniques that were utilized during the design and building of the products, because the customer may wish to continue to implement them during the operations phase of the product’s lifecycle. Part of closing the project includes creating an end project report which documents the details of the project upon its closure. The project manager must also create a project closure notice. One of the final tasks of the project manager is to create a project closure notice. This is then sent to the project board to either approve or deny using the directing a project process. This is the last official approval action of the project board for this particular project.

When the project closure is authorized, all management projects should be securely archived and available for future audits because the project can be audited as part of the quality assurance approach in the organization, even after the project is closed. Nothing from the project should be deleted; instead, everything is properly archived and saved. What is the end state when a project has reached final closure? First, the products are transferred over to the customer so that they can utilize them and realize the expected benefits. For example, if the project was to build a network so that another hundred employees could work in the building, at this point there should be a new network that is operating and employees using that network. The benefit is realized, and the project can now be closed.

The project management team returns to their normal roles, or if the project management team is a dedicated team, they will instead be assigned to another project. But before the team disperses, they should


93

document any lessons learned one last time because these will be useful in future projects.


94


95

CHAPTER SIX CONCLUSION

OBJECTIVES

• Take and pass the PRINCE2® Foundation exam

At this point, everything you need to know to take and pass the PRINCE2® Foundation certification exam has been covered.

In Chapter Two, you were introduced to the seven principles of PRINCE2®: continued business justification, learn from experience, defined roles and responsibilities, manage by stages, manage by exception, focus on products, and tailor to suit the project environment. In Chapter Three, we covered the seven themes in PRINCE2®: the business case, organization, quality, plans, risk, change, and progress. In Chapter Four, we combined the principles and themes in order to put them into practice in the real world by using processes. Describing the who, what, when, where, how, and why of a given project, we focused our learning on the PRINCE2® seven processes: starting up a project, initiating a project, directing a project, controlling a project, managing our product delivery, managing a stage boundary, and closing out a project.

With the foundational understanding of the principles, themes, and processes, what should you do next in order to prepare to take and


96

pass the PRINCE2® Foundation certification exam on your first attempt?

First, you should test yourself using the two full-length practice exams located in Chapter Seven and Chapter Eight of this book. Each practice exam contains sixty multiple-choice questions, just like the real PRINCE2® Foundation certification exam. When you take those exams and you are scoring at least 75% of higher on them, you are ready to schedule your official certification exam through PeopleCert. When you check your answers on the practice exams, you should not only verify what the correct letter choice was, though. Each answer contains a short explanation of why the correct answer was correct, and you should attempt to understand the reasoning behind the correct answer. Always learn from your mistakes on these practice exams in order to get them correct the next time you attempt them and on exam day. If you are still struggling with these practice exams, please find additional practice exams to test your skills. At the back of this book, you will find information on how to register you copy of this book at our website. Upon registration, you will get free access to additional practice exams to use as practice during your study efforts.

Remember, if you have read this entire book and scored at least a 75% or higher on the practice exams, then you are ready to take and pass the PRINCE2® Foundation certification exam on your first attempt!

With that said, I want you to practice, practice, practice, and then go take that exam! And don’t forget to let me know when you have joined the ranks of those who are PRINCE2® Foundation certified!


97

CHAPTER SEVEN PRACTICE EXAM #1

GUIDELINES • Practice exams should be taken without using any notes • Try to complete the 60 questions in under 60 minutes • Aim to achieve a score of 85% or higher on this exam

1. What BEST describes the purpose of a lessons log?

a) Document and maintain information on issues b) Document who should receive copies of highlight reports c) Document information from other projects that could be input

to the project’s strategies and plans d) Document the results of quality checking activities

2. What is an output of a project in PRINCE2®?

a) Business benefits b) Any of its tangible or intangible specialized products c) Resources d) Results of change


98

3. What role is responsible for managing the information flows between the directing and delivering levels of the project? a) Project manager b) Project support c) Team manager d) Senior user

4. What situation would cause an issue report to be produced?

a) Whenever the project board directs the project manager b) It should only be created for those issues that need to be

handled formally c) Every time someone wishes to bring anything to the attention of

the project manager d) Only if the project manager feels it is necessary

5. What role can the project manager NOT perform?

a) Change authority b) Project assurance c) Project support d) Team manager

6. What describes a favorable impact on objectives, also known as an opportunity? a) A competitor may launch a rival product first, thus affecting the

expected market share for the product b) The product might complete user acceptance testing in a single

test cycle rather that in the two cycles scheduled c) A prototype may be damaged in transit d) A critical meeting could be affected by air travel disruption

7. What BEST describes a purpose of the benefits review plan? a) Defines how and when a measurement of the project’s benefits

can be made b) Documents the justification for undertaking the project c) Provides all of the right information for decisions to be made

regarding continued business justification d) Describes just the benefits that are only to be delivered after the

project


99

8. What process has the specific objective to ensure that there is a business justification for initiating the project? a) Directing a project b) Controlling a stage c) Starting up a project d) Initiating a project

9. What is a purpose for the closing a project process? a) Provide a fixed point at which acceptance for the project

product is confirmed b) Enable the project board to review the success of the current

stage c) Assign work to be done and monitor such work d) Enable the organization to understand the work that needs to be

done to deliver the project’s products

10. What role cannot be shared? a) Project assurance b) Project support c) Executive d) Team manager

11. When is the stage plan for project initiation is produced? a) Immediately prior to the authority to deliver a project has been

given b) Before the project board authorizes the initiation of the project c) After the project plan has been produced d) During managing a stage boundary process

12. What is the purpose of the progress theme? a) To identify, assess, and control uncertainty b) To establish mechanisms to monitor and control what has

happened against what is planned c) Facilitate communication and control by defining the means of

delivering the products d) Define and implement the means by which the project will

create and verify that products are fit for purpose


100

13. What product establishes the baseline against which the project’s actual performance is compared? a) Project brief b) Product status account c) Project initiation documentation d) Configuration item record

14. What process controls the link between the project manager and

the team manager? a) Controlling a stage b) Managing a stage boundary c) Managing product delivery d) Directing a project

15. Which is NOT a purpose of a product description? a) Define the time and cost needed to produce the product b) Define the quality skills required to check the product c) Defines functionality and appearance of the product d) Defines development skills required to produce products

16. What can a project board control? a) Project-level tolerance b) Stage-level tolerance c) Checkpoint report d) Quality register

17. What is NOT a purpose of a product description? a) Defines the level of quality required for the product b) Records the quality results of the stage c) Defines the people or skills required to produce, review, and

approve the product d) Understand the detailed nature, purpose, function and

appearance of a product


101

18. What role has the specific responsibility for briefing non-technical management on supplier aspects of the project? a) Team manager b) Project manager c) Senior supplier d) Team member

19. What is an objective of the directing a project process?

a) Enables the project board to be accountable for the project’s success

b) Verifies user acceptance of the project’s products c) Ensures that the host site is able to support the products when

the project is disbanded d) Ensures that there is authority to deliver the project’s products

20. What is NOT a type of issue? a) Concession b) Off-specification c) Request for change d) Problem/concern

21. What BEST describes the purpose of starting up a project process? a) Provide the information required for the project board to decide

whether it is worthwhile initiating the project b) Plan the strategy on how the quality expected by the customer

will be achieved c) Look for lessons to be learned from this project d) Document how changes to products will be captured and

reviewed

22. What role is responsible for briefing corporate or program management about project progress? a) Team manager b) Project support c) Project board d) Project manager


102

23. What product would be at the center of any impact assessment of risks, issues, and changes? a) Highlight report b) Business case c) Lessons log d) Communication management strategy

24. What factor is NOT considered when defining stages? a) How long the project is b) When team managers are available c) When key decisions are required on the project d) The amount of risk within the project

25. What step would involve sending information regarding any threats or opportunities to an external interested party? a) Identify b) Communicate c) Implement d) Plan

26. In which product is the acceptance criteria documented?

a) Project product description b) Product description c) Quality register d) Quality management strategy

27. What task is NOT carried out as part of product-based planning? a) Write a project product description b) Identify activities and dependencies c) Create a product breakdown structure d) Create a product flow diagram

28. What plans can the project manager approve?

a) Project plan b) Team plan c) Exception plan at stage-level d) Stage plan


103

29. What BEST describes something that should be provided by the project but currently is not being provided? a) Problem/concern b) Concession c) Off-specification d) Exception report

30. What product is NOT routinely produced as part of the managing a stage boundary process? a) Next stage plan b) Updated project plan c) Exception plan d) Updated business case

31. What is the supplier’s responsibility within the customer/supplier

environment? a) Define the acceptance criteria for the project product b) Ensure that the resources are made available to deliver the

required result c) Secure the funding for the project d) Specify the desired project outcomes

32. What is a characteristic of a project compared to that of business operations? a) Incurs cost b) Introduces business change c) Delivers benefits d) Creates products

33. What level of management in the project management team has the ability to review progress and decide whether to continue, change, or stop the project? a) Project manager b) Project board c) Team manager d) Corporate or program management


104

34. What department should a forecast breach of benefits tolerance be referred to? a) Project manager b) Executive c) Senior supplier d) Corporate or program management

35. What role is responsible for identifying and advising the project manager of issues/risks associated in a work package? a) Senior supplier b) Team manager c) Project support d) Project assurance

36. What is NOT a valid risk response to threats? a) Accept b) Avoid c) Enhance d) Fallback

37. What choice below would NOT be classified as a threat to a project? a) A competitor may launch a rival product first thus affecting the

expected market share for the product b) A product might complete its user acceptance testing in a single

test cycle rather that the two scheduled test cycles c) A prototype may be damaged in transit d) A critical meeting could be affected by air travel disruption

38. When producing an exception plan for a stage, what would require the quality register to be updated? a) The quality register is NOT updated when creating an exception

plan b) To add details of new quality management activities planned c) To close all quality checks from the stage plan that’s about to be

replaced d) To record any corrective actions required when the quality

checks of products in the current stage plan were complete


105

39. Along with users and suppliers, what is the third interest that is represented by the three primary stakeholder interests on the project board at all times? a) Customer b) Business c) Program d) Corporate

40. What process contains a review of the performance of the project

against its baselines? a) Initiating a project b) Closing a project c) Managing product delivery d) Starting up a project

41. What is an objective of the managing product delivery process? a) To ensure regular reports are issued to the senior supplier b) To capture and examine issues and risks c) To ensure the planned products are delivered to expectations

and within tolerance d) The project board should commit to resources for each work

package before it’s allocated to a team

42. What is NOT one of the three levels of plan? a) Stage b) Team c) Benefits Review d) Project

43. What process has the purpose of taking action to ensure the stage remains within tolerance? a) Directing a project b) Controlling a stage c) Managing a stage boundary d) Managing product delivery


106

44. What product confirms the version numbers of all products being developed within a given stage? a) Configuration item record b) Stage plan c) Work package d) Product status account

45. What BEST shows the scope of a plan?

a) Full contents of a product status account for a related work package

b) Related plan’s product breakdown structure c) Composition section of a project product description d) All of the project’s configuration item records

46. What product would the project manager update to show that progress has been made by documenting the information about the progress received on a work package? a) Checkpoint report b) Stage plan c) Benefits review plan d) Project plan

47. A PRINCE2® principle states that a project must have a(n) __________ in order for a project to start and continue on. a) Lesson applied throughout b) Continued business justification c) At least two stages d) Focus on products that will meet business expectations

48. What product would be at the center of any impact assessments of

risks, issues, and changes in a project? a) Highlight report b) Business case c) Lessons log d) Risk management strategy


107

49. What is NOT a purpose of the benefits review plan? a) Define how to measure the achievement of the project’s benefits

can be made b) Define what benefits assessments need to be undertaken c) Define the project in order to form the basis for its management

and an assessment of its overall success d) Define the activities required to measure the expected project’s

benefits

50. What PRINCE2® principle does every project’s organizational structure need to have? a) Defined and agreed upon roles and responsibilities with an

organization structure that engages the business, user, and supplier primary stakeholder interests

b) People allocated to clearly defined management jobs and assigning those jobs on a one-to-one basis

c) As many stakeholders as possible from the customer environment involved in key decision making throughout the project’s life cycle

d) Stakeholders who are responsible, accountable, consulted, and informed throughout every stage of the project

51. How should a team manager inform the project manager if a work

package is forecast to exceed its tolerances? a) Raise an exception report b) Issue an exception plan c) Raise an issue d) Raise a risk

52. What BEST describes when an issue report would be produced? a) Whenever the project board instruct the project manager b) Only for those issues that will be handled formally c) Every time someone wishes to bring anything to the attention of

the project manager d) Only if the project manager feels it is necessary


108

53. What is the purpose of the risk management strategy? a) Describes in detail each risk identified in the project and how

each risk should be managed b) Describes how each risk owner and risk actionee will manage

and fund the actions to mitigate each risk c) Describes the risk response actions taken to mitigate the

project’s risks d) Describes the techniques and standards to be applied and the

responsibilities for achieving effective risk management procedures

54. What is the configuration management strategy purpose?

a) Define the various types of quality methods to be applied to the project’s products

b) Provide details of the current state and version of each configuration item

c) Record how the products will be protected and uniquely identified

d) Define what the budget will be for controlling any risks

55. What BEST defines a product’s quality tolerance? a) Project product description b) Product description c) Stage plan d) Quality management strategy

56. What product would best answer the question, “Is an investment in this project still worthwhile?” a) Business case b) Risk management strategy c) Issue register d) Benefits review plan


109

57. What BEST describes the purpose of a business case? a) Defines how and when a measurement of the project’s benefits

can be made b) Helps to establish whether the project is achievable c) Allows the project board to manage by exception by providing

confirmation of continued business justification d) Describes the risks to be managed throughout the project

58. What action should be done during the initiation stage? a) Appoint the executive b) Establish who needs information, when, and in what format c) Establish the quality expectations of the customer d) Define how the project will deliver the chosen business solution

59. What is NOT an event-driven control?

a) Highlight report b) Exception report c) Project initiation documentation d) End of a stage

60. What BEST describes the main purpose of the directing a project

process? a) Enable the project board to exercise overall control of a project b) Prepare a solid foundation for the project c) Establish the prerequisites for the initiation of a project d) Assign work packages


110


111

CHAPTER EIGHT PRACTICE EXAM #2

GUIDELINES FOR THE PRACTICE EXAM • Practice exams should be taken without using any notes • Try to complete the 60 questions in under 60 minutes • Aim to achieve a score of 85% or higher on this exam

1. What product records any information regarding issues that are

managed informally? a) Configuration item record b) Issue register c) Daily log d) Risk register

2. According to the change theme, what are the steps of the recommended issue and change control procedure? a) Capture, examine, analyze impact, review probability, implement

action b) Capture, log, review, resolve c) Assess, decide, escalate, implement d) Capture, examine, propose, decide, implement


112

3. When is the risk management strategy produced? a) After authorization was given to proceed with the initiation stage b) Before the planning of the initiation stage c) As soon as the project manager is appointed at project start-up d) After the project board approves the project initiation

documentation

4. What BEST describes the term risk effect? a) The area of uncertainty in terms of the threat or the opportunity b) The situation that gives rise to the risk c) The impact(s) that the risk would have on the project objectives

should the risk materialize d) How soon in the future the risk is likely to occur

5. What principle is supported by the project product description?

a) Continued business justification b) Focus on products c) Learn from experience d) Manage by stages

6. What role represents the interests of the people operating the project’s products? a) Senior supplier b) Executive c) Change authority d) Senior user

7. When does the directing a project process start?

a) On completion of the starting up a project process b) On completion of the initiating a project process c) When the starting up a project process commences d) After the project has been authorized

8. What process would the directing level of management use to

ensure there is continued business justification? a) Directing a project b) Managing a stage boundary c) Initiating a project d) Controlling a stage


113

9. What is the purpose of the the configuration item records?

a) Record quality issues found in a quality test of the product b) Explain which procedure should be used for updating the

configuration item records of products completed in the stage c) Explain which procedure should be used for transferring

completed products into the operational and maintenance environment

d) Record the development status of a product in a completed work package

10. What role is responsible for designing and appointing the project

management team? a) Project manager b) Executive c) Senior user d) Project assurance

11. What role has the specific responsibility for planning, monitoring,

and managing the team’s work? a) Senior supplier b) Project support c) Team manager d) Project manager

12. Consider the following statements:

(I) If the stage is forecast to exceed its tolerances, the project manager should produce an Issue Report to capture and analyze the details of the deviation. (II) When a Work Package is forecast to exceed its tolerances, the project manager may request the team manager to produce an Exception Plan. a) Only statement I is true b) Only statement II is true c) Both statements are true d) Both statements are false


114

13. What is a step in the issue and change control procedure that is used to evaluate the alternative options to respond to an issue? a) Propose b) Examine c) Capture d) Decide

14. What is NOT a purpose of the end stage report?

a) Allow the project board to decide what to do next with the project

b) Help decide whether to amend the project scope or to stop the project

c) Escalate a stage-level tolerance threat to the project board d) Give a summary of progress to date

15. What product holds each product’s current version and any

important relationships between them? a) Product description b) Highlight report c) Configuration item record d) Work package

16. What process BEST describes when an exception plan should be

created to replace a stage plan? a) Directing a project b) Controlling a stage c) Managing a stage boundary d) Closing a project

17. Where would you document the reasons why the project is required to be performed? a) Business case b) Benefits review plan c) Project product description d) Project approach


115

18. When should the initiation stage plan be produced? a) Immediately prior to the authority to deliver a project has been

given b) Before the project board authorizes the initiation of the project c) After the project plan has been produced d) During managing a stage boundary process

19. What product identifies the source products from which a product

is to be derived? a) Product breakdown structure b) Product checklist c) Product description d) Project approach

20. What best describes the purpose of the business case theme in

PRINCE2®? a) Provide full details of any risks related to the project b) Provide a forecast for the project objectives and the project’s

continued viability c) Establish ways of judging whether the project is and remains

viable, desirable, and achievable to assist with decision making d) Specifies the ways in which the project will deliver the chosen

business solution

21. What is an individual who is responsible for the management, monitoring and control of all aspects of a particular risk assigned to them known as? a) Risk actionee b) Risk coordinator c) Project risk manager d) Risk owner

22. After starting up a project process, what product is used to capture

and maintain information on all of the identified threats and opportunities relating to the project? a) Risk management strategy b) Risk register c) Issue register d) Quality register


116

23. What is a specific responsibility of Project Assurance? a) Approving the Risk Management Strategy b) Giving ad-hoc direction to the project manager c) Reporting highlights to the project board d) Ensuring that right people are planned to be involved in quality

inspection

24. Consider the following statements: (I) There can be more than one technical stage per management stage. (II) The work can be grouped by the set of techniques used or the products created. a) Only statement I is true b) Only statement II is true c) Both statements are true d) Both statements are false

25. What are typical characteristics of a project board member?

a) Democratic, supportive, can make decisions b) Hard working, experienced, forceful c) Focused, steadfast, autocratic d) Have authority, credibility, ability to delegate, available when

required

26. Which role is a part of the quality review team? a) User b) Approver c) Reviewer d) Project support

27. What defines the sequence in which the products are to be created

and any dependencies between them? a) Product status account b) Product flow diagram c) Product breakdown structure d) Product description


117

28. What role is the single focus for day-to-day management of the project? a) Project manager b) Executive c) Project support d) Team manager

29. When does the directing a project process start?

a) When corporate or program management issues a project mandate to trigger a project

b) As soon as the necessary authorities are appointed for initiating the project

c) On completion of the starting up a project process d) Once the project initiation documentation is submitted for

project board approval

30. What is considered an issue likely to affect the project, according to PRINCE2®? a) The project manager’s workload b) The project’s performance targets c) The customer/supplier relationship d) Only the project plan

31. What would the project manager use for gathering work package

progress information? a) Highlight report b) Daily log c) Checkpoint report d) Product status account

32. What process defines the project’s risk management techniques and

standards? a) Starting up a project b) Directing a project c) Initiating a project d) Managing product delivery


118

33. What is a prioritized list of measurable definitions of the attributes required for the set of products to be acceptable to the key stakeholders? a) Acceptance criteria b) Quality criteria and related tolerance c) Project product description d) Product status account

34. What provides the documentation of which business option your

project is choosing to use, such as do nothing, do the minimum, or do something in terms of the project’s investment? a) Project approach b) Business case c) Risk management strategy d) Benefits review plan

35. What is a characteristic of a project?

a) Projects are free of risk b) Projects have no uncertainty c) Projects are managed as part of business as usual d) Projects are cross-functional

36. What PRINCE2® theme defines the method of facilitating

communication and control by defining the means of delivering the products? a) Plans b) Progress c) Organization d) Change

37. What process demonstrates that each product meets its quality

criteria? a) Closing a project b) Managing a stage boundary c) Directing a project d) Managing product delivery


119

38. What factor does NOT need to be taken into consideration when identifying the number of management stages required? a) Where key decisions points need to be b) The amount of risk within the project c) The number of technical stages d) How confident the project board and project manager are with

proceeding

39. In PRINCE2®, what is TRUE about a project? a) Projects are covered in section 2.3 of the PRINCE2® Manual b) Work package level activities are identified when Starting up a

project c) A project has defined and agreed roles and responsibilities d) Every project will need a different project management

approach

40. A principle of PRINCE2® is that a project has defined and agreed upon ______. a) Roles and responsibilities b) Specialist teams with appropriate technical skills c) Management jobs with job descriptions d) Senior managers at all levels of the project management team

41. What PRINCE2® principle supports a project being output

oriented? a) Focus on products b) Defined roles and responsibilities c) Manage by stages d) Continued business justification

42. What is the purpose of a business case?

a) To enable the identification of risks and their impact b) To identify the quality expectations of the customer c) To document the details of how and when benefit reviews will

be undertaken d) To document the justification for undertaking the project


120

43. What product is continuously maintained in order to inform the project manager of where a product is at any time, what its status is, and who is working on it? a) Product description b) Highlight report c) Configuration item record d) Work package

44. Who is allowed to raise project issues?

a) Only the project manager and team manager b) Anyone with an interest in the project or its outcome c) Only the change authority d) Only members of the project management team

45. What is NOT recommended when responding to a threat? a) Avoid b) Exploit c) Share d) Transfer

46. What is the controlling a stage process used for?

a) Day-to-day management of each management stage of a project b) Closure of the project prematurely or at the project’s natural end c) Creation and quality control of the specialist products d) Preparing a stage plan near the end of each stage

47. Whose responsibility is it to provide the project mandate?

a) Project support b) Corporate or program management c) Project manager d) Project board

48. A risk consists of a combination of the _______ of a perceived

threat or opportunity occurring and the magnitude of its impact on objectives. What word BEST fills in the blank? a) Outcome b) Probability c) Dis-benefit d) Proximity


121

49. What BEST informs the project board of a forecast deviation of stage-level tolerance? a) Exception plan b) Exception report c) Off-specification d) Lessons report

50. What role has the assurance responsibility of monitoring any risks

in the production aspects of projects? a) Senior user b) Team manager c) Senior supplier d) Executive

51. What best describes risk appetite? a) An organization’s unique attitude towards risk taking that

dictates the amount of risk that it considers acceptable b) A stakeholder’s perception of how a risk affects them c) The net financial effect of all risks when aggregated together d) The levels of risk exposure that, when exceeded, will trigger an

exception report

52. What process authorizes a premature closure of the project? a) Directing a project b) Controlling a stage c) Managing a stage boundary d) Closing a project

53. What does the product description NOT provide?

a) Necessary abilities of the people needed to produce the product b) Why the product is needed and what it will look like c) Necessary abilities of the people needed to review the product d) Time and cost needed to produce the product


122

54. What role has the specific responsibility for referring to the project board if any delegated limits of authority or allocated change budget are forecast to be exceeded? a) Senior user b) Project assurance c) Change authority d) Project manager

55. What process provides the opportunity to ensure that all unachieved goals and objectives are identified? a) Initiating a project b) Controlling a stage c) Directing a project d) Closing a project

56. When authorizing a stage, what product would the project board

look in for an explanation of any deviations from the approved plans that are within tolerance? a) Lessons report b) End stage report c) Benefits review plan d) Project initiation documentation

57. What role has the specific responsibility for planning, monitoring,

and managing the team’s work? a) Senior supplier b) Project support c) Team manager d) Project manager

58. Which of the following is not a PRINCE2® principle?

a) Manage risks b) Manage by exception c) Focus on products d) Tailor to suit the project environment


123

59. What is a purpose of the controlling a stage process? a) To enable the organization to understand the work that needs to

be done to deliver the project’s products b) To delegate day-to-day management of the project to the project

manager c) To report progress to the project board d) To report progress to the project manager

60. If project assurance is being conducted by anyone other than the

project board, then who would they report to? a) Corporate or program management b) The project board member overseeing the relevant area of

interest c) The project manager d) The team manager whose work package execution is being

monitored


124


125

APPENDIX A Answer Key to Practice Exam #1

OBJECTIVES • Understand the correct answers to Practice Exam #1

As you check the answers to your Practice Exams #1, it is important to understand why each answer is correct. As you go over your practice exam results, ensure that you pay close attention to the questions you missed and understand the explanation provided for their correct answers.

Answers to Practice Exam #1

1. C - The PRINCE2® lessons log template is a project repository for lessons that apply to this project or future projects. Some lessons may originate from other projects and should be captured on the lessons log for input to the project’s strategies and plans.

2. B - A project’s output is any of the project’s specialized products,

whether tangible or intangible. These outputs can result in certain outcomes, which in turn create benefits.

3. A - The project manager manages a project on a day-to-day basis

and is the only one with this day-to-day focus on the project. The


126

project manager runs the project on behalf of the project board within specified constraints and liaises throughout the project with the project board and project assurance.

4. B - An issue report is a report containing the description, impact

assessment, and recommendations for a request for change, off-specification, or a problem/concern. It is only created for those issues that need to be handled formally.

5. B - The project assurance role assures the interests of the primary

stakeholders. The change authority role decides on some of the request for changes on behalf of the project board. The project support role helps the project manager in project management activities. The team manager role is one or more people responsible for ensuring the quality and other variables of production in the teams. The project manager can have multiple roles, but they cannot fulfill both the project manager and the project assurance role simultaneously.

6. B - If it is possible that the product completes user acceptance

testing in a single test cycle rather that the scheduled two, then it could be an opportunity. For example, this could enable the product to be delivered early and prior to a competitor’s rival product.

7. A - The purpose of the benefits review plan is to identify the

benefits and to select how the benefits can be measured so that it is possible to show that they have been reached. You can then compare the new results to the baseline measurements which recorded the current situation as it exists today.

8. C - The starting up a project process is responsible for ensuring

that there is a business case (business justification) for the project and this should be documented in the outline business case.

9. A - One of the problems with projects is that when they come to

their end point, it is not clear when to close the project, or worse, there are arguments about whether the project has delivered what it promised. The purpose of the closing a project process is to


127

provide a fixed point to check that the project has reached its objectives and that the products have been accepted. If there are any unachieved goals and objectives, they are identified during this process.

10. C - The executive is the single person with overall responsibility for

ensuring that a project meets its objectives and delivers the projected benefits. This individual should ensure that the project maintains its business focus, that it has clear authority, and that the work, including risks, is actively managed. The executive is the chair of the project board. He or she represents the customer and is responsible for the business case. This role cannot be shared.

11. B - The stage plan is the detailed plan for a particular stage of a

project. The stage plan for the first delivery stage of a project should be prepared and completed during project Initiation but before the project board authorize initiation. Subsequent Stage Plans are prepared towards the end of the preceding stage.

12. B - The purpose of the PRINCE2® progress theme is to check the

progress of the project compared to the plan, to check project viability, and to control any deviations.

13. C - The project initiation documentation is a living product in that

it should always reflect the current status, plans, and controls of the project. Its component products will need to be updated and re-baselined, as necessary, at the end of each stage, to reflect the current status of its constituent parts. This document is used to compare the established baseline, recorded in the document, against the actual performance achieved by the project.

14. C - The objective of the managing product delivery process is to

ensure that the products assigned to the team are authorized and agreed upon. A second objective is to ensure that the team is clear about what has to be produced and understands the effort, time, and cost needed to achieve the desired result. Finally, it ensures that the planned products are delivered to the expectations and within tolerance.


128

15. B - A product description is used to (1) understand the detailed nature, purpose, function and appearance of the product, (2) define who will use the product, and (3) identify the sources of information or supply for the product.

16. B - The executive and the project board will set stage-level

tolerances at each end stage assessment. These tolerances allow the executive to authorize a stage or exception plan process. This is a ‘contract’ with the project manager who will manage the stage on a day-by-day basis.

17. B - A product description is normally written for each of the

identified products in the product breakdown structure, if required. This defines the purpose that the project’s product will fulfil and who will use it. It is helpful in understanding the product’s functions, size, quality, complexity, robustness, etc.

18. C - The senior supplier role represents the interests of those

designing, developing, facilitating, and implementing the project’s products. They provide supplier resources to the project and ensure that the right people, tools, equipment and knowledge are in place, and that the products will meet the expected criteria, including quality criteria. It is their job to brief non-technical management on supplier aspects of the project.

19. D - The objectives of the directing a project process are to provide

authority (to make a decision), to initiate the project (allow the initiation stage to start), to deliver the project’s products (start the delivery stages), and to close the project. The directing a project process gives the corporate or program management an interface to the project through direction of the project board.

20. A - There are three types of issues: request for change, off-

specification, and problem/concern. 21. A - The purpose of this process is to answer the question, “Do we

have a worthwhile and viable project?” The project mandate is usually the only document that exists when this process starts, and this is not enough information for the project board to make the


129

decision to start the initiation stage. Therefore, the purpose of this process is to provide the project board with the necessary information to judge whether the project is worth moving forward with.

22. C - The project board consists of the executive, the senior user,

and the senior supplier. Only one person can be the executive while both the senior user and senior supplier roles may be assigned to one or more persons. The project board is responsible for briefing corporate or program management about the progress of the project.

23. B - The purpose of the business case is to provide a structure to

judge whether the business case is desirable, viable, achievable, and worth the continued investment that is made during the project. The business case theme provides a mechanism to judge whether the project is and remains desirable and achievable. All risks, issues, and changes should be considered through the perspective of the business case.

24. B - Management stages are defined by key decision points

(conditions or time-based). The factors considered are how long the project is, the key decisions needed, and the amount of risk within the project. The availability of team managers should not be a factor.

25. B - The communicate step involves sending information to the

stakeholders of a project. You should use existing management reports that are created during the project to send this information, such as the end stage report.

26. A - Acceptance criteria define a prioritized list of measurable

definitions of attributes required for products to be acceptable to key project stakeholders. It is documented inside the project product description.

27. B - The product based planning technique consists of four steps.

(1) Create a project product description for the project final product (used for project plan only); (2) Create the product


130

breakdown structure; (3) Create a product description for each main lower level product (not all may need a product description); and (4) Create a product flow diagram.

28. B - Team plans are produced by the team manager to plan the

execution of one or more work packages. Team plans are optional, depending on the project’s size, complexity and the number of resources involved in creating the products. The project manager can approve team plan’s without needing more senior manager approval.

29. C - Off-specification is something that should be provided by the

project, but currently is not provided nor forecasted to be so. For example, if a piece of functionality is missing, or even a product that is missing, then an off-specification may be necessary.

30. C - The purpose of managing a stage boundary process has two

parts. First, the project manager has to provide the project board with an overview of the performance of the current stage, update the project plan and business case, and create a stage plan for the next stage. Then, this information enables the project board to review the current stage, approve the next stage, review the updated project plan, and confirm continued business justification.

31. B - It is vital that those who design, build, and deliver the products

requested by the user should also be represented on the project board. The senior supplier represents these groups.

32. B - Projects introduce business changes. Business operations run

the business and keep the lights on. They serve customers, and they hit targets. Business operations teams (or “business as usual” teams) also are the first to know when the existing business processes aren’t working and are no longer fit for purpose. When that happens, these teams are the ones who identify the need for change, but that change is introduced through a project.

33. B - The project board consists of the executive, the senior user and

the senior supplier. Only one person can be the executive while both the senior user and senior supplier roles may be assigned to


131

one or more persons. The executive owns the business case and has the final word on decisions; the project board is not a democracy.

34. D - Corporate/program management is the level of management

that exists outside of the project, either at organizational or program level. Ultimate responsibility for commissioning and setting project-level tolerances rests with this management level.

35. B - The team manager is the person responsible for the production

of the products assigned by the project manager, as defined in a work package, to an appropriate quality, timescale, and at a cost acceptable to the project board.

36. C - Valid risk responses to threats are avoid (take action so the

threat no longer has impact or can no longer happen), fallback (a contingency plan of action includes things that would be done if the risk occurs and would become an issue), and accept (a decision is taken to accept the risk since it may just be too costly to do something about it or it may not be possible to do anything about it). Enhance is a response to an opportunity. Enhance is when you take actions to improve the likelihood of the event occurring and you enhance the impact if the opportunity should occur.

37. B - If the product completes the user acceptance testing in only

one cycle instead of two, this isn’t a threat but an opportunity since you may be able to accelerate the schedule or save money on the project. The user acceptance testing phase of a project is often one of the most crucial because it determines whether your application is able to go live or if there are any other issues to address. As a project manager, it is in your interests to ensure that this phase runs as smoothly as possible, providing a clear plan for all concerned. Often this will include more than one stage because it provides more accuracy and efficiency.

38. B - An exception plan is used to recover from the effect of

tolerance deviation, which happens when a tolerance is exceeded. During the production of an exception plan, the quality register is


132

updated to add details of any new quality management activities planned.

39. B - A PRINCE2® project should always have three primary

categories of stakeholders which are represented in the project board. These are business, user and supplier.

40. B - A few of the objectives of the closing a project process are (1)

to verify that there is user acceptance of the project’s products; (2) to ensure that the operational team is able to support the products when the project and the project team is disbanded; and (3) to review the performance of the project against its baselines.

41. C - The objective of the managing product delivery process is to

ensure that the products assigned to the team are authorized and agreed upon. A second objective is to ensure that the team is clear about what has to be produced and understands the effort, time, and cost needed to achieve the desired result. Finally, it is also to ensure that the planned products are delivered to the expectations and within tolerance.

42. C - PRINCE2® recommends three levels of plans: project plan,

stage plan, and team plans. Since you can only accurately plan in detail a short time in advanced, it is often impossible to plan an entire project from the start. This is called the planning horizon, i.e., as far ahead as you can see. It is therefore a good idea to have different levels of plans.

43. B - The purpose of the controlling a stage process is for the project

manager to assign the work to be done, monitor this work, deal with issues, report progress to the project board and take corrective action to ensure that the stage remains within tolerance.

44. D - The product status account is a report on the status of

products. The required products can be specified by a unique identifier or the part of the project in which they were developed.

45. B - The scope of a plan is the sum total of its products and the

extent of their requirements. It is described by the product


133

breakdown structure for the plan and associated product descriptions.

46. B - A stage plan is a detailed plan used as the basis for project

management control throughout a stage. It should be updated by the project manager to show the progress that has been made on a project.

47. B - For a project to start and carry on, a PRINCE2® principle

states that a project must have a continued business justification. This is accomplished by each project having a business case. This means that the reason to start the project must make sense from a business point of view, and there must be a clear return on investment.

48. B - In the major risk section of the business case, a summary of any

major risks associated with the project is contained, including an evaluation of their likely impact and plans for dealing with their occurrence. These risks are taken into consideration by the project board when deciding whether to proceed with the project both when the project is starting up and also at the end of each management stage. If the project is deemed as too risky, then the project board may decide that it isn’t sensible to proceed any further with the project.

49. C - A PRINCE2® benefits review plan is used to define how and

when a measurement of the achievement of the project’s benefits, as expected by the senior user, can be made. The plan is presented to the executive during the initiating a project process, updated at each stage boundary, and used during the closing a project process to define any required post-project benefits reviews.

50. A - The PRINCE2® principle of “defined roles and

responsibilities” is critical to maintain in every project organizational structure. It ensures that everyone involved in a project should know both their own as well as their colleagues’ responsibilities. This includes knowing who the decision makers are for the project.


134

51. C - If a work package is forecast to exceed tolerance levels, the team manager would raise this as an issue to bring it to the attention of the project manager. The project manager may then, in turn, raise an exception report to the project board if he cannot solve the issue within his allowed tolerances and change budget.

52. B - An issue report is a description of an issue, which could be a

request for change, an off-specification, or a problem/concern. The issue report is usually created when the issue is first registered in the risk register.

53. D - The risk management strategy document defines the project

procedures for risk management in terms of how risk will be identified, assessed, controlled, and communicated in the project. This includes a description of the techniques and standards to be applied and the responsibilities for achieving effective risk management procedures.

54. B - The configuration management strategy is used to identify how,

and by whom, the project’s products will be controlled and protected. It is concerned with version and change control. The configuration management strategy is essential for the project to maintain control over its management and specialist products.

55. B - The PRINCE2® project product description template is a

special form of product description that defines what the project must deliver in order to gain acceptance. The quality tolerance are details of any range in the quality criteria within which the product would be acceptable.

56. A - The purpose of the knowledge in the business case theme is “to

provide a structure to judge whether the business case is desirable, viable, achievable, and worth the continued investment that is made during the project”. The business case theme provides a mechanism to judge whether the project is and remains desirable and achievable. A business case will help decision makers decide if an investment in a project is worthwhile and will provide a desirable return on investment.


135

57. B - The purpose of the knowledge in the business case theme is to provide a structure to judge whether the business case is desirable, viable, achievable, and worth the continued investment that is made during the project. The business case provides a mechanism to judge whether the project is and remains desirable and achievable.

58. B - This information should be established during the initiation

stage as part of the project initiation document. The purpose of the project initiation document is to capture and record basic information needed to correctly define and plan the project. The document should expand upon the project mandate and state what the project is aiming and planning to achieve, as well as the reason for the importance of meeting these aims.

59. A - Event driven controls occur when a specific event occurs. A

Highlight Report is used to provide the project board, and possibly other stakeholders, with a summary of the stage status at intervals defined by them. It is a time-driven management product.

60. A - The purpose of the directing a project process is to enable the

project board to be accountable for the project by making key decisions, to have overall control, and delegate day-to-day management of the project to the project manager.


136


137

APPENDIX B Answer Key to Practice Exam #2

OBJECTIVES • Understand the correct answers to Practice Exam #2

As you check the answers to your practice exam, it is important to understand why each answer is correct. As you go over your practice exam results, ensure that you pay close attention to the questions you missed and understand the explanation provided for their correct answers.

Answers to Practice Exam #2

1. C - The daily log is used to record problems/concerns that can be handled by the project manager informally. At its simplest, the daily log may just be a list of each action and the date it was raised/completed.

2. D - The five main steps recommended for issue and change control procedure are capture, examine, propose, decide, and implement.

3. A - A risk management strategy describes the specific risk management techniques and standards to be applied and the responsibilities for achieving an effective risk management


138

procedure and takes place before the initiating project stage.

4. C - Risk effect is the impact that the risk that would have on the project objectives should the risk materialize.

5. B - Focus on products is supported by the project product description. The project product description is a special form of product description that defines what the project must deliver in order to gain acceptance. The quality tolerance are details of any range in the quality criteria within which the product would be acceptable.

6. D - The senior user is responsible for specifying the products and outcomes expected. The senior user has a responsibility for articulating and realizing the benefits expected from a project. The senior user must therefore be able to demonstrate to higher levels of management that the project benefits are indeed being fulfilled. Therefore, the senior user represents the interests of the people operating the project’s products.

7. B - The purpose of the directing a project process is to enable the project board to be accountable for the project by making key decisions, to have overall control, and to delegate day-to-day management of the project to the project manager. Once authorization is received by completion of the initiating a project process, the directing a project process begins.

8. A - The purpose of the directing a project process is to enable the project board to be accountable for the project by making key decisions, to have overall control, and to delegate day-to-day management of the project to the project manager. The project board is responsible for ensuring that there is continued business justification and can decide to shut down the project if the business case is no longer viable, as this can change during the project.

9. D - The configuration item records are used to provide a record of information such as the history, status, version, and variant of each configuration item, and any important details of the relationships


139

between them.

10. B - The executive is the single individual with overall responsibility for ensuring that a project meets its objectives and delivers the projected benefits. This role is responsible for designing and appointing the project management team. This individual should also ensure that the project maintains its business focus, that it has clear authority, and that the work, including risks, is actively managed.

11. C - The team manager is the person responsible for the production of those products allocated by the project manager as defined in a Work Package to an appropriate quality, timescale, and at a cost acceptable to the project board.

12. A - If the stage is forecast to exceed its tolerances, the project manager should first produce an issue report to capture and analyze the details of the deviation and then provide an exception report for the project board. Based on information in this report, the project board may request that the project manager produces an exception plan to replace the plan that was forecast to exceed tolerance.

13. A - The issue and change control procedure under the change theme includes dealing with each project issue and involves five steps: capture, examine, propose, decide, and implement. The propose step is used to evaluate alternatives for dealing with the project issue and to recommended appropriate actions to address the issue.

14. C - An end stage report is used to give a summary of the progress to date, the overall project situation, and sufficient information to ask for a project board decision on what to do next with the project. A stage-level tolerance threat is brought up to the project board using an exception report.

15. C - A configuration management system is used to provide a record of such information as the history, status, version, and variant of each configuration item, and any important details of the


140

relationships between them.

16. A - The purpose of the directing a project process is to enable the project board to be accountable for the project by making key decisions, to have overall control, and to delegate day-to-day management of the project to the project manager. Management stages are a key tool for the project board in exercising high-level control over a project. Authorization must be granted at every stage boundary, and the project board must evaluate project and stage progress to date and review the next stage plan and the updated project plan and business case in order to decide whether the project remains viable. Authorization is also important if a project requires an exception plan. This happens when a project or stage is forecast to exceed its tolerances. Following its review of the exception report, the project board may instruct the project manager to create an exception plan.

17. A - The business case gathers the information to allow the management to judge if a project is desirable, viable, and achievable. It helps the executive determine if the project is worthwhile to invest in. The business case is normally developed at the start of the project and contains the reasons why the project is required to be performed.

18. B - At the end of each stage, a plan for the next stage is created and used as part of the evidence for the project board to make a decision whether or not to continue with the project and authorize the next stage. The same holds true for the initiation stage plan, so it should be produced prior to the project board authorizing the initiation of the project.

19. C - The product description presents information about a project’s component products. The product breakdown structure (PBS) visualizes these, and the description breaks them down.

20. C - The business case gathers the information to allow the management to judge if a project is desirable, viable, and achievable. It documents the justification for undertaking the project based on estimated costs and the benefits to be gained and


141

offset by any associated risks. This allows decision makers to determine if a project is a worthwhile investment. The business case is normally developed at the start of the project unless it has already been provided by an executive or the program management office. Once created, the business case is maintained throughout the life of the project.

21. D - The risk owner is responsible for managing, monitoring, and controlling risks aspects. They are responsible for ensuring that all actions are carried out by assigning them to the proper team members.

22. B - The risk register captures and maintains the information, both threats and opportunities, on all the risks that were identified for the project. It provides a record of all risks including their status and history.

23. C - They are there to serve as the eye of the project board member they represent. Their responsibility is to give assurance to the project board on the actual status of the project. This is done by reporting highlights back to the project board.

24. C - Both of these statements are true. There can be more than one technical stage per management stage. The work can be grouped by the set of techniques used or the products created.

25. D - Project board members should have authority, credibility, ability to delegate, and be available when required. The authority required will depend on the project, but they should be sufficiently senior to be able to make strategic decisions and provide appropriate resources, such as human, financial, and capital resources. The project board must be able to delegate responsibility to the project manager without involvement in the details of the project or its products. Finally, the project board must be available to make timely decisions.

26. C - The quality review technique has four specific roles. These are chair, presenter, reviewer, and administrator.


142

27. B - The product flow diagram is intended to depict the order and interdependencies of product development within the plan.

28. A - The project manager is the person given the authority and responsibility to manage the project on a day-to-day basis to deliver the required products within the constraints agreed with the project board.

29. C - Directing a project process begins after the request to initiate a project is done by the project manager at the end of the starting Up a project process.

30. B - In PRINCE2®, all changes are treated as a type of project issue. If a project’s performance targets are an issue, it is likely that project failure could occur.

31. C - The checkpoint report is a progress report of the information gathered at a checkpoint, which is given by a team to the project manager and provides reporting data as defined in the work package.

32. C - The definition of the project’s risk management strategy, both techniques and standards, are often found inside the project initiation document, which is created in the initiating a project process.

33. A - The acceptance criteria is a prioritized list of criteria that the project product must meet before the customer will accept it. For example, it can be measurable definitions of the attributes required for the set of products to be acceptable to key stakeholders.

34. B - The purpose of the business case is to provide a structure to judge whether the project is desirable, viable, achievable, and worth continued investment. The business case should describe the reasons for the project and include information on the estimated costs, risks and expected benefits. The business case contains an executive summary, reasons for doing the project, business options (do nothing, do the minimum, or do something), expected benefits,


143

expected dis-benefits, timeline, costs, ROI, and major risks.

35. D - There are five main characteristics of a project. Projects are the means by which changes are introduced into the business. A project is a temporary organization with a defined start and end date. Projects often bring together people with different skills from different departments and even different organizations, which means that the project environment is often cross-functional in nature. Also, every project is unique in what it delivers. Lastly, projects have a greater level of uncertainty than business as usual activities.

36. A - The purpose of the plans theme is to facilitate communication and control by defining the means of delivering the product.

37. D - The team manager follows a strict set of guidelines to ensure that the products contained in the Work Packages are created and delivered. The managing product delivery process ensures that the products are delivered to the expectations and within tolerance.

38. C - The number of technical stages is not a consideration when identifying the number of management stages. Key factors include the risk within a project, when key decisions need to be made, and how confident the project board and project manager are with the project.

39. C - In any project, people need to know what to do and what they can expect from others. PRINCE2® states that a project should have defined and agreed roles and responsibilities within an organization structure that includes the business, user, and supplier stakeholders’ interests. Projects can have people from different departments or companies, so it is important that the project has a clear team structure, otherwise it might be impossible to manage the project. Each role in the project management team has a defined role and agreed responsibility. To summarize the principle of “defined roles and responsibilities,” understand that a good project management structure answers the questions “What is expected of me?”, “What can I expect from others?”, and “Who


144

makes what decisions?”

40. A - PRINCE2® states that a project should have defined and agreed upon roles and responsibilities within an organization structure that includes the business, user and supplier stakeholders’ interests. To summarize the principle of “defined roles and responsibilities,” understand that a good project management structure answers the questions “What is expected of me?”, “What can I expect from others?”, and “Who makes what decisions?”

41. A - In PRINCE2®, even before the project begins, there is a need to understand and define what must be delivered from the project in order to ensure that the benefits are realized. This is done by writing a project product description. When planning each subsequent stage, more detailed product descriptions are developed for the major products of the project and are incorporated into the appropriate stage plan. When planning either the entire project or a single stage, you should focus on what will be delivered before making a decision to proceed to the next stage and allocating any additional resources.

42. D - It documents the justification for undertaking the project based on estimated costs and the benefits to be gained, offset by any associated risks. The business case gathers the information to allow the management to judge if a project is desirable, viable, and achievable. This allows decision makers to determine if a project is a worthwhile investment. The business case is normally developed at the start of the project unless it has already been provided by an executive or the program management office. Once created, the business case is maintained throughout the life of the project.

43. C - The configuration item record is a summary of a product’s status. It contains the stage of quality, the version number, who is responsible for the product, and cross-references to any project issues that have arisen.

44. B - An issue covers any relevant event that was not planned and that requires some management action, such as a question or a change request. Issues can be raised at any time during the project


145

and by anyone with an interest in the project or its outcome.

45. B - The six responses for threats are avoid, reduce, fallback, transfer, share, and accept. Exploit is not a response to a threat, but is instead a response to opportunity (exploit, enhance, share, and reject). Our goal is to reduce or prevent the risk from having a negative effect on our project.

46. A - The controlling a stage process describes the work of the project manager as they do their day-to-day management of a stage, and it is where the project manager does most of their work.

47. B - PRINCE2® projects have a controlled start, a controlled middle, and a controlled close. The project mandate triggers the controlled startand is begins the starting up a project process. The very first activity to take place is the creation of the project mandate itself from those with the appropriate level of authority. PRINCE2® calls this authority corporate or program management, with the latter being used if the project forms part of a larger program.

48. B - A risk consists of a combination of the probability of a perceived threat or opportunity and the magnitude of its impact on objectives. Risk is defined as uncertainty of outcome, and can be either a positive opportunity or a negative threat. Some amount of risk taking is inevitable if the project is to achieve its objectives. The task of risk management is to manage a project’s exposure to risk by reducing the probability of specific risks occurring and the potential impact if they did occur.

49. B - A PRINCE2® exception report is created whenever a stage plan or project plan is forecast to exceed the relevant tolerance bounds. At the first instance of forecasting that a tolerance is to be exceeded, the project manager will log it as an issue in the issue register.

50. C - The senior supplier is the project board role that provides knowledge and experience of the main discipline involved in the production of the project’s deliverables. The senior supplier


146

represents the supplier interests within the project and provides supplier resources.

51. A - Risk appetite looks at how much risk a company is willing to accept. There can still be deviations that are within a risk appetite. Before determining what to do about risks, the project board and project manager must consider the amount of risk they are prepared to tolerate.

52. A - Sometimes the project board will instruct the project manager to close the project. The project manager will not just abandon the project but should try to salvage anything of value so it can be used again. This closure can occur for many reasons, such as the project not meeting the desired benefits for the expended costs, or other such reasons.

53. D - The product description presents information about a project’s component products. The product breakdown structure (PBS) visualizes these and the description breaks them down. This includes the necessary abilities of the people needed to produce and review the product, as well as why the product is needed and what it will look like.

54. D - If the stage is forecast to exceed its tolerances, the project manager should first produce an issue report to capture and analyze the details of the deviation and then provide an exception report for the project board. Based on information in this report, the project board may request that the project manager produces an Exception Plan to replace the plan that was forecast to exceed tolerance.

55. D - The purpose of the closing a project process is to provide a fixed point to check that the project has reached its objectives and that the products have been accepted. If there are any unachieved goals and objectives, they are identified during this process.

56. B - A PRINCE2® end stage report template is used to give a summary of progress to date, the overall project situation, and sufficient information to ask for a project board decision on what


147

to do next with the project. The project board uses the information in the end stage report in tandem with the next Stage Plan to decide what action to take with the project.

57. C - The team manager has the responsibility to produce the products that were assigned in work packages by the project manager and to provide regular status reports to the project manager.

58. A - There are seven principles in PRINCE2®: continued business justification, learn from experience, defined roles and responsibilities, manage by stages, manage by exception, focus on products, and tailor to suit the project environment.

59. C - The purpose of the controlling a stage process is for the project manager to assign the work to be done, monitor work, deal with issues, report progress to the project board, and take corrective action to ensure that the stage remains within tolerance.

60. B - Even if the project board members choose to delegate their assurance responsibilities, they still must understand that they are still responsible for ensuring that the project is being run correctly.


148


149

APPENDIX C Glossary of Terms

OBJECTIVE

• Provide a reference for key terms and definitions

ACCEPTANCE CRITERIA Defined attributes for a set of products that the key stakeholders will consider acceptable AGILE Type of project management that is especially popular in software development; Methodology that focuses on dividing tasks into short phases or work that allows for frequent reassessment and adaptation of plans BASELINE An official version of a product within a project that cannot be further modified, altered, or changed without going through the official change management process BENFITS REVIEW PLAN A document (product) that outlines the positive things expected as a result of a project’s outcome


150

BENFITS MANAGEMENT APPROACH A document that is created during the project to specify how, when, and by whom the benefits of a project are measured BUSINESS CASE Required product that provides the justification for a project CHANGE A theme that seeks to identify, assess, and control any potential or approved changes to the project baseline CHANGE AUTHORITY The role responsible for making decisions regarding requests for change and off-specification requests CHANGE BUDGET A dedicated amount of money controlled by the change authority to fund authorized changes to the baseline CHANGE CONTROL PROCESS A process that contains five steps to conducting a change: capture, examine, propose, decide, and implement CLOSING A PROJECT A process used to provide a fixed point in the lifecycle of a project to ensure that a project has achieved its objectives and that the products associated with a project have been accepted by the user COMMUNICATIONS MANAGEMENT APPROACH A document that outlines how communications should occur with the stakeholders by identifying their information needs CONFIGURATION ITEM RECORD A document used in configuration management to record the status and version of a given product


151

CONFIGURATION MANAGEMENT Used to identify the different versions of products created during a project; consists of the configuration item record and the product status account CONTROLLING A STAGE A process used by the project manager to assign the work to be performed, to monitor this work, to deal with issues that arise, and to report the progress of the project to the project board CONTINUED BUSINESS JUSTIFICATION A principle that states that a project must always remain desirable, viable, and achievable COST TOLERANCES A set tolerance for a given budget’s line item to allow for variation in the cost of goods and services during the execution and delivery of a project DEFINED ROLES AND RESPONSIBILITIES A principle that ensures that everyone involved in a project knows what function they are fulfilling and what work is expected to be performed by each job function DELIVERY STAGE The subsequent stages of a project that are used to manage and execute product delivery DIRECTING A PROJECT A process used to provide direction and authorization to the project at key decision points throughout its lifecycle DEVOPS Short for “Development and Operations”, it is a software practice that aims at unifying software development and software operation; aims to create shorter development cycles by increasing deployment frequency through automation and monitoring


152

END PROJECT REPORT A document that serves to close out the project and allow the project team to evaluate the project as a whole, and to discern whether the project can now be closed and if there are any outstanding items remaining to be completed for the project END STAGE REPORT A document written by the project manager at the end of each stage to present the current level of progress achieved versus the progress that was forecasted EXCEPTION PLAN A plan created when a deviation from the project plan, stage plan, or team plan is required EXECUTIVE Person appointed by the corporation or program management to oversee the project board; person who retains the final decision authority and overall accountability for the success or failure of a project FIT FOR PURPOSE A product that meets the agreed upon requirements for the level of utility that it was designed. Asks the question, does the product fulfill the customer’s needs? FOCUS ON PRODUCTS A principle that seeks to always ensure that the successful delivery of products in a project will lead to the realization of the product’s benefits FRAMEWORK A basic underlying system, concept, or text such as a the PRINCE2® Framework GLOSSARY OF TERMS Listing of common terms and their meaning used by an organization or project team


153

INITIATING A PROJECT A process that is used to understand the work that is needed to be performed to deliver the required products in a project INITIATION STAGE The first stage in a project which is used to create the overall plan for product delivery LEARN FROM EXPERIENCE A principle that states the project team should implement lessons learned from previous successes and failures LESSONS LEARNED A documented issue or problem that was identified in a previous project and an organizational change occurred as a result LESSONS LOG A document used to capture and review the lessons learned during the project by the project manager LESSONS REPORT Collection of lessons captured and documented into a report that is provided to the project board MANAGE BY EXCEPTION A principle that empowers personnel to make decisions within an allowable and agreed upon tolerance without having to seek higher management’s approval MANAGE BY STAGES A principle that states a project should be separated into smaller portions for planning and execution; a minimum of two stages should be used, including the initiation stage and delivery stage MANAGING PRODUCT DELIVERY A process that is used by the project manager to manage and control the work of the team manager by setting requirements for the acceptance, execution, and delivery of products


154

MANAGING A STAGE BOUNDARY A process used by the project board to review and update all of the products within a project and then provide approval for the next stage plan to be executed METHODOLOGY Systematic approach to conducting a particular activity OFF-SPECIFICATION REQUESTS A type of change request that is made to have the product provide some functionality that is not currently being provided nor forecasted to be provided by the project OPERATION The active process or discharge of a function; business as normal ORGANIZATION A theme in PRINCE2® that involves defining and setting up a project management team structure OUTCOME The realization of a project’s benefit PLANNING HORIZON The length of time a project manager or project planner can accurately and realistically plan ahead PLANS A theme in PRINCE2® that helps facilitate communication and control by defining the means of delivering products PROCESSES The seven processes in PRINCE2® that are performed sequentially throughout the lifecycle of the project to move a project from an idea to its desired outcome PRODUCT BREAKDOWN STRUCTURE A document that lists all of the sub-products required to be completed in order to create the finished outcome of the project


155

PRODUCT DESCRIPTION Document that contain the purpose, composition, specifications, quality criteria, tolerance levels, and acceptance criteria for any given product. PRODUCT STATUS ACCOUNT A report in configuration management that contains the status of one or more products PROGRESS A theme that is concerned with establishing mechanisms for monitoring and comparing the actual versus planned achievements within a project PROJECT Temporary organization that is created for the purpose of delivering one or more business products according to an agreed upon business case PROJECT ASSURANCE The role responsible for making sure that the project manager is properly performing their job and to assure the project board that everything is running smoothly PROJECT BOARD Team consisting of the executive, senior user, and senior supplier that oversees the project manager during a project PROJECT INITIATION DOCUMENT (PID) Document (product) that is used by the project board to determine the project’s viability to continue to the next stage by providing an outline of all major tasks that need to be completed during a given stage PROJECT ISSUE An actuality that must be dealt with during the project, such as when a negative risk has been actualized


156

PROJECT MANAGER The person who performs the work and is responsible for the day-to-day project management activities as well as reporting progress up to the project board PROJECT MANAGEMENT Practice of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and to meet specific success criteria within a specified timeframe PROJECT PLAN A broad plan created by the project board which specifies the timeline, overall cost, and number of stages in a project PROJECT PRODUCT DESCRIPTION A document that defines exactly what the product must deliver PROJECT SUPPORT The role that assists the project manager and team managers with daily administration, report generation, progress monitoring, and other necessary tasks QUALITY A theme in PRINCE2® that defines and implements the mechanisms in the project to determine if the products are fit for purpose and if the project can provide the benefits which the customer expects QUALITY ASSURANCE A role that seeks to determine if a project is complying with the corporate standards, policies and procedures QUALITY CONTROL A process to determine is the result or end product of a project meets a sufficient level of quality to be considered acceptable QUALITY MANAGEMENT APPROACH Documents the method of quality control that will be used inside of the project


157

QUALITY MANAGEMENT SYSTEM System that contains the quality products, policies, procedures, and standards expected within the organization QUALITY REGISTER A document that is used to summarize all of the quality management activities that are planned or have taken place QUALITY RECORD Documentation of the details of any quality tests performed on a product during a project REQUESTS FOR CHANGE A formal request to make an addition, modification, or deletion to the baseline REQUIREMENTS DOCUMENT Document that contains the purpose, composition, specifications, quality criteria, tolerance levels, and acceptance criteria for any given product; also known as a product description RISK A theme that seeks to identify, assess, and control uncertainty in order to improve the likelihood of the project’s success RISK APPETITE The level of risk that an organization is comfortable with accepting during a project RISK BUDGET A dedicated amount of money that is controlled by the project manager in order to fund actions necessary to respond to the realization of an unexpected risk RISK MANAGEMENT APPROACH A document created during the project initiation stage that details how risk will be managed in the project


158

RISK TOLERANCE The risk threshold that must not be exceeded without submitting an exception report to the next higher level of management SENIOR USER Role that represents the end user’s needs in the creation of the project’s final product; Role can be fulfilled by a singular person or multiple people SENIOR SUPPLIER Role that represents the people or organizations that will be designing, developing, and implementing the project’s outcome or final product; Role can be fulfilled by a singular person or multiple people STAGE BOUNDARY Marks the end of the current stage and requires a Go/No-Go decision to be made by the project board prior to starting the next stage of the project STAGE PLAN A detailed plan created by the project manager that provides more detail than a project plan STAKEHOLDER Any person or organization that has an interest in the outcome of the project STARTING UP A PROJECT A process that takes place prior to the project commencing and is designed to determine if an idea should become a project; is it viable, achievable, and desirable? SUNK COST ANALYSIS An analysis where the amount of money spent to date on a project is not considered in determining the viability or desirability of finishing the project; only further spending is considered


159

TAILOR TO SUIT THE PROJECT ENVIRONMENT A principle that states that a project should be adapted, scaled, and modified based on the size, scope, and complexity of a given project TEAM MANAGER A role that serves beneath the project manager in the organization structure and manages the specialists with the required skills to design, enable, and produce the specified products desired in the project TEAM PLAN An optional plan created by the team manager providing incredible detailed plans or work packages TOLERANCE An agreed upon variation to a set value or set point


160

ALSO AVAILABLE FROM

www.DionTraining.com

ITIL® Foundation: Your Complete ITIL Exam Prep This course is your complete guide to all 26 processes and functions covered by the ITIL® Foundation certification exam. If you are interested in learning more about IT Service Management, this is the course for you! You will pass the exam on your first attempt IF you follow our methods and study using this course. Join us and get ITIL® certified! ITIL® Foundation: Practice Certification Exams This course gives you 6 full-length practice exams to prepare for the ITIL® Foundation certification exam. If you want to practice the exam before you spend hundreds of dollars for the certification exam fee, this is the course for you! Each exam is timed for 60 minutes and has 40 questions (just like the ITIL® Foundation). Every question comes complete with the explanation, making it a great learning tool! CompTIA CySA+ (CS0-001): Course & Practice Exam In this course, you will receive over 10 hours of video that teach you everything that you need to know to take and pass the CompTIA CySA+ certification exam, including a full-length practice exam. This course is simply outstanding. Check out the reviews from previous students, if you want to pass the CySA+ certification, join this course! CompTIA Network+ Certification: Course & Practice Exam This course teaches you everything you need to know to pass the Network+ certification exam, complete with 8.5 hours of lecture and hundreds of practice questions. This course is the key to your success in passing the exam How to Pass IT Certifications with Strategic Test Taking Learn "how to study" for certification exams and understand how to pick the right answers come test day. Now, I know that sounds simple, but there is a method to this that many students don't know. You will learn how to study better, take more efficient notes, and most importantly, increase your odds of passing your exams.

Visit http://www.DionTraining.com for more details! Follow us on Facebook: JasonDionTraining Subscribe on YouTube: JasonDionTraining


161

www.DionTraining.com

PRINCE2® Foundation: Cram to Pass In this 3-hour video course, you will review everything covered in this book. This course is designed to get you ready to take and pass the PRINCE2® Foundation certification exam in the next 7 days! This online video course also comes with 480 practice exam questions to ensure you are ready come test day! In just 30-60 minutes a day, you will be ready to conquer the exam on your first attempt!

PLEASE REGISTER YOUR BOOK TODAY TO RECEIVE FREE ACCESS TO THE ACCOMPANYING

CRAM TO PASS VIDEO COURSE AT https://www.DionTraining.com/pages/prince2cram

For more details, visit http://www.DionTraining.com.


162

ABOUT THE AUTHOR

Jason Dion, is an Adjunct Assistant Professor at the University of Maryland University College and an Adjunct Instructor at Liberty University’s College of School of Business and Anne Arundel Community College’s Department of Computing Technologies. He holds numerous information technology professional certifications, including Certified Information Systems Security Professional (CISSP), Cybersecurity Analyst+ (CySA+), CyberSec First Responder (CFR), Certified Ethical Hacker (CEH), Certified Network Defense Architect (CNDA), Digital Forensic Examiner (DFE), Digital Media Collector (DMC), Security+, Network+, A+, ITIL® Foundation, and PRINCE2® Practitioner. With networking experience dating back to 1992, Jason has held positions as an IT Director, Deputy Director of a Network Operations Center, Network Engineer, and many others. He holds a Master of Science degree in Information Technology with a specialization in Information Assurance from University of Maryland University College, a Master of Arts and Religion in Pastoral Counseling from Liberty University, and a Bachelor of Science in Human Resources Management from New School University. He lives in the greater Washington D.C./Baltimore, Maryland area with his wife and two children.