Appendix B

Glossary of the Main PRINCE2 Terms

Acceptance Criteria. Set down in the Project Product Description, these are measurable factors used to decide whether or not to accept the project. This sounds strict, and sometimes it is, to the point of being the base of a legal contract. But in many cases you don’t refuse the project because it doesn’t meet some criteria, but you must certainly discuss these criteria. Please see Chapter 14 for more on the whole area of product planning and the Project Product Description.

Activity. Something you do on the project which is recorded in the activity plans. But activities are also the name given to the list of suggested things you do in each of the seven PRINCE2 Processes.

Activity Plans. These plans show what activities you need to build the products. PRINCE2 doesn’t specify what techniques you use for activity planning, but most people use activity networks and Gantt charts. You do activity planning at all three levels of planning detail in PRINCE2 – project, stage, and team plans.

Administrator. A role in a Quality Review. This person helps set up the review meeting and then keeps notes of any errors found in the product under review.

Approval. This is an acceptance of a product (deliverable) that may in turn authorise action. For example, when the Project Board approves a Stage Plan, it is giving the Project Manager permission to start work on the next Management Stage on the basis of that plan. Specialist products must be approved too, often by those who are testing the products and signing them off as correct, but sometimes it needs authority beyond that for formal approval.

Assurance. Basically an audit function. For the auditing done inside the project, please see Project Assurance. For auditing done by the organisation – outside the project – please see Quality Assurance.

Baseline. This term is used in two senses, both to do with Configuration Management or version control. First, any project product that has been quality checked and signed off is said to be ‘baselined’. This is significant, because after this point any change to the product is done under change control. Some of the PRINCE2 management products, such as the Business Case, are defined as ‘baseline management products’ because if you change them then you need to keep track of that. The other use of the term identifies a set of products of known versions that you then handle together. They form a baseline, or if you’re in a computer development environment you may call them a ‘release’.

Benefit. A good result of doing the project, such as a cost saving or faster delivery to customers. PRINCE2 says that benefits must be measurable, but most people recognise than non-quantifiable benefits are not only real but can be extremely important too. Please see Chapter 11 for more on this.

Benefits Review Plan. Sometimes benefits can come on-stream in the project, not just at the end of the project or after it. The Benefits Review Plan sets down when benefits should be measured, who should do it and when.

Business Case. This document is the justification for the project and incorporates the business benefits that the project brings. The Business Case may be provided on the Project Mandate, but if not, is first developed in Start Up. After this it is kept up to date throughout the project – making it a ‘living document’. The Project Board refer to it at all key decision points to ensure that the project is still viable and worth continuing with.

Change Authority. A group or person with the authority to approve changes, at an intermediate level of authority between the Project Board and the Project Manager. One use of it is to speed things up in a fast-moving project where getting a change decision from the Project Board takes too long. Beware of bureaucracy though. Please see Chapter 16 for more detail.

Change Budget. An amount of money given to a Project Manager to fund changes without having to go back to the Project Board or Change Authority. This can be controlled by setting an overall amount, or an overall amount plus a cap on the cost of any individual change.

Change Control. This set of procedures makes sure that things cannot be changed without proper consideration. With change control, a change may be refused or agreed, but if agreed, then care is taken to make sure that the time and resources are given to implement the change – unlike scope creep, where the project is supposed to absorb the change somehow. How change control is done in the project is set down in the Configuration Management Strategy. See Chapter 16 for more detail on managing project change.

Checkpoint (Checkpoint Meeting). A progress measuring point for a team working on a Work Package, this often takes the form of a Checkpoint Meeting, where the Team Manager gets together with the team to discuss progress and any problems, and to look at the work in the next period. As a result of the meeting, the Team Manager usually gives a progress report (the Checkpoint Report) to the Project Manager.

Checkpoint Report. A progress report from a Team Manager to the Project Manager that gives information on how work is progressing on a Work Package. Each individual Work Package specifies the frequency and exact content of this report, allowing the Project Manager to vary it from one Work Package to another.

Communication Management Strategy. A plan developed in the Initiation Stage and which then forms part of the Project Initiation Document (PID). The strategy outlines project communications and so helps thinking communications through to make sure that they’re both complete and sensible. Over-communication is as much of a problem, or even more, than under-communication, so this thinking is important. The strategy lists the information that moves around (such as progress information), who produces it, who receives it, and when and how it will be communicated. A particular communication may be verbal, such as a phone call.

