A.1 Benefits Review Plan
A.1.1 Purpose
A Benefits Review Plan is used to define how and when a measurement of the achievement of the project’s benefits, 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 post-project benefits reviews that are required.
The plan has to cover the activities to find out whether the expected benefits of the products have been realized and how the products have performed when in operational use. Each expected benefit has to be assessed for the level of its achievement and whether any additional time is needed to assess the residual benefits. Use of the project’s products may have brought unexpected side-effects, either beneficial or adverse. Time and effort have to be allowed to identify and analyse why these side-effects were not foreseen.
If the project is part of a programme, the Benefits Review Plan may be contained within the programme’s benefits realization plan and executed at the programme level. Post-project, the Benefits Review Plan is maintained and executed by corporate or programme management.
A.1.2 Composition
The scope of the Benefits Review Plan covering what benefits are to be measured
Who is accountable for the expected benefits
How to measure the achievement of the expected benefits, and when they can be measured
What resources are needed to carry out the review work
Baseline measures form which the improvements will be calculated
How the performance of the project’s products will be reviewed.
A.2 Business Case
A.2.1 Purpose
A Business Case is used to document the justification for the undertaking of a project, based on the estimated costs (of development, implementation and incremental ongoing operations and maintenance costs) against the anticipated benefits to be gained and offset by any associated risks.
The outline Business Case is developed in the Starting up a Project process and refined by the Initiating a Project process. The Directing a Project process covers the approval and re-affirmation of the Business Case.
The Business Case is used by the Controlling a Stage process when assessing impacts of issues and risks. It is reviewed and updated at the end of each management stage by the Managing a Stage Boundary process, and at the end of the project by the Closing a Project process.
A.2.2 Composition
Executive summaryHighlights the key points in the Business Case, which should include important benefits and the return on investment (ROI)
Reasons Defines the reasons for undertaking the project and explains how the project will enable the achievement of corporate strategies and objectives
Business options Analysis and reasoned recommendation for the base business options of: do nothing, do the minimal or do something
Expected benefits The benefits that the project will deliver expressed in measurable terms against the situation as it exists prior to the project. Benefits should be both qualitative and quantitative. They should be aligned to corporate or programme benefits. Tolerances should be set for each benefit and for the aggregated benefit. Any benefits realization requirements should be stated
Expected dis-benefits Outcomes perceived as negative by one or more stakeholders. Dis-benefits are actual consequences of an activity whereas, by definition, a risk has some uncertainty about whether it will materialize. For example, a decision to merge two elements of an organization onto a new site may have benefits (e.g. better joint working), costs (e.g. expanding one of the two sites) and disbenefits (e.g. drop in productivity during the merger). Dis-benefits need to be valued and incorporated into the investment appraisal
Timescale Over which the project will run (summary of the Project Plan) and the period over which the benefits will be realized. This information is subsequently used to help timing decisions when planning (Project Plan, Stage Plan and Benefits Review Plan)
Costs A summary of the project costs (taken from the Project Plan), the ongoing operations and maintenance costs and their funding arrangements
Investment appraisal Compares the aggregated benefits and dis-benefits to the project costs (extracted from the Project Plan) and ongoing incremental operations and maintenance costs. The analysis may use techniques such as cash flow statement, ROI, net present value, internal rate of return and payback period. The objective is to be able to define the value of a project as an investment. The investment appraisal should address how the project will be funded
Major risks Gives a summary of the key risks associated with the project together with the likely impact and plans should they occur.
A.3 Checkpoint Report
A.3.1 Purpose
A Checkpoint Report is used to report, at a frequency defined in the Work Package, the status of the Work Package.
A.3.2 Composition
Date The date of the checkpoint
Period The reporting period covered by the Checkpoint Report
Follow-ups From previous reports, for example action items completed or issues outstanding
This reporting period:
The products being developed by the team during the reporting period
The products completed by the team during the reporting period
Quality management activities carried out during the period
Lessons identified
Next reporting period:
The products being developed by the team in the next reporting period
The products planned to be completed by the team in the next reporting period
Quality management activities planned for the next reporting period
Work Package tolerance status How execution of the Work Package is performing against its tolerances (e.g. cost/time/scope actuals and forecast)
Issues and risks Update on issues and risks associated with the Work Package.
A.4 Communication Management Strategy
A.4.1 Purpose
A Communication Management Strategy contains a description of the means and frequency of communication to parties both internal and external to the project. It facilitates engagement with stakeholders through the establishment of a controlled and bi-directional flow of information.
A.4.2 Composition
Introduction States the purpose, objectives and scope, and identifies who is responsible for the strategy
Communication procedure A description of (or reference to) any communication methods to be used. Any variance from corporate or programme management standards should be highlighted, together with a justification for the variance
Tools and techniques Refers to any communication tools to be used, and any preference for techniques that may be used, for each step in the communication process
Records Definition of what communication records will be required and where they will be stored (for example, logging of external correspondence)
Reporting Describes any reports on the communication process that are to be produced, including their purpose, timing and recipients (for example, performance indicators)
Timing of communication activities States when formal communication activities are to be undertaken (for example, at the end of a stage) including performance audits of the communication methods
Roles and responsibilities Describes who will be responsible for what aspects of the communication process, including any corporate or programme management roles involved with communication
Stakeholder analysis:
Identification of the interested party (which may include accounts staff, user forum, internal audit, corporate or programme quality assurance, competitors etc.)
Current relationship
Desired relationship
Interfaces
Key messages
Information needs for each interested party:
Information required to be provided from the project
Information required to be provided to the project
Information provider and recipient
Frequency of communication
Means of communication
Format of the communication.
A.5 Configuration Item Record
A.5.1 Purpose
To provide a record of such information as the history, status, version and variant of each configuration item, and any details of important relationships between them. The set of Configuration Item Records for a project is often referred to as a configuration library.
A.5.2 Composition
The composition of a Configuration Item Record will be defined in the project’s Configuration Management Strategy.
There follows a suggested list of components for each Configuration Item Record (note that the first three uniquely identify the configuration item):
Project identifier A unique reference. It will typically be a numeric or alpha-numeric value
Item identifier A unique reference. It will typically be a numeric or alpha-numeric value
Current version Typically an alpha-numeric value
Item title The description of the item (for a product this should be as it appears in the product breakdown structure)
Date of last status change
Owner The person or group who will take ownership of the product when it is handed over
Location Where the item is stored
Copy holders (if relevant) Who currently has the product?
Item type Component, product, release (see section 9.2.2)
Item attributes As defined by the Configuration Management Strategy. These are used to specify a subset of products when producing a Product Status Account, such as the management stage in which the product is created, the type of product (e.g. hardware/ software), product destination etc.
Stage When the product will be developed
Users The person or group who will use the item
Status As defined by the Configuration Management Strategy, e.g. pending development, in development, in review, approved or handed over
Product state (if used) As defined by the Product Description, e.g. dismantled machinery, moved machinery, reassembled machinery (see section 7.3.3.2)
Variant (if used) for example, language variants
Producer The person or team responsible for creating or obtaining the item
Date allocated To the producer
Source For example, in house, or purchased from a third-party company
Relationship with other items Those items that:
Would be affected if this item changed
If changed, would affect this item
Cross-references:
Issues and risks
Documentation that defines requirements, design, build, production and verification for the item (specifically this will include the Product Description).
A.6 Configuration Management Strategy
A.6.1 Purpose
A Configuration Management Strategy is used to identify how, and by whom, the project’s products will be controlled and protected. It answers the questions:
How and where the project’s products will be stored
What storage and retrieval security will be put in place
How the products and the various versions and variants of these will be identified
How changes to products will be controlled
Where responsibility for configuration management will lie.
A.6.2 Composition
Introduction States the purpose, objectives and scope, and identifies who is responsible for the strategy
Configuration management procedure A description of (or reference to) the configuration management procedure to be used. Any variance from corporate or programme management standards should be highlighted, together with a justification for the variance. The procedure should cover activities such as planning, identification, control (including storage/retrieval, product security, handover procedures etc.), status accounting, and verification and audit.
Issue and change control procedure A description (or reference to) the issue and change control procedures to be used. Any variance from corporate or programme management standards should be highlighted, together with a justification for the variance. The procedure should cover activities such as capturing, examining, proposing, deciding and implementing.
Tools and techniques Refers to any configuration management systems or tools to be used and any preference for techniques that may be used for each step in the configuration management procedure
Records Definition of the composition and format of the Issue Register and Configuration Item Records
Reporting Describes the composition and format of the reports that are to be produced (Issue Report, Product Status Account), their purpose, timing and chosen recipients. This should include reviewing the performance of the procedures
Timing of configuration management and issue and change control activities States when formal activities are to be undertaken, for example configuration audits
Roles and responsibilities Describes who will be responsible for what aspects of the procedures, including any corporate or programme management roles involved with the configuration management of the project’s products. Describes whether a Change Authority and/or change budget will be established.
Scales for priority and severity For prioritizing requests for change and off-specifications and for determining the level of management that can make decisions on severity of issue.
A.7 Daily Log
A.7.1 Purpose
A Daily Log is used to record informal issues, required actions or significant events not caught by other PRINCE2 registers or logs. It acts as the project diary for the Project Manager.
It can also be used as a repository for issues and risks during the Starting up a Project process if the other registers have not been set up.
There may be more than one Daily Log as Team Managers may elect to have one for their Work Packages, separate from the Project Manager’s Daily Log.
A.7.2
A Daily Log is in free form but likely to include:
Date of entry
Problem, action, event or comment
Person accountable
Target date
Results.
A.8 End Project Report
A.8.1 Purpose
An End Project Report is used during project closure to review how the project performed against the version of the Project Initiation Documentation used to authorize it. It also allows the:
Passing on of any lessons that can be usefully applied to other projects
Passing on of details of unfinished work, ongoing risks or potential product modifications to the group charged with future support of the project’s products in their operational life.
A.8.2 Composition
Project Manager’s report Summarizing the project’s performance
Review of the Business Case Summarizing the validity of the project’s Business Case:
Benefits achieved to date
Residual benefits expected (post-project)
Expected net benefits
Deviations from the approved Business Case
Review of project objectives Review of how the project performed against its planned targets and tolerances for time, cost, quality, scope, benefits and risk. Review the effectiveness of the project’s strategies and controls
Review of team performance In particular, providing recognition for good performance
Review of products:
Quality records Listing the quality activities planned and completed
Approval records Listing the products and their requisite approvals
Off-specifications Listing any missing products or products that do not meet the original requirements, and confirmation of any concessions granted
Project product handover Confirmation (in the form of acceptance records) by the customer that operations and maintenance functions are ready to receive the project’s product
Summary of follow-on action recommendations Request for Project Board advice about who should receive each recommended action. The recommended actions are related to unfinished work, ongoing issues and risks, and any other activities needed to take the products to the next phase of their life
Lessons Report (see section A.15) A review of what went well, what went badly, and any recommendations for corporate or programme management consideration (and if the project was prematurely closed, then the reasons should be explained).
A.9 End Stage Report
A.9.1 Purpose
An End Stage Report 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 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: for example, authorize the next stage, amend the project scope, or stop the project.
A.9.2 Composition
Project Manager’s report Summarizing the stage performance
Review of the Business Case Summarizing the validity of the project’s Business Case:
Benefits achieved to date
Residual benefits expected (remaining stages and post-project)
Expected net benefits
Deviations from approved Business Case
Aggregated risk exposure
Review of project objectives Review of how the project has performed to date against its planned targets and tolerances for time, cost, quality, scope, benefits and risk. Review the effectiveness of the project’s strategies and controls
Review of stage objectives Review of how the specific stage performed against its planned targets and tolerances for time, cost, quality, scope, benefits and risk
Review of team performance In particular, providing recognition for good performance
Review of products:
Quality records Listing the quality activities planned and completed in the stage
Approval records Listing the products planned for completion in the stage and their requisite approvals
Off-specifications Listing any missing products or products that do not meet the original requirements, and confirmation of any concessions granted
Phased handover (if applicable) Confirmation by the customer that operations and maintenance functions are ready to receive the release
Summary of follow-on action recommendations (if applicable) Request for Project Board advice for who should receive each recommended action. The recommended actions are related to unfinished work, ongoing issues and risks, and any other activities needed to take the products handed over to the next phase of their life
Lessons Report (if appropriate) (see section A.15) A review of what went well, what went badly, and any recommendations for corporate or programme management consideration
Issues and risks Summary of the current set of issues and risks affecting the project
Forecast The Project Manager’s forecast for the project and next stage against planned targets and tolerances for time, cost, quality, scope, benefits and risk.
Where the End Stage Report is being produced at the end of the initiation stage, not all of the above content may be appropriate or necessary.
A.10 Exception Report
A.10.1 Purpose
An Exception Report is produced when a Stage Plan or Project Plan is forecast to exceed tolerance levels set. It is prepared by the Project Manager in order to inform the Project Board of the situation, and to offer options and recommendations for the way to proceed.
A.10.2 Composition
Exception title An overview of the exception being reported
Cause of the exception A description of the cause of a deviation from the current plan
Consequences of the deviation What the implications are if the deviation is not addressed for:
The project
Corporate or programme management
Options What are the options that are available to address the deviation and what would the effect of each option be on the Business Case, risks and tolerances
Recommendation Of the available options, what is the recommendation, and why?
Lessons What can be learned from the exception, on this project or future projects.
A.11 Highlight Report
A.11.1 Purpose
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. The Project Board uses the report to monitor stage and project progress. The Project Manager also uses it to advise the Project Board of any potential problems or areas where the Project Board could help.
A.11.2 Composition
Date The date of the report
Period The reporting period covered by the Highlight Report
Status summary An overview of the status of the stage at this time
This reporting period:
Work Packages – pending authorization, in execution, and completed in the period (if the Work Packages are being performed by external suppliers, this information may be accompanied by purchase order and invoicing data)
Products completed in the period
Products planned but not started or completed in the period (providing an early warning indicator or potential breach of time tolerance)
Corrective actions taken during the period
Next reporting period:
Work Packages – to be authorized, in execution, and to be completed during the next period (if the Work Packages are being performed by external suppliers, this information may be accompanied by purchase order and invoicing data)
Products to be completed in the next period
Corrective actions to be completed during the next period
Project and stage tolerance status How execution of the project and stage are performing against their tolerances (e.g. cost/ time actuals and forecast)
Requests for change Raised, approved/rejected and pending
Key issues and risks Summary of actual or potential problems and risks
Lessons Report (if appropriate) (see section A.15) A review of what went well, what went badly, and any recommendations for corporate or programme management consideration.
A.12 Issue Register
A.12.1 Purpose
The purpose of the Issue Register is to capture and maintain information on all of the issues that are being formally managed. The Issue Register should be monitored by the Project Manager on a regular basis.
A.12.2 Composition
For each entry in the Issue Register, the following should be recorded:
Issue identifier Provides a unique reference for every issue entered into the Issue Register. It will typically be a numeric or alpha-numeric value
Issue type Defines the type of issue being recorded, namely:
Request for change
Off-specification
Problem/concern
Date raised The date on which the issue was originally raised
Raised by The name of the individual or team who raised the issue
Issue Report author The name of the individual or team who created the Issue Report
Issue description A statement describing the issue, its cause and impact
Priority This should be given in terms of the project’s chosen categories. Priority should be re-evaluated after impact analysis
Severity This should be given in terms of the project’s chosen scale. Severity will indicate what level of management is required to make a decision on the issue
Status The current status of the issue and the date of the last update
Closure date The date the issue was closed.
A.13 Issue Report
A.13.1 Purpose
An Issue Report is a report containing the description, impact assessment and recommendations for a request for change, offspecification or a problem/concern. It is only created for those issues that need to be handled formally. The report is initially created when capturing the issue, and updated both after the issue has been examined and when proposals are identified for issue resolution. The Issue Report is later amended further in order to record what option was decided upon, and finally updated when the implementation has been verified and the issue is closed.
A.13.2 Composition
Issue identifier As shown in the Issue Register (provides a unique reference for every Issue Report)
Issue type Defines the type of issue being
Request for change
Off-specification
Problem/concern
Date raised The date on which the issue was originally raised
Raised by The name of the individual or team who raised the issue
Issue Report author The name of the individual or team who created the Issue Report
Issue description A statement describing the issue in terms of its cause and impact
Impact analysis A detailed analysis of the likely impact of the issue. This may include, for example, a list of products impacted
Recommendation A description of what the Project Manager believes should be done to resolve the issue (and why)
Priority This should be given in terms of the project’s chosen scale. It should be re-evaluated after impact analysis
Severity This should be given in terms of the project’s chosen scale. Severity will indicate what level of management is required to make a decision on the issue
Decision The decision made (accept, reject, defer or grant concession)
Approved by A record of who made the decision
Decision date The date of the decision
Closure date The date that the issue was closed.
A.14 Lessons Log
A.14.1 Purpose
The Lessons Log 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. Some lessons may originate from within the project – where new experience (both good and bad) can be passed on to others via a Lessons Report.
A.14.2 Composition
For each entry in the Lessons Log, the following should be recorded:
Lesson type Defines the type of lesson being
Project – to be applied to this project
Corporate or programme – to be passed on to the corporate or programme management
Both project and corporate or programme management
Lesson detail The detail may include:
Event
Effect (e.g. positive/negative financial impact)
Causes/trigger
Whether there were any early warning indicators
Recommendations
Whether it was previously identified as a risk (threat or opportunity)
Date logged The date on which the lesson was originally logged
Logged by The name of the person or team who raised the lesson
Priority In terms of the project’s chosen categories.
A.15 Lessons Report
A.15.1 Purpose
The Lessons Report is used to pass on any lessons that can be usefully applied to other projects. The purpose of the report is to provoke action so that the positive lessons become embedded in the organization’s way of working, and that the organization is able to avoid any negative lessons on future projects.
A Lessons Report can be created at any time in a project and should not necessarily wait to the end. Typically it should be included as part of the End Stage Report and End Project Report. It may be appropriate (and necessary) for there to be several Lessons Reports specific to the particular organization (e.g. user, supplier, corporate or programme).
The data in the report should be used by the corporate group that is responsible for the quality management system, in order to refine, change and improve the standards. Statistics on how much effort was needed for products can help improve future estimating.
A.16 Plan
A.16.1 Purpose
A plan provides a statement of how and when objectives are to be achieved, by showing the major products, activities and resources required for the scope of the plan. In PRINCE2, there are three levels of plan: project, stage and team. Team Plans are optional and may not need to follow the same composition as a Project Plan or Stage Plan. An Exception Plan is created at the same level as the plan that it is replacing.
A Project Plan provides the Business Case with planned costs, and it identifies the management stages and other major control points. It is used by the Project Board as a baseline against which to monitor project progress.
Stage Plans cover the products, resources, activities and controls specific to the stage and are used as a baseline against which to monitor stage progress. Team Plans (if used) could comprise just a schedule appended to the Work Package(s) assigned to the Team Manager.
A plan should cover not just the activities to create products but also the activities to manage product creation – including activities for assurance, quality management, risk management, configuration management, communication and any other project controls required.
A.16.2 Composition
Plan description Covering a brief description of what the plan encompasses (i.e. project, stage, team, exception) and the planning approach
Plan prerequisites Containing any fundamental aspects that must be in place, and remain in place, for the plan to succeed
External dependencies That may influence the plan
Planning assumptions Upon which the plan is based
Lessons incorporated Details of relevant lessons from previous similar projects, which have been reviewed and accommodated within this plan
Monitoring and control Details of how the plan will be monitored and controlled
Budgets Covering time and cost, including provisions for risks and changes
Tolerances Time, cost and scope tolerances for the level of plan (which may also include more specific stage- or team-level risk tolerances)
Product Descriptions (see section A.17) Covering the products within the scope of the plan (for the Project Plan this will include the project’s product; for the Stage Plan this will be the stage products; and for a Team Plan this should be a reference to the Work Package assigned). Quality tolerances will be defined in each Product Description
Schedule Which may include graphical
Gantt or bar chart
Product breakdown structure (see Appendix D for an example)
Product flow diagram (see Appendix D for an example)
Activity network
Table of resource requirements – by resource type (e.g. four engineers, one test manager, one business analyst)
Table of requested/assigned specific resources – by name (e.g. Nikki, Jay, Francesca).
A.17 Product Description
A.17.1 Purpose
A Product Description is used to:
Understand the detailed nature, purpose, function and appearance of the product
Define who will use the product
Identify the sources of information or supply for the product
Identify the level of quality required of the product
Enable identification of activities to produce, review and approve the product
Define the people or skills required to produce, review and approve the product.
A.17.2 Composition
Identifier Unique key, probably allocated by the configuration management method and likely to include the project name, item name and version number
Title Name by which the product is known
Purpose This defines the purpose that the product will fulfil and who will use it. Is it a means to an end or an end in itself? It is helpful in understanding the product’s functions, size, quality, complexity, robustness etc.
Composition This is a list of the parts of the product. For example, if the product were a report, this would be a list of the expected chapters or sections
Derivation What are the source products from
A design is derived from a specification
A product is bought in from a supplier
A statement of the expected benefits are obtained from the user
A product is obtained from another department or team
Format and presentation The characteristics of the product
– for example, if the product were a report, this would specify whether the report should be a document, presentation slides or an email
Development skills required An indication of the skills required to develop the product or a pointer to which area(s) should supply the development resources. Identification of the actual people may be left until planning the stage in which the product is to be created
Quality criteria To what quality specification must the product be produced, and what quality measurements will be applied by those inspecting the finished product? This might be a simple reference to one or more common standards that are documented elsewhere, or it might be a full explanation of some yardstick to be applied. If the product is to be developed and approved in different states (e.g. dismantled machinery, moved machinery and reassembled machinery), then the quality criteria should be grouped into those that apply for each state
Quality tolerance Details of any range in the quality criteria within which the product would be acceptable
Quality method The kinds of quality method
– for example, design verification, pilot, test, inspection or review – that are to be used to check the quality or functionality of the product
Quality skills required An indication of the skills required to undertake the quality method or a pointer to which area(s) should supply the checking resources. Identification of the actual people may be left until planning the stage in which the quality inspection is to be done
Quality responsibilities Defining the producer, reviewer(s) and approver(s) for the product.
A.18 Product Status Account
A.18.1 Purpose
The Product Status Account provides information about the state of products within defined limits. The limits can vary. For example, the report could cover the entire project, a particular stage, a particular area of the project, or the history of a specific product. It is particularly useful if the Project Manager wishes to confirm the version number of products.
A.18.2 Composition
Report scope Describing the scope of the report (e.g. for the entire project, by stage, by product type, by supplier etc. The product’s attribute can be used to select the subset of products for the report)
Date produced The date the report was generated
Product status For each product within the
Product identifier and title
Version
Status and date of status change
Product state
Owner
Copy-holders
Location
User(s)
Producer and date allocated to producer
Planned and actual date Product Description was baselined
Planned and actual date product was baselined
Planned date for the next baseline
List of related items
List of related issues (including changes pending and approved) and risks.
A.19 Project Brief
A.19.1 Purpose
A Project Brief is used to provide a full and firm foundation for the initiation of the project and is created in the Starting up a Project process. In the Initiating a Project process, the contents of the Project Brief are extended and refined in the Project Initiation Documentation, after which the Project Brief is no longer maintained.
A.19.2 Composition
Project definition Explaining what the project
Background
Project objectives (covering time, cost, quality, scope, risk and benefit performance goals)
Desired outcomes
Project scope and exclusions
Constraints and assumptions
Project tolerances
The user(s) and any other known interested parties
Interfaces
Outline Business Case (see section A.2) Reasons why the project is needed and the business option selected. This will later be developed into a detailed Business Case during the Initiating a Project process
Project Product Description (see section A.21) Including the customer’s quality expectations, user acceptance criteria, and operations and maintenance acceptance criteria
Project approach To define the choice of solution that will be used within the project to deliver the business option selected from the Business Case, taking into consideration the operational environment into which the solution must fit
Project management team structure A chart showing who will be involved with the project
Role descriptions For the project management team and any other key resources identified at this time
References To any associated documents or products.
A.20 Project Initiation Documentation
A.20.1 Purpose
The purpose of the Project Initiation Documentation is to define the project, in order to form the basis for its management and an assessment of its overall success. The Project Initiation Documentation gives the direction and scope of the project and (along with the Stage Plan) forms the ‘contract’ between the Project Manager and the Project Board.
The three primary uses of the Project Initiation Documentation are to:
Ensure that the project has a sound basis before asking the Project Board to make any major commitment to the project
Act as a base document against which the Project Board and Project Manager can assess progress, issues and ongoing viability questions
Provide a single source of reference about the project so that people joining the ‘temporary organization’ can quickly and easily find out what the project is about, and how it is being managed.
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. The version of the Project Initiation Documentation that was used to gain authorization for the project is preserved as the basis against which performance will later be assessed when closing the project.
A.20.2 Composition
There follows a contents list for the Project Initiation Document. Note that the first two (project definition and project approach) are extracted from the Project Brief.
Project definition Explaining what the project
Background
Project objectives and desired outcomes
Project scope and exclusions
Constraints and assumptions
The user(s) and any other known interested parties
Interfaces
Project approach To define the choice of solution that will be used in the project to deliver the business option selected from the Business Case, taking into consideration the operational environment into which the solution must fit
Business Case (see section A.2) Describing the justification for the project based on estimated costs, risks and benefits
Project management team structure A chart showing who will be involved with the project
Role descriptions For the project management team and any other key resources
Quality Management Strategy (see section A.22) Describing the quality techniques and standards to be applied, and the responsibilities for achieving the required quality levels
Configuration Management Strategy (see section A.6) Describing how and by whom the project’s products will be controlled and protected
Risk Management Strategy (see section A.24) Describing the specific risk management techniques and standards to be applied, and the responsibilities for achieving an effective risk management procedure
Communication Management Strategy (see section A.4) To define the parties interested in the project and the means and frequency of communication between them and the project
Project Plan (see section A.16) Describing how and when the project’s objectives are to be achieved, by showing the major products, activities and resources required on the project. It provides a baseline against which to monitor the project’s progress stage by stage
Project controls Summarizing the projectlevel controls such as stage boundaries, agreed tolerances, monitoring and reporting
Tailoring of PRINCE2 A summary of how PRINCE2 will be tailored for the project.
A.21 Project Product Description
A.21.1 Purpose
The Project Product Description is a special form of Product Description that defines what the project must deliver in order to gain acceptance. It is used to:
Gain agreement from the user on the project’s scope and requirements
Define the customer’s quality expectations
Define the acceptance criteria, method and responsibilities for the project.
The Product Description for the project product is created in the Starting up a Project process as part of the initial scoping activity, and is refined during the Initiating a Project process when creating the Project Plan. It is subject to formal change control and should be checked at stage boundaries (during Managing a Stage Boundary) to see if any changes are required. It is used by the Closing a Project process as part of the verification that the project has delivered what was expected of it, and that the acceptance criteria have been met.
A.21.2 Composition
Title Name by which the project is known
Purpose 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.
Composition A description of the major products to be delivered by the project
Derivation What are the source products from
Existing products to be modified
Design specifications
A feasibility report
Project mandate
Development skills required An indication of the skills required to develop the product, or a pointer to which area(s) should supply the development resources
Customer’s quality expectations A description of the quality expected of the project’s product and the standards and processes that will need to be applied to achieve that quality. They will impact on every part of the product development, and thus on time and cost. The quality expectations are captured in discussions with the customer. Where possible, expectations should be prioritized
Acceptance criteria A prioritized list of criteria that the project’s product must meet before the customer will accept it
– i.e. measurable definitions of the attributes that must apply to the set of products to be acceptable to key stakeholders (and, in particular, the users and the operational and maintenance organizations). Examples are: ease of use, ease of support, ease of maintenance, appearance, major functions, development costs, running costs, capacity, availability, reliability, security, accuracy or performance
Project-level quality tolerances Specifying any tolerances that may apply for the acceptance criteria
Acceptance method Stating the means by which acceptance will be confirmed. This may simply be a case of confirming that all the project’s products have been approved or may involve describing complex handover arrangements for the project’s product, including any phased handover of the project’s products
Acceptance responsibilities Defining who will be responsible for confirming acceptance.
A.22 Quality Management Strategy
A.22.1 Purpose
A Quality Management Strategy is used to define the quality techniques and standards to be applied, and the various responsibilities for achieving the required quality levels, during the project.
A.22.2 Composition
Introduction States the purpose, objectives and scope, and identifies who is responsible for the strategy
Quality management procedure A description of (or reference to) the quality management procedure to be used. Any variance from corporate or programme management quality standards should be highlighted, together with a justification for the variance. The procedure
Quality planning
Quality control: the project’s approach to quality control activities. This may include:
Quality standards
Templates and forms to be employed (e.g. Product Description(s), Quality Register)
Definitions of types of quality methods (e.g. inspection, pilot)
Metrics to be employed in support of quality control
Quality assurance: the project’s approach to quality assurance activities. This may include:
Responsibilities of the Project Board
Compliance audits
Corporate or programme management reviews
Tools and techniques Refers to any quality management systems or tools to be used, and any preference for techniques which may be used for each step in the quality management procedure
Records Definition of what quality records will be required and where they will be stored, including the composition and format of the Quality Register
Reporting Describes any quality management reports that are to produced, their purpose, timing and recipients
Timing of quality management activities States when formal quality management activities are to be undertaken, for example audits (this may be a reference to the Quality Register)
Roles and responsibilities Defines the roles and responsibilities for quality management activities, including those with quality responsibilities from corporate or programme management.
A.23 Quality Register
A.23.1 Purpose
A Quality Register is used to summarize all the quality management activities that are planned or have taken place, and provides information for the End Stage Reports and End Project Report. Its purpose is to:
Issue a unique reference for each quality activity
Act as a pointer to the quality records for a product
Act as a summary of the number and type of quality activities undertaken.
A.23.2 Composition
For each entry in the Quality Register, the following should be recorded:
Quality identifier Provides a unique reference for every quality activity entered into the Quality Register. It will typically be a numeric or alpha-numeric value
Product identifier(s) Unique identifier(s) for the product(s) that the quality activity relates to
Product title(s) The name(s) by which the product(s) is known
Method The method employed for the quality activity (e.g. pilot, quality review, audit etc.)
Roles and responsibilities The person or team responsible for the quality management activities (e.g. auditor or, for quality reviews, presenter, reviewer(s), chair, administrator)
Dates Planned, forecast and actual dates for:
The quality activity
Sign-off that the quality activity is complete
Result The result of the quality activity. If a product fails a quality review, then any re-assessment should be listed as a separate entry in the register, as the original quality activity has been completed (in deciding that the result is a ‘fail’)
Quality records References to the quality inspection documentation, such as a test plan or the details of any actions required to correct errors and omissions of the products being inspected.
A.24 Risk Management Strategy
A.24.1 Purpose
A Risk Management Strategy describes the specific risk management techniques and standards to be applied and the responsibilities for achieving an effective risk management procedure.
A.24.2 Composition
Introduction States the purpose, objectives and scope, and identifies who is responsible for the strategy
Risk management procedure A description of (or reference to) the risk management procedure to be used. Any variance from corporate or programme management standards should be highlighted, together with a justification for the variance. The procedure
Identify
Assess
Plan
Implement
Communicate
Tools and techniques Refers to any risk management systems or tools to be used, and any preference for techniques which may be used for each step in the risk management procedure
Records Definition of the composition and format of the Risk Register and any other risk records to be used by the project
Reporting Describes any risk management reports that are to be produced, including their purpose, timing and recipients
Timing of risk management activities States when formal risk management activities are to be undertaken
– for example, at end stage assessments
Roles and responsibilities Defines the roles and responsibilities for risk management activities
Scales Defines the scales for estimating probability and impact for the project to ensure that the scales for cost and time (for instance) are relevant to the cost and timeframe of the project. These may be shown in the form of probability impact grids giving the criteria for each level within the scale, e.g. for ‘very high’, ‘high’, ‘medium’, ‘low’ and ‘very low’
Proximity Guidance on how proximity for risk events is to be assessed. Proximity reflects the fact that risks will occur at particular times and the severity of their impact will vary according to when they occur. Typical proximity categories will be: imminent, within the stage, within the project, beyond the project
Risk categories Definition of the risk categories to be used (if at all). These may be derived from a risk breakdown structure or prompt list. If no risks have been recorded against a category, this may suggest that the risk identification has not been as thorough as it should have been
Risk response categories Definition of the risk response categories to be used, which themselves depend on whether a risk is a perceived threat or an opportunity
Early-warning indicators Definition of any indicators to be used to track critical aspects of the project so that if certain predefined levels are reached, corrective action will be triggered. They will be selected for their relevance to the project objectives
Risk tolerance Defining the threshold levels of risk exposure, which, when exceeded, require the risk to be escalated to the next level of management. (For example, a project-level risk tolerance could be set as any risk that, should it occur, would result in loss of trading. Such risks would need to be escalated to corporate or programme management.) The risk tolerance should define the risk expectations of corporate or programme management and the Project Board
Risk budget Describing whether a risk budget is to be established and, if so, how it will be used.
A.25 Risk Register
A.25.1 Purpose
A Risk Register provides a record of identified risks relating to the project, including their status and history. It is used to capture and maintain information on all of the identified threats and opportunities relating to the project.
A.25.2 Composition
For each entry in the Risk Register, the following should be recorded:
Risk identifier Provides a unique reference for every risk entered into the Risk Register. It will typically be a numeric or alpha-numeric value
Risk author The person who raised the risk
Date registered The date the risk was identified
Risk category The type of risk in terms of the project’s chosen categories (e.g. schedule, quality, legal etc.)
Risk description In terms of the cause, event (threat or opportunity) and effect (description in words of the impact)
Probability, impact and expected value It is helpful to estimate the inherent values (preresponse action) and residual values (postresponse action). These should be recorded in accordance with the project’s chosen scales
Proximity This would typically state how close to the present time the risk event is anticipated to happen (e.g. imminent, within stage, within project, beyond project). Proximity should be recorded in accordance with the project’s chosen scales
Risk response categories How the project will treat the risk in terms of the project’s chosen
For threats: avoid, reduce, fallback, transfer, accept, share
For opportunities: enhance, exploit, reject, share
Risk response Actions to resolve the risk, and these actions should be aligned to the chosen response categories. Note that more than one risk response may apply to a risk
Risk status Typically described in terms of whether the risk is active or closed
Risk owner The person responsible for managing the risk (there can be only one risk owner per risk)
Risk actionee The person(s) who will implement the action(s) described in the risk response. This may or may not be the same person as the risk owner.
A.26 Work Package
A.26.1 Purpose
A Work Package is a set of information about one or more required products collated by the Project Manager to pass responsibility for work or delivery formally to a Team Manager or team member.
A.26.2 Composition
Although the content may vary greatly according to the relationship between the Project Manager and the recipient of the Work Package, it should cover:
Date The date of the agreement between the Project Manager and the Team Manager/person authorized
Team Manager or person authorized The name of the Team Manager or individual with whom the agreement has been made
Work Package description A description of the work to be done
Techniques, processes and procedures Any techniques, tools, standards, processes or procedures to be used in the creation of the specialist products
Development interfaces Interfaces that must be maintained while developing the products. These may be people providing information or those who need to receive information
Operations and maintenance interfaces Identification of any specialist products with which the product(s) in the Work Package will have to interface during their operational life. These may be other products to be produced by the project, existing products, or those to be produced by other projects (for example, if the project is part of a programme)
Configuration management requirements A statement of any arrangements that must be made by the producer for: version control of the products in the Work Package; obtaining copies of other products or their Product Descriptions; submission of the product to configuration management; any storage or security requirements; and who, if anyone, needs to be advised of changes in the status of the Work Package
Joint agreements Details of the agreements on effort, cost, start and end dates, and key milestones for the Work Package
Tolerances Details of the tolerances for the Work Package (the tolerances will be for time and cost but may also include scope and risk)
Constraints Any constraints (apart from the tolerances) on the work, people to be involved, timings, charges, rules to be followed (for example, security and safety) etc.
Reporting arrangements The expected frequency and content of Checkpoint Reports
Problem handling and escalation This refers to the procedure for raising issues and risks
Extracts or references Any extracts or
Stage Plan extract This will be the relevant section of the Stage Plan for the current management stage or will be a pointer to it
Product Description(s) This would normally be an attachment of the Product Description(s) for the products identified in the Work Package (note that the Product Description contains the quality methods to be used)
Approval method The person, role or group who will approve the completed products within the Work Package, and how the Project Manager is to be advised of completion of the products and Work Package.
There should be space on the Work Package to record both its initial authorization and its acceptance and return as a completed Work Package. This can be enhanced to include an assessment of the work and go towards performance appraisal.
Projects with common controls across all Work Packages may simply cross-reference the controls defined in the Project Plan or Stage Plan.
Like this:
Like Loading...
