PRINCE2 practices: Free ebook

Introduction

This guide to the PRINCE2 practices is one in a series of four study guides designed to prepare students for attending a PRINCE2 Foundation course. The other three – PRINCE2 principles, PRINCE2 processes, and People – are available to download as ebooks.

These articles have all been updated so they are based upon the 7^th edition of PRINCE2 which was released in 2023. We recommend you read all four articles.

Read on to learn all about the seven PRINCE2 practices and start preparing yourself for the PRINCE2 Foundation exam.

The seven practices of PRINCE2 are:

• Business case
• Organizing
• Plans
• Quality
• Risk
• Issues
• Progress

The seven practices

The seven PRINCE2 practices are designed to help the project management team apply and tailor PRINCE2, primarily through a suite of management approaches. The approaches define the procedures, techniques, and standards to be applied and the responsibilities for that practice to be effective.

PRINCE2 does not prescribe how procedures, techniques, and standards should be documented, nor the level of detail required, nor how they are published and shared. The approaches could be a few paragraphs to a comprehensive and large document.

PRINCE2 management products describe the information required to manage the project. Two management products that are relevant to the majority of the PRINCE2 practices are the project initiation documentation (PID) and the project log.

The project initiation documentation (PID) provides the direction and scope for the project and (with the stage plan) forms the ‘contract’ between the project manager and the project board. The PID ensures the project has a solid foundation before a major commitment is made and forms a base document against which progress, issues, and ongoing viability can be assessed. It also provides a single reference about the project.

The project log is used to capture information that is continually changing. For example, the records about issues, lessons, products, quality, risk, and other formal/informal actions or events. The project log is dynamic and contains both current and historic records of project progress.

Business case

The purpose of this practice is “to establish mechanisms to judge whether the project is (and remains) desirable, viable, and achievable as a means to support decision making in its (continued) investment” [1]. In other words, it’s about deciding whether the project is a worthwhile investment.

The business investing in the project and (in a commercial environment) the supplier organizations will each have their own business case written to justify their own involvement in the project.

Projects deliver ‘specialist’ products (known as outputs) which are used to facilitate changes within the business. These changes create capabilities that lead to outcomes allowing the business to realize the benefits that are described in the business case to justify the project. In turn, these outcomes contribute to achieving business objectives which are the measurable outcomes contributing to the organization’s strategy. Outcomes perceived as negative by stakeholders are called dis-benefits.

A business case is ‘owned’ by the project executive. At all times, the executive must ensure there is an acceptable business case, otherwise the project should be closed. Not wasting any more time and money on a project is better than continuing with an unjustifiable project.

The development of the business case begins with the initial justification being communicated by the business in the project mandate. This is then documented by the executive as the outline version and forms part of the project brief. During the initiation stage the outline is expanded by the project manager with more detail into the full business case and forms part of the PID. The full version is then used to justify the project. Thereafter, the business case is maintained by the project manager who must update it at the end of each stage, so that the project board can decide whether to proceed to the next stage or not.

After the project is closed, the business case is no longer required, and the benefits management approach is used to guide who will measure the realized benefits (note this can also happen during the project). This approach gets updated as and when the benefits are actually realized (either at the end of a stage, or post-project).

The senior user role is responsible for both specifying the benefits of the project, and also for realizing them i.e. make sure that they are actually achieved after the project closes. This means that the people who perform the senior user role need to come from those areas of the business organization which are most often impacted by the changes (outcomes).

Sustainability targets and tolerances for the project are documented in the business case and should reference and contribute to the environmental, social and governance goals forming part of the organization’s business objectives. The sustainability management approach (part of the PID) defines actions, reviews, and controls needed to ensure that sustainability performance targets are achieved.

Relationships between the ‘business case’ practice and the principles are visible when creating and maintaining the business case throughout the project; when using lessons to inform business justification; by assigning accountability for managing the business case; by ensuring decisions at stage boundaries are checked for business justification; by measuring the impact of issues and risks to the business case; by ensuring that the products produced can lead to the required outcomes and benefits; and by ensuring the level of formality and control for developing the business case is appropriate.

Organizing

The purpose of this practice is “to define and establish the project’s structure of accountability and responsibilities (the who?)” [2].

Projects are complex and involve an ever-changing web of relationships. Successful projects establish an effective project management team structure to navigate this complexity (hence the principle ‘define roles, responsibilities, and relationships’).