Concession. This means accepting a product that’s off-specification. Normally, if a product is found to be off-spec when it’s tested, it’s re-worked until it passes the test and meets its specified quality criteria. But if for some reason achieving this is difficult or even impossible, or it causes other problems such as unacceptable delay to the project, then the best thing may be to make a concession and accept the product as it is. That’s not good, but better than the impact of correction. The PRINCE2 manual says that only the Project Board can authorise a concession, but for some very technical projects that’s debatable, as Chapter 16 discusses.

Configuration Management (CM). This is basically version control or versioning. CM covers the control of management products that are likely to go through more than one version and also most specialist products. It includes holding information about products and why changes occurred (change history), as well as version information. The way that Configuration Management will be done in the project is decided in the Initiation Stage and recorded in the project’s Configuration Management Strategy that goes on to form part of the Project Initiation Document (PID).

Configuration Management Strategy (CM Strategy). The Project Manager produces this strategy, often with the advice of Project Support and specifically any person within Project Support who specialises in configuration management. The Configuration Management Strategy sets down the procedures for managing change in the project, including the version control procedures. The CM Strategy forms part of the Project Initiation Document (PID) and is maintained throughout the project.

Contingency. PRINCE2 no longer uses this term and instead refers to fall back. There is more on this in Chapter 15 on risk.

Daily Log. This log, set up in Start Up, is effectively the Project Manager’s diary but Team Managers can use Daily Logs as well. It can save on documentation because its simple notes help avoid more formal and lengthy communications. If the Project Manager decides that an Issue or risk does not need to be formally managed, the details can be recorded in the Daily Log rather than in one of the registers. The Daily Log is also a ‘catch-all’ for any information that other PRINCE2 management products don’t cover.

Deliverable. See Product.

Dis-benefit. A disadvantage of running the project, such as disruption to business operations while building work is carried out. Unlike a risk that might happen, a dis-benefit concerns an effect that will happen.

Embedding. Adjusting PRINCE2 to fit the needs of the organisation for all of its projects. Adjustments within that to meet the needs of individual projects is called tailoring.

End Project Report. The Project Manager produces this report at the end of the project and presents it to the Project Board. It’s the Project Manager’s assessment of how well the project went and to what extent it met the objectives set down in the Project Initiation Document.

End Stage Assessment (ESA). At the planned end of a management stage the Project Board attend this meeting to review the completed stage, check that the project is still viable against its Business Case, check that the risk is still acceptable, and then give approval for the next stage on the basis of its Stage Plan. The board always have an option to close the project instead of authorising the next stage.

End Stage Report. The Project Manager produces this report at the end of each management stage. The report focuses on how the stage ran, and covers things like the final cost, final time, delivery of quality, and any problems that are likely to flow through to the next management stage. Like other reports, the End Stage Report doesn’t necessarily have to be written. The Project Manager can present it to the Project Board verbally, and the details can then be noted in the record of the meeting.

Event driven. This is one of two categories of control, the other being time driven. An event-driven control is one that is fixed to a particular event, so if that event is delayed or doesn’t happen the control will be late or won’t kick in. An example is an End Stage Assessment (ESA) which is fixed to the end of a stage. If the stage finishes early, the ESA will also be early.

Exception. This is the state when a Work Package, stage, or project is projected to finish outside the tolerances set for it. PRINCE2 works on an Exception Management principle: All the time the work goes to plan there’s relatively little to communicate between control points apart from progress confirmation. But if it’s projected that the project is going significantly off the plan (‘significantly’ meaning outside the specified tolerances) then the fact must be reported immediately. At stage or project level, this is usually done using an Exception Report. This control mechanism isn’t only sensible and practical; at stage level it can save considerable Project Board time. Chapter 17 has a full explanation.

Exception Assessment. This is when the Project Board meet to consider an Exception Plan. This meeting is very like an ordinary End Stage Assessment, but is a forced stage boundary where you have to completely re-plan the remainder of a stage because of an exception or the need to accommodate a major change.

Exception Management. See Exception.

Exception Plan. This is a plan used after an exception. When corrective work, or additional work required to accommodate a major change, substantially changes things, then the existing plan won’t be usable any more. If this happens to a stage, it triggers a stage boundary. The work done so far in the stage is closed down and reported with an End Stage Report; there’s no point in re-planning what’s already completed. An Exception Plan is used to re-plan the remainder of the stage from this point until the end of the stage. The Exception Plan may have a knock-on effect on other plans, notably the Project Plan, and if so, then that revised plan is also included in the Exception Plan.