The project management team must represent the interests of 3 stakeholder groups: business (the commissioning organization), user (the organization which will use the project’s products to realize benefits), and supplier (the organization which delivers the project’s outputs) communities. The project team refers to all those people who allocate their time to the project.

PRINCE2 defines a set of roles and responsibilities. It does not define tasks to be allocated to people on a one-to-one basis. When tailoring, roles can be shared (performed by more than one person) or combined (one person performs multiple roles), but responsibilities must always be allocated. In PRINCE2 all roles can be shared EXCEPT for the executive and project manager roles. The project assurance role cannot be combined with project manager, team manager or project support roles.

The key decision-making role is the project board consisting of 3 roles: project executive, senior user, and senior supplier. It is important to note that the project board is not a democracy and ultimately, it is the executive who takes the decisions, advised, and supported by the other 2 roles. On small projects, a single individual might perform all 3 project board roles, providing they can represent all 3 project stakeholder groups (business, user, supplier).

The executive role must be able to represent the business. This role is ultimately accountable for the project. The senior user role is responsible for specifying and realizing benefits and for specifying the project’s requirements and products. The senior supplier is accountable for the quality of the specialist products which it delivers to the project.

The project manager role is responsible for the day-to-day management of the project and reports progress on a regular basis to the project board. The project manager is responsible for keeping issues and risks under control, monitoring progress, taking corrective action when there is a slippage from the plan, and escalating exceptions to the project board.

Team managers manage teams of specialists who have the requisite skills to enable them to design and build the products which have been specified by the customer. They are responsible for delivering the specialist products, on time and within the agreed tolerances. They report on a regular basis to the project manager.

The project assurance role assures the project board independently of the project manager that the project is being conducted properly. Project assurance gives advice to the project manager and reviews documents prior to their approval by the project board.

The project support role assists the project manager and team managers with administration, writing reports, monitoring of progress and tools.

On commercial projects, a commercial management approach is included in the PID. This covers all commercial aspects such as procurement and contract management.

Work breakdown structures help support the project manager in structuring teams and setting boundaries and are most useful when there are multiple work packages and a mix of internally staffed and externally supplied work packages.

Relationships between the ‘organizing’ practice and the principles are visible when assigning a business representative to the executive role; when using lessons to inform the team structure design and to ensure the right people in the right roles; when ensuring everyone in the PM team are aware of their responsibilities and relationships; when assessing the PM team structure at stage boundaries; when empowering decision-makers at appropriate points; when ensuring users are on the PM team who can support product acceptance; and when ensuring the PM team is appropriate to the needs of the project.

PRINCE2 describes a technique for the organizing practice and includes 5 steps. These are:

1. Understand the organizational ecosystem – this is required to successfully design the project organization and determine how the project ecosystem will develop as a distinct entity from the organizational ecosystem.
2. Design the project ecosystem – this describes how to organize people and work to achieve the project’s objectives.
3. Develop the project ecosystem – this involves implementing the project organizational design and continuously improving it throughout the project.
4. Manage changes to the project ecosystem – the project manager must make the best use of the people and resources available, enhancing capabilities where required.
5. Transition the project into the organizational ecosystem – it is important to understand the organizational ecosystem that the products of the project and any remaining project team members will be transitioning into. The three key aspects the project board must consider are products, people, and learning.

Plans

The purpose of this practice is to “to facilitate communication and control by defining: the products to be delivered (the ‘what’), and; the means to deliver them (the ‘who’, the ‘how’, the ‘where’, and estimates of the ‘when’ and for ‘how much’) to satisfy the project business case (the ‘why’)” [3].

Planning provides you with information about what is required, how to achieve it, by whom, when, and whether the targets for benefits, costs, time, quality, scope, sustainability, and risk are achievable. An approved plan forms a baseline against which progress will be measured.

It is unrealistic to plan in detail too far into the future (beyond the planning horizon). Plan in detail only until the end of the next stage. The division of the project into stages is determined by balancing the delivery method, sequence of activities, people and resources, key decision points, level of risk, and the time horizon. Stages are sequential and form “stop-go” decision points for the project board. The work required to deliver one or more products in each stage are described in work package description(s). They are used to pass responsibility for work formally to a team manager or member.

PRINCE2 recommends 3 levels of plan to meet the needs of the 3 levels management:

• project plan (used by the project board): a high-level plan containing project-level costs, timescales, and control points, updated at each stage end to reflect progress.
• stage plan (used by the project manager): a detailed plan for day-to-day management of the project. There is one for each management stage.
• team plan (used by a team manager): more detailed covering a work package.

Exception plans are new plans and can replace stage plans or the project plan and must be approved prior to replacing the plan which caused the exception.

Scope refers to the sum of all of the product, delivery, and management activities in an approved plan and its product descriptions and work package descriptions.

The PRINCE2 technique for planning involves steps which are repeated for all PRINCE2 plans. These are:

• Defining and analysing products
• Organising work packages*
• Preparing estimates*
• Preparing schedule*
• Preparing the budget*
• Documenting the plan
• Analysing risks (note: occurs in parallel with those steps marked with *).

A schedule is a graphical representation of a plan. The most common format is a Gantt chart. Usually it describes a sequence of tasks and resource allocations, which together deliver the plan.

The defining and analysing products step involves 4 further steps:

1. Write a project product description (only for project plan) to define what the project must deliver to gain acceptance. This describes the project’s major products and intended purpose. It is created in the ‘starting up a project’ process and refined in the ‘initiating a project’ process.
2. Create a product breakdown structure showing the products within scope (note: external products are those that already exist or are created outside of the plan).
3. Write product descriptions for the major products.
4. Create a product flow diagram to define the sequence the products will be developed. This shows the dependencies (internal and external) between products.

When planning, understanding which constraints take precedence, selecting which approaches to use, and setting appropriate tolerances for control is important. Tolerances which can be set for plans include time, cost, scope, risk, and sustainability. The PRINCE2 technique for planning helps the project management team to set tolerances that balance the need for the project board to maintain effective control.

Plans can address sustainability in at least three different ways:

1. Product sustainability – when specifying products, consider the environmental impact of the product through its full lifetime.
2. Delivery sustainability – choices made in planning can affect the climate impacts of delivery activities. Sustainability tolerances are an effective way to keep things like fuel consumption and waste aligned with the organizational strategy.
3. Benefits sustainability – projects often deliver benefits after closure. Achieving the expected benefits often fails because there are no means to sustain these benefits. To avoid this problem plan for benefits sustainability e.g. through ongoing training and user support after project closure.

Relationships between the ‘plans’ practice and the principles are visible when aligning plans’ performance targets to business case objectives; when sharing planning lessons for future projects; when establishing roles and responsibilities for a plan; when breaking the project into stages and aligning stages to  key decision points; when defining levels of plan and establishing targets and tolerances for them; when basing planning activities on identifying required products and the most effective way to deliver them; and when planning in ways that are suitable and relevant for your project approach and context.

Quality

The purpose of this practice is “to document the user’s requirements of the project products and to establish the means by which they will be met” [4].

Requirements are needs or expectations that are documented in an approved management product. Any needs or expectations not captured in an approved management product are NOT requirements. The user’s quality expectations are (usually high level) statements about the quality expected from the project product, captured in the project product description. The project product description contains acceptance criteria which form a prioritized list of criteria that the project product must meet before the user will accept it. Acceptance criteria are usually described as the functional capabilities the business expects to achieve after accepting the project’s products and are derived from user’s quality expectations. Quality specifications are stated in product descriptions and describe the quality measures to be applied by those performing quality control and the quality levels that a finished product must meet.

Effective quality management requires quality planning, quality control, and quality assurance. Quality planning is where the quality specifications for the project products are captured, and the associated product descriptions and quality management approach are created. Quality control refers to the procedures to monitor products and their development or delivery activities to determine whether they comply with relevant standards and to identify ways to minimize the causes of unsatisfactory performance.  Quality assurance is the systematic and planned activities that provides confidence that products will meet their defined quality specifications when tested under quality control. Quality assurance activities are typically performed by the business to ensure they are independent of the project team.

The PRINCE2 technique for quality management involves quality planning, quality control and acceptance. Quality planning starts with gathering inputs from users in the form of user’s quality expectations and acceptance criteria. These are documented in the quality management approach (describing techniques and standards to be applied, and the roles and responsibilities for achieving the required quality specifications and acceptance criteria) and a set of product descriptions (detailing the quality methods, specifications, and quality tolerances) for the major products.

When the quality management approach and the initial product descriptions are approved, the focus shifts to quality control. Quality control activities and results (usually ‘pass’ or ‘fail’) are recorded in the quality register which is used to summarize all quality management activities that are planned or have occurred.