Exception Report. The Project Manager uses this report to inform the Project Board that a stage is now projected to finish outside a specified limit (tolerance). The report could be verbal, such as a phone call.

Executive. This is a role on the Project Board and the person who takes this role represents the business viewpoint, which means primarily thinking about value for money. This role may not be shared, so a project can only ever have one Executive. Also, the Executive must be a person, so a committee can’t act as the Executive. Although the whole of the Project Board own the project and are responsible for it, ultimately it’s the Executive’s project. The Executive always chairs board meetings and is the ultimate owner of the project. Some still refer to this role as Project Executive to avoid confusion with other executive roles in the management of the organisation.

Follow-On Action Recommendations. At the end of the project, the Project Board may recommend that the organisation does some things after the project has shut down. The recommendations can include good ideas generated during the project but where there was not enough time or resources to implement them, and suggestions for changing project management standards as a result of experience gained during the project.

Highlight Report. The Project Manager gives this regular progress report to the Project Board. The contents and the frequency of the Highlight Report are set down in the Communication Management Strategy. The report may also go to other interested parties, notably to programme management if the project is part of a programme.

Initiation Stage (Initiation). This is the first stage of any PRINCE2 project and is devoted solely to project planning. The main deliverable of this stage is a package of plans called the Project Initiation Document. At the end of the Initiation Stage, the Project Board decides whether or not to commit to the whole project with the intention of running it through to the end.

Issue. This is a direct communication from anyone in the project from the Executive through to the most junior team member, straight to the Project Manager – the PRINCE2 manual suggests it can be from anyone with an interest in the project. A project Issue can be about anything to do with the project and it can be submitted at any time. So, quite flexible then. There are three sub-types of Issue which are Problem/concern, Request for Change and Off-Specification. Issues that are to be tracked formally are recorded on an Issue Report and then in the Issue Register. Issues to be informally controlled are recorded in the Daily Log.

Issue Register. A control document set up during Project Initiation in order to track all Project Issues that are to be formally managed. The Issue Register records information such as who submitted each Issue and its current status.

Issue Report. A record made by the Project Manager when an Issue is received.

Lessons Log. As the name suggests, this log records lessons learned from this project that may help improve the management of future projects but it also notes lessons from previous projects (and other sources) which may be of help in this project. The Lessons Log is closed and turned into a Lessons Report at the end of the project.

Lessons Report. This is produced from the Lessons Log at the end of the project. But more frequent reporting is possible if significant lessons need to be passed back into the organisation before the end of the project, such as end stage. The report is stored somewhere accessible (such as a Project Office) so that Project Managers can easily check it for advice for future projects. The Lessons Report is a very positive document, not a post-mortem report that focuses on bad news and whose fault the problems were. The report records problems and how they can be avoided in the future, but also contains information on what worked really well in the project that may benefit future ones.

Logs. These are informal records and there are two; the Daily Log and the Lessons Log. Things that need more formal control are recorded in registers.

Management products. These are the products that you use to manage the project. The Project Initiation Document, Risk Log, and Business Case are examples of management products. See also Product.

Management stage. Project stages in PRINCE2 are management stages and not technical stages. A management stage is a block of work that the Project Board authorise the Project Manager to do before coming back to them for approval to do the next management stage. You may have several technical stages within a single PRINCE2 management stage. The stage boundaries form powerful control points for the Project Board and are the single most important control in the method. The Project Manager can’t start work on the next stage until the board has given permission by authorising the Stage Plan.

Milestone. This is a progress measuring point. PRINCE2 For Dummies strongly recommends, contrary to the PRINCE2 manual, that all stage-level products should be used as milestones. Chapter 14 explains why.

Off-Specification (Off-Spec). This is a sub-type of Issue used when a product fails to meet the quality criteria on its Product Description and can’t easily be corrected. An Off-Spec can also be used in advance of a test if a team can see that a product isn’t going to meet its required quality criteria. The resolution may be to accept the product in this state as a concession, or authorise a more substantial re-working of the product, which may then involve altering the plans to accommodate the extra time and resources needed. Chapter 16 covers Project Issues, Off-Specs, and concessions.

Outcome. The use of the project’s deliverables or ‘output’ (see next item) to bring about a change. So, the project may deliver new tools, and the outcome is that production work can be done faster and capacity is thereby increased. In turn, this outcome may lead to the benefits of increased sales through lowered prices and so to increased profitability of the manufacturing plant.

Output. The products or deliverables generated in the project.