If a product fails a quality control activity (e.g. inspection or test), and it is expected that the product is likely to pass, the activity may be repeated. If a product cannot pass, it must be reviewed against quality tolerances and specifications. Exceptions to quality tolerances and off-specifications are addressed using the issue management technique.

The individuals or roles responsible for accepting a product are identified in the product description. Acceptance usually involves both the review of the product quality control information and an independent review of the product against the user’s quality expectations and acceptance criteria. Acceptance of a project product typically transfers ownership or responsibility for the product from the project or supplier to the project board on behalf of the user.

To help with monitoring the delivery of products, the product register (part of the project log) is used to list all products required of a plan and their statuses. This enables the project team to see the dates of product description approvals, dates of product acceptance, and the current statuses of products (such as in development or accepted).

Relationships between the ‘quality’ practice and the principles are visible when developing an approach that designs and delivers products meeting the specifications required of the business case; when incorporating lessons into quality planning; when establishing roles and responsibilities for quality; when aligning quality controls and techniques with stages; when establishing approved quality tolerances in the PID; when basing quality planning and control activities on the project products; and when ensuring only those quality activities appropriate to the method delivery and product characteristics are performed.

Risk

The purpose of this practice is to “to identify, assess, and control uncertainties that would affect the project’s objectives, and, as a result, improve the ability of the project to succeed” [5].

A risk is defined as an uncertain event or set of events which (if it occurs) will affect the achievement of objectives. Risks with a negative effect are called threats, and risks with a positive effect are called opportunities.

Effective risk management provides confidence that the project can meet objectives, and the business justification remains valid. Risk management requires planning, analysis, and control, and is informed by the risk culture of the business. A supportive risk culture recognizes risk management as an important part of decision-making.

The risk culture of the business should be reflected in its risk appetite, which is the amount and type of risk that the business is willing to take in pursuit of its objectives. Risk tolerance is a threshold representing the tolerable range of outcomes for each objective ‘at risk’ using the same units as for measuring performance for that objective. Risk exposure is the degree to which a particular objective is ‘at risk’. Risk exposure can be positive or negative.

One aspect of culture that affects decisions and risk management is decision bias where people adopt mental shortcuts or faulty thinking during decision-making. Decision bias is natural and mainly positive, allowing the brain to efficiently make decisions, but can sometimes be problematic. Some types of bias include optimism bias, loss aversion, groupthink, proximity.

When risk planning, risk categories can help projects identify and prioritize risks, and appropriate owners. The results of risk planning are recorded in the risk management approach and reflects the project board’s attitude towards risk-taking, documented as risk tolerance (the threshold level of risk, which once exceeded (or forecast to be exceeded) will result in an exception report being triggered). Risk tolerance is set by the project board based on the business’ overall risk appetite.

Risk planning requires specifying how risks will be assessed, analysed, and recorded. Risks are expressed in terms of their cause (the risk source, or situation causing it), event (the area of uncertainty), and effect (impact on project objectives). Risks are recorded in a risk register (part of the project log) which keeps a record of identified risks, their status and history.

Risk analysis can include qualitative and quantitative approaches. Qualitative analyses require assessing risk probability (the estimated likelihood that a risk will occur) and impact on objectives if the risk occurs. It may include analysing risk proximity (how near in time it might occur) and velocity (how quickly it would have an impact if it occurs). A useful way to summarize the set of risks is by using a risk matrix containing a risk tolerance line. Risks above the line are those that the business will not tolerate, except under special circumstances, and must be referred by the project manager to the project board as an exception.

The combined effect of all risks helps understand whether the overall risk exposure (the degree to which a particular objective is ‘at risk’) of the project remains within the risk appetite of the business.

Risk control requires taking decisions about the best responses to take, monitoring the effectiveness of these responses, and reporting the results. PRINCE2 defines 2 responses (avoid, reduce) specifically for threats and 2 responses (exploit, enhance) specifically for opportunities. In addition, it defines 4 more responses (transfer, share, accept, prepare contingent plans) applicable to both threats and opportunities.

When deciding which responses to take, a risk owner is assigned responsibility for responding to a risk. A risk action owner (risk actionee) is also appointed as the nominated owner of agreed actions to respond to a risk. The use of data to identify, analyse, and control risks helps provide greater insight about risks which is useful when deciding about risk responses. Risk responses are paid for from a risk budget.

The PRINCE2 technique for the ‘risk’ practice describes 5 steps:

1. Identify – identify the context and formulate a risk management approach and identify risks. Log the risks in the risk register and describe as cause/event/effect.
2. Assess
   • Estimate the probability (likelihood), impact, proximity, and record in risk register
   • Evaluate the overall net effect of all risks.
3. Plan one or more specific risk responses. Escalate any risks above risk tolerance to the project board as an exception.
4. Implement – the chosen risk responses and assign:
   • A risk owner – the individual responsible for managing the risk.
   • A risk action owner – the person(s) assigned to carry out the risk response(s).
   • Monitor the effectiveness of the response(s and identify any new risks emerging as a result of the responses (back to step 1).
5. Communicate – throughout all the previous steps, report risk information to stakeholders using all reports.

Relationships between the ‘risk’ practice and the principles are visible when assessing whether identified risks have a material impact on the business case; when using lessons to inform risk identification and management; when clarifying risk responsibilities throughout of the project; when de-risking the project via ‘stop-go’ decisions at stage end; when empowering risk and action owners, and escalating risks that are forecast to exceed tolerances; when understanding risks associated with developing specialist and management products; and when aligning the risk management approach to the project size and complexity.

Issues

The purpose is to “collect and assess issues and control changes to the project’s baseline” [6].

An issue is an event relevant to the project that requires project management consideration. Anyone can raise an issue at any time and are captured in the project log.

A change is a modification to any approved product that forms the project baseline. The project baseline forms the currently approved versions of those management products and project products that are subject to change control. Changes are not incorporated into the project baseline until they have been approved by those with the appropriate authority.

Projects occur in the context of organizational and environmental change. The bigger the length and scope of a project, the more likely that issues and potential changes must be dealt with. Issue management forms a key part of a project’s monitoring function. The PRINCE2 issue management approach describes:

• Baselines – describing what is subject to change control.
• Issue resolution – describing how issues are identified, captured, assessed, and resolved.
• Change control – describing how changes to the project baseline are controlled.
• Delegating authority for changes – allocating authority from the project board down to enable responsive and controlled change management.
• Change budget – setting aside money in a plan to pay for changes.

Baselines describe the current approved versions of products that are subject to change control. The project management team must determine.

During issue resolution, issues are categorized as one of:

• a problem or concern – a problem is an issue with an immediate and negative impact. A concern is an issue whose timeliness and impact must be assessed.
• an event external to the project.
• a business opportunity – an issue representing an unexpected positive effect for the project or user organization.
• a request for change – a request to change a baseline product.
• off-specification – a product that will not meet its quality specifications.

Change control is how changes that may affect the project baseline are identified, assessed, and then approved, rejected, or deferred.

Delegating authority for changes may be done by the project board which is the ultimate authority for reviewing and approving requests for change and off-specifications. Delegating authority requires balancing efficiency and control. Too little delegation means the project board is likely to slow the progress. Too much delegation involves an increased risk that the overall benefits of the project will be reduced as the business justification is diluted.

The change budget is money set aside in a plan to cover changes. It is allocated by those with delegated authority to deliver authorized changes.

The PRINCE2 technique for issue management contains 5 steps:

1. Capture – determine the issue type and initial severity/priority and record in the issue register.
2. Assess – analyse the impact on the business case and project risk profile. Check the severity/priority.
3. Recommend – identify, evaluate, and recommend options for responding.
4. Decide – escalate if beyond delegated authority. Approve, reject, ask for an exception plan, and request more information.
5. Implement – take corrective action. Update records and project baseline if necessary.

Note, for minor issues that can be dealt with immediately by the project manager and do not need to be tracked formally, should be recorded in the daily log.

There are 3 management products that support issue management. The issue management approach (part of the PID) describes how issues will be captured and reported, and how changes to the project baseline will be assessed and controlled. An issue report describes an issue’s impacts on the project baseline and identifies ways to resolve the issue and recommends a decision. The issue register (part of the project log) is used to log all issue reports raised during the project, their status, and closure date.

Relationships between the ‘issues’ practice and the principles are visible when assessing the impact of issues on business case; when using issue management to capture the lessons learned; establishing roles and responsibilities for issue management and change control; when enabling issues and changes to be identified and reviewed within stages; when establishing the authority and procedure for issue management; when linking issues and requested changes to the project baseline; and when requiring a level of change control appropriate to project’s needs.

Progress

The purpose is to “

• establish mechanisms to monitor and compare actual achievements against those planned
• provide a forecast for the project’s objectives and continued viability
• control any deviations causing an exception” [7].

Effective progress management includes:

• defining management levels and tolerances for progress control
• applying two types of control (event-driven and time-driven)
• reviewing progress and lessons
• reporting progress and lessons
• forecasting remaining work
• escalating
• using data

Progress measures the achievement of a plan’s objectives and is monitored at work package, stage, and project levels. Progress control involves measuring actual progress against the 7 performance targets and is delivered through accurate, timely, and regular measurement of actual progress and comparing it with the planned progress at that point in the project or stage and taking any necessary corrective action. Tolerances are the permissible deviations from the plan’s target for benefits, cost, time, quality, scope, sustainability, and risk before it needs to be escalated to the next level of management. Tolerance is applied at project, stage, and team levels.

The business layer sets project tolerances, the project board sets stage tolerances, and the project manager agrees work package tolerances with a team manager. An exception is a situation where it is forecast that there will be a deviation beyond the agreed tolerance levels. Exceptions can occur when either project-level or stage-level tolerances are forecast to be exceeded.

There are two types of progress control:

1. Event-driven controls occur when a specific event occurs, e.g. at the end of a stage. Control (decision-making) is event-based.
2. Time-driven controls occur at predefined periodic intervals e.g. highlight reports for the project board or checkpoint reports showing the progress of a work package. Monitoring is time-based.

Reporting is both time-driven and event- driven. Using event-driven controls is efficient because the project management team only meet when most needed, not regularly which would be unnecessary.

Reviewing progress and lessons is done during the ‘controlling a stage’ process by the project manager who regularly reviews progress using checkpoint reports from the team manager and uses this information to update the stage plan with the actual progress. They also use the daily log to record informal issues and other notes not captured in other management product. The project manager reviews the product register to understand the status of the products, issues and risks, and quality activities. Any lessons identified are captured in the lessons log (part of project log).

Reporting progress and lessons is also done during the ‘controlling a stage’ process. The frequency of reporting reflects the level of control needed. The project manager creates a highlight report to update the project board with progress. Reports can be in either digital or non-digital forms. On larger projects lessons reports may report lessons. At the end of a stage, an end stage report summarises progress so far, including the overall project situation, and sufficient information for the project board to decide whether to proceed with the project.

Forecasts are predictions made by studying historical data and patterns. When reviewing progress, the project manager forecasts the remaining work to be done. They assess past performance data to predict future risks and outcomes and whether the project retains continued business justification. The digital and data management approach describes the systems and data for forecasting.

Escalating issues is done using the PRINCE2 technique for exception management containing 6 steps:

Step 1 – The team manager forecasts that the work package will finish outside its tolerances and raises an issue in the issue register. The project manager tries to resolve the issue within stage tolerances. The issue is reported in the next highlight to the project board. For formal issues, an issue report is written.

Step 2 – If the issue will breach either stage or project tolerances, the project manager creates an exception report for the project board for a decision. It contains resolution options and recommendations.

Step 3 – The project board or project executive chooses from these options:

• reallocate project tolerances to resolve the breach of stage tolerances.
• reprioritize requirements to bring the stage back within tolerances.
• inform the project manager that they need more time for consideration.
• request an exception plan from the project manager.
• escalate to the business layer for advice and direction if project level tolerances will be breached.

Step 4 – The project manager stops the current stage and inserts a stage boundary to create an exception plan, and an end stage report.

Step 5 – The project board or project executive chooses from these options:

• reject the exception plan and request amendments from the project manager.
• reject the exception plan and direct the project manager to continue with the stage.
• approve the exception plan.

Step 6 – The project manager implements the exception plan as a new stage plan (the exception plan becomes the new stage plan).

Use of data and systems to support progress tracking and decision-making is key. Project data can take many forms – digital and non-digital and can include internal and external data. Using digital technology to plan and schedule projects makes for easier understanding of progress. Having data stored within systems means that past performance can be used to predict future performance. The project’s digital and data management approach explains what digital technology will be used as well as how the data will be used, and which systems will be used for data analytics.

At the end of the project the end project report is used to review how the project performed against the original approved version of the PID.

Relationships between the ‘progress’ practice and the principles are visible when checking the viability of the business case when progress is reviewed; when identifying lessons from the output of progress management; when clarifying reporting requirements and progress management responsibilities; when dividing the project into stages, authorizing one stage at a time, and evaluating progress; when setting tolerances and delegating authority from one level to the level below; when knowing the status of each product and the project product during delivery; and when defining the approach to controlling progress, setting tolerances and controls based on the project’s specific needs.

References