Phase. Some non-PRINCE2 project management approaches and planning tools use this term to mean a section of the project. The PRINCE2 equivalent is management stage.

Presenter. One of the roles in a Quality Review, this is the person or people who understand the product that the review meeting checks.

Principle. One of the seven things that the method suggests you should be doing in order to claim that your project is being run under PRINCE2. Principles include things such as defined roles and responsibilities and using the exception management principle. You will find more on them in Chapter 2.

Process. Part of PRINCE2 which indicates when things should be done in a project. Each process has a number of suggested activities. There are seven processes and these are covered in Section II of this book.

Product or Project Product. Things that are being produced in the project – the deliverables. The two categories of product in PRINCE2 are management products and specialist products. The management products are things like the Risk Register and Project Initiation Document that are being used to manage the project. The specialist products are mostly what the team build, although a few may be obtained from outside the project. For specialist products, PRINCE2 incorporates a very powerful product-led, or product-based, planning approach. Chapter 14 has full details.

Product Breakdown Structure (PBS). This is one of the diagrams used in product-led planning. The PBS is a hierarchical diagram and is useful when thinking through what products you need to build. You group products in categories, which helps you think through the whole project systematically. Chapter 14 contains information about this diagram and how to use it.

Product Checklist. This is a simple but very powerful progress monitoring tool. The checklist provides unambiguous milestones during each stage and records what products will be produced in the stage together with their target and actual delivery dates. The Product Checklist can also be used at team level to monitor progress on building the products in a Work Package.

Product Description. A form that defines a particular product and sets down related information, such as how that product will be tested. The description is part of the product-led planning approach explained in Chapter 14. Take great care when writing Product Descriptions because this is largely a thinking exercise; it’s not a form-filling one.

Product Flow Diagram. This diagram shows the sequence in which you produce the deliverables or products. It’s extraordinarily powerful and is a part of the product-led planning approach that Chapter 14 explains.

Product-led planning (Product-Based Planning). A powerful ‘front end’ to the more traditional activity planning approach. Product-led planning sets out to understand the nature of what the project is to produce (products) before trying to establish what needs to be done to produce them, what resources are needed, and how long the project may take. It also opens the way to particularly effective progress monitoring and quality management. Chapter 14 describes product-led planning and the associated techniques.

Product Plans. PRINCE2 uses product planning alongside activity plans and resource planning, but the products are planned first – a product-led planning approach. Product plans are used at all three levels of detail of planning in the method: Project Plans, Stage Plans, and Team Plans. Please see Chapter 12 for the full detail.

Product Status Account. A report giving the current status of a set of products, such as all of the products being developed in the current stage. Status settings may show things such as ‘under construction’, ‘ready for test’, and ‘delivered’.

Programme. This is the name given to a group of projects that you need to manage together in order to co-ordinate them. For example, perhaps all the projects need to finish at the same time or they have significant inter-dependencies. PRINCE2 does not cover programme management, but being part of a programme affects the way you set up a PRINCE2 project. For example, the Project Plan may have to fit in with the programme plan.

Project and Programme Office (PPO). When the project is part of a programme, you may centralise the administrative support at project level and programme level in a PPO that serves both levels.

Project Approach. You develop this management product in Start Up and then maintain it throughout the project. The Project Approach sets down things that affect how you plan and run the project and things that constrain the project outcome, such as legal requirements, the type of staff you use on a project (perhaps solely contractors or solely customer staff), and security requirements.

Project Assurance. This role performs an audit function in the project. The Project Board members may do their own assurance or they may appoint one or more other people to do it on their behalf and report back. Project Assurance isn’t optional and must be independent of the Project Manager.

Project Board. This comprises a group of senior managers (relative to the project) who own the project and are responsible for it. The board incorporates three roles: Executive, Senior User, and Senior Supplier. You can have fewer than three people on the board if a board member fulfils more than one role, or you can have more than three if people share roles but boards of more than six tend to give problems. The board isn’t a voting democracy and other board members can’t outvote the head, the Executive.

Project Brief. The Project Brief is like a sketch of the project idea. It’s a short document produced in Start Up and so before the project begins. The Project Board use the information in the brief to decide whether starting the project and doing the full project planning in an Initiation Stage is worthwhile.

Project Executive. Please see Executive.

Project Initiation Document (PID). You produce this key PRINCE2 document during Initiation and it defines the project and exactly how you manage it. Although the PID is a single document you can think of it as like a folder containing many other plans and documents such as the Business Case, Project Plan, Risk Log, Project Organization, and Project Quality Plan.

Project Issue. Please see Issue.

Project Management Strategy. A document that sets down the level of quality required in the project, how it will be delivered, and who’s responsible for making sure that the project delivers quality. The strategy forms part of the Project Initiation Document and is maintained throughout the life of the project.

Project Management Team. This comprises all the management roles in PRINCE2 with the addition (rather strangely) of Project Support, which actually doesn’t do any management. The roles are the Project Board roles of Executive, Senior User, and Senior Supplier, and then Project Assurance, Change Authority, Project Manager, Team Manager, and Project Support. The concept of the Project Management Team underpins the important point that the team are ‘in this together’. For example, the Project Board can’t just delegate the whole project to the Project Manager and walk away.

Project Management Team Structure. The document showing the Project Management Team for the project, often in the form of an organisation chart.

Project Manager. This manager runs the project on a day-to-day basis on behalf of the Project Board and is accountable to the board. The board decide the amount of responsibility and authority the Project Manager has. In turn, the Project Manager may have one or more Team Managers reporting to her.

Project Mandate. Programme or corporate management produces this document, which contains high-level information about the project idea. The mandate is the trigger that starts PRINCE2 off and names the project’s Executive, at least, but often the Project Manager as well.

Project Office. An office that centralises Project Support for all the organisation’s projects in order to give enhanced expertise and also economy of scale. A very large project may be big enough to justify its own office. When the organisation runs one or more programmes, an option is to combine the support at both levels in a Project and Programme Office.

Project Plan. This is the high-level plan of the whole project from the end of the Initiation Stage to the end of the project i.e. the delivery stages. It contains product plans, activity plans, and resource plans, together with textual explanation and financial planning.

Project Support. This is primarily administrative support to the Project Manager and Team Managers. However, Project Support can also function in an advisory capacity. Project Support may be provided in a number of different ways, from a centralised Project Office to a personal assistant given to each Project Manager to provide admin support. On smaller projects especially, the person who is the Project Manager may also do her own administration and so have a second role of Project Support.

Project Support Office (PSO). The name formerly given by PRINCE2 to the Project Office. PRINCE2 has now aligned with other project approaches.

Quality Assurance. A check or audit from outside the project to ensure that it is being run properly and that information about it is correct. Quality assurance is independent of the project, including independent from the Project Board. This is unlike Project Assurance which is the responsibility of the Project Board and is only independent of the Project Manager.

Quality Control. The testing or checking of something to check if it meets its quality criteria as specified on its Product Description and any further standards that the Product Description refers to.

Quality Register. This lists the quality activities, including tests and checks, to be done in each stage (entered when the Stage Plan is built) and then the results of those activities. It forms a simple but very powerful audit trail to ensure that no planned test is missed out. If a test hasn’t been done then the Quality Register makes that obvious because the entry isn’t signed off. The register is checked frequently.

Quality Review (Quality Walkthrough). A technique in the form of a meeting held to check a product. This technique is used mostly to check paper-based products such as reports and specifications.

Registers. Control documents used by the Project Manager for things that are to be formally managed. The logs are for things to be informally managed. There are three registers in PRINCE2; Risk, Issue and Quality.

Request for Change (RFC). A sub-type of project Issue, an RFC is used when a change is wanted to a product that has already been baselined (signed off). After a product has been quality checked and baselined, any change to it must be controlled or quality is completely undermined.

Resource plans. These set down who performs activities to build products and when, but you can use them to schedule physical resources (such as equipment) as well as human resources. PRINCE2 doesn’t cover this area and expects users of the method to look up information in other project management sources. However, PRINCE2 For Dummies gives you a bit of information in Chapter 14. Computer tools for activity planning usually include facilities for resource planning, but they’re generally rather limiting. Project Managers of projects of any size use the software for activity planning, but then often turn to a spreadsheet to do resource planning.

Reviewer. One of the roles in a Quality Review, this person checks whether the product is correct and meets its specified quality criteria.

Risk Actionee. Someone who is appointed to take action on a particular risk. This may or may not be the same person who is that risk’s Owner.

Risk Management. The work involved in identifying, analysing, and managing risks in the project. Each identified risk is entered into the Risk Log. Risk management is important in PRINCE2 and is built into the method. Chapter 15 gives full information.

Risk Owner. A person appointed to monitor and control a particular risk. This may be outside of the project. For example, some risks may be ‘owned’ by programme management or corporate risk management even though it is recorded in the project because it has particular implications for the project.

Risk Register. This register, opened in Initiation, records all the risks in the project that are to be formally managed, along with key information on each one, such as the probability of something happening, the impact if it does, and what actions are being taken to limit the possibility. The register is kept up to date throughout the project and reviewed systematically at the end of each management stage so that the Project Board can see the very latest position on risk when deciding whether or not to authorise the next stage in the project.

Role. This is an important term in the context of the Project Organisation Structure and is a key to flexible use of the method. With two exceptions (Executive and Project Manager) more than one person can share a role. Equally, one person, again with some limitations, can have more than one role. This gives considerable flexibility when applying the method, including using it on small projects that involve very few people.

Senior Supplier. This role on the Project Board represents the supplier viewpoint of the project. One or more managers who provide the teams that build the project’s products fill this role. They’re on the board to be sure that the project delivers something realistic and workable and to authorise the team resources. One or more people from outside the customer organisation may fill this role where external suppliers provide one or more teams on the project. For more information please see Chapter 12.

Senior User. This Project Board role represents the user viewpoint. One or more managers fill the role and represent those who use what the project delivers. They ensure that the project deliverables are suitable and fit for purpose, they provide user resources (such as to help specify requirements) and they also specify the business benefits that will result from running the project and are then responsible for delivering those benefits. For more information on this role, go to Chapter 12.

Specialist Product. The specialist products are the deliverables of the project that are not management products (such as the Risk Register). PRINCE2 classifies these in two ways: the internal or team products that project teams produce, and external products that come over the project boundary from outside the project.

Sponsor. This isn’t a PRINCE2 term or concept. The PRINCE2 equivalent is somewhere between the project Executive and Senior User on the Project Board. Chapter 12 tells you more about these roles.

Stage. See Management stage.

Stage boundary. At a stage boundary one management stage finishes and another one starts. The Project Board decides the stage boundaries during Initiation, because these are the board’s control points. An additional stage boundary can occur if a stage goes significantly off its plan, goes into exception, and then requires an Exception Plan. That exception planning triggers a stage boundary that you didn’t originally plan; this new stage boundary is reactive and part of the handling of the exception. The board meeting at an originally planned stage boundary is an End Stage Assessment. The board meeting on a reactive stage boundary is an Exception Assessment.

Stage Plan. A plan produced by the Project Manager for a single management stage. Stage Plans are always created at the end of the previous stage except for the Initiation Stage Plan, which is created at the end of Start Up.

Stakeholders. These are individuals or corporate bodies with an interest in the project and its outcome.

Start Up (Starting Up a Project). This part of PRINCE2 happens before the project starts. During Start Up, you produce a Project Brief that provides the information that the Project Board need in order to decide whether going forward to full planning work is worthwhile.

Tailoring. The name given to fitting the PRINCE2 method to a particular project. How this is being done in a project will be recorded in a dedicated section of the Project Initiation Document (PID).

Team Manager. This manager is responsible for a project team, which may be from within the customer organisation or from an external supplier but which is nevertheless under project control. This is the only role in the Project Management Team that’s optional. In a very small project with just one team, the Project Manager may also manage the team.

Theme. The name given in PRINCE2 for advice on how things are done in the project as opposed to the processes which indicate when things should be done. There are seven themes which are covered in Part III of this book.

Time Driven. One of two categories of control, of which the other is event driven. Time-driven controls are at a set frequency. An example is with progress reporting from the Project Manager to the Project Board which is at set intervals, such as every four weeks, right through the project.

Tolerance. PRINCE2 uses this term to mean the limits above and below a specified amount. Project work doesn’t often go exactly to plan to the precise minute and precise penny. So having some flexibility makes sense, or else the Project Board would be called in every five minutes to hear reports of something not going to plan. But the board don’t expect to be told about major problems only late in the day when it’s too late to react. Tolerances can be set for cost and time which are the most common, but also for quality, benefits, scope and risk. If work may finish outside the tolerance band, the fact must be reported to the Project Board immediately. This is an exception and PRINCE2 makes use of Exception Management. Tolerance can be set at project, stage, and Work Package levels. Chapter 17 has more information on this and other controls.

Work Package. The Project Manager gives this instruction pack to the Team Manager. The Work Package asks the Team Manager to produce a product or perhaps more than one, and give instructions on how to do this. Those instructions include things such as how to report problems and how often to submit Checkpoint Reports to report progress. Each team works through a series of Work Packages in each stage.