16
Initiating a project
This chapter covers:
•reviewing and confirming the business justification
•defining the approaches for managing risk, quality, benefits and communication
•setting up the project controls
•setting up the first stage (agreeing the PID and plan)
•guidelines for tailoring products and roles
16 Initiating a project
The purpose of the initiating a project process is to establish solid foundations for the project, enabling the organization to understand the work that needs to be done to deliver the project product before committing to a significant spend.
The objective of the initiating a project process is to ensure that there is a common understanding of:
•the reasons for doing the project, the benefits expected and the associated risks
•the scope of what is to be done and the products to be delivered
•how and when the project product will be delivered and at what cost
•who is to be involved in the project decision-making
•how the quality required will be achieved
•how baselines will be established and controlled
•how risks, issues and changes will be identified, assessed and controlled
•how progress will be monitored and controlled
•who needs information, in what format and at what time
•how the corporate, programme management or customer method will be tailored to suit the project.
Figure 16.1 provides an overview of initiating a project.
Initiating a project is aimed at laying down the foundations in order to achieve a successful project. Specifically, all parties must be clear on what the project is intended to achieve, why it is needed, how the outcome is to be achieved and what their responsibilities are, so that there can be genuine commitment to it.
The initiating a project process enables the project board, via the directing a project process (see Chapter 15), to decide whether or not the project is sufficiently aligned with corporate, programme management or customer objectives to authorize its continuation.
If, instead, the organization proceeds directly from starting up a project (see Chapter 14) to controlling a stage (see Chapter 17), then it may risk committing significant financial resources to a project without fully understanding how its objectives will be achieved.
All activities within the initiating a project process need further consideration if the relationship between the customer and the supplier is a commercial one (e.g. the reasons for undertaking the project as defined in the supplier’s business case may be different from those defined in the customer’s business case).
During the initiating a project process the project manager will be creating the suite of management products required for the level of control specified by the project board. The project manager should have agreed (as part of the initiation stage plan) the means by which the project board will review and approve the management products; the two extremes are one at a time or all at once.
The activities within the initiating a project process are project manager oriented and are to:
•agree the tailoring requirements
•prepare the risk management approach
•prepare the change control approach
•prepare the quality management approach
•prepare the communication management approach
•set up the project controls
•create the project plan
•prepare the benefits management approach
•assemble the project initiation documentation.
The activities to establish the approaches for the project may be executed in parallel, but it is recommended that the communication management approach is completed last as it will need to include any communications required by the other approaches.
The approaches are derived from corporate, programme management or customer strategies, standards or practices that the project needs to comply with, and the customer’s quality expectations captured in the project product description. When the approaches have been defined, it is possible to set up the project controls and create the project plan. These are parallel and iterative activities as:
•each control will need time and resources to operate, which will need to be documented in the project plan
•there may be additional controls required as products and activities are identified in the project plan.
After the controls have been established and a project plan created, it is then possible to complete the business case because forecast time and costs of developing the project product, and managing the project, are now fully understood.
The final activity in the initiating a project process is to assemble the project initiation documentation. This is a compilation of all the documentation developed during initiation that will be used to gain project board approval to proceed.
16.4.1 Agree the tailoring requirements
The project manager may need to tailor how the project is directed and managed in order to recognize internal and external factors that affect the way in which the project is delivered. Any deviations from the organization’s standard project management approach must be documented and agreed.
Figure 16.2 shows the inputs to, and outputs from, this activity. For more details on tailoring, see sections 4.1 and 4.3.
PRINCE2 recommends the following actions:
•Review the project brief to understand the outline tailoring approach (if defined).
•Seek lessons from similar previous projects, corporate, programme management or the customer, and external organizations, related to how tailoring was applied.
•Define the tailoring as part of the PID and create initial project controls.
•Consult with project assurance to check that any proposed tailoring will meet the needs of the project board and/or corporate, programme management or the customer.
•Seek project board approval for any tailoring (although they may prefer to review it later as part of the PID).
Table 16.1 shows the responsibilities for this activity.
Table 16.1 Agree the tailoring requirements: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The complete list of responsibilities for each product is shown. Where a product is produced, reviewed or approved in another process, the responsibility is shown in parentheses, as in (P), (R) or (A).
16.4.2 Prepare the risk management approach
The risk management approach describes the goals of applying risk management, the procedure that will be adopted, the roles and responsibilities, the risk tolerances, the timing of risk management activities, the tools and techniques that will be used and the reporting requirements. For more on risk management, see Chapter 10.
Figure 16.3 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Review the tailoring approach included in the PID and its implications for risk management.
•Review the project brief to understand whether any corporate, programme management or customer strategies, standards or practices relating to risk management need to be applied by the project.
•Seek lessons from similar previous projects, corporate, programme management or the customer, and external organizations related to risk management. Some of these may already have been captured in the lessons log.
•Review the daily log for any issues and risks related to risk management.
•Define the risk management approach.
•Consult with project assurance to check that the proposed risk management approach meets the needs of the project board and/or corporate, programme management or the customer.
•Create the risk register in accordance with the risk management approach, and populate it with any risks from the daily log.
•Seek project board approval for the risk management approach (although the project board may prefer to review it later as part of the PID).
Table 16.2 shows the responsibilities for this activity.
Table 16.2 Prepare the risk management approach: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The complete list of responsibilities for each product is shown. Where a product is produced, reviewed or approved in another process, the responsibility is shown in parentheses, as in (P), (R) or (A).
16.4.3 Prepare the change control approach
Change control is essential for the project to maintain control over its management and specialist products.
The level of control required will vary from project to project. The maximum level of control possible is determined by breaking down the project’s products until the level is reached at which a component can be independently installed, replaced or modified. However, the level of control exercised will be influenced by the importance of the project and the complexity of the relationship between its products.
The change control approach will define the format and composition of the records that need to be maintained (see Appendix A, section A.3). For more details on change control, see Chapter 11.
Figure 16.4 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Review the tailoring approach included in the PID and its implications for change control.
•Review the project brief to understand whether any corporate, programme management or customer strategies, standards or practices relating to change control need to be applied (including any that are contractual requirements).
•Seek lessons from similar previous projects, corporate, programme management or the customer, and external organizations related to change control. Some of these may already have been captured in the lessons log.
•Review the risk register and daily log for risks and issues associated with change control.
•Define the change control approach.
•Consult with project assurance to check that the proposed change control approach meets the needs of the project board and/or corporate, programme management or the customer.
•Create the initial configuration item records, if used.
•Create the issue register and consider whether any issues already captured in the daily log need to be managed formally and therefore transferred.
•If any new risks or issues are identified (or existing ones have changed), update the risk register, issue register and/or daily log.
•Seek project board approval for the change control approach (the project board may prefer to review it later as part of the PID).
Table 16.3 shows the responsibilities for this activity.
Table 16.3 Prepare the change control approach: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The complete list of responsibilities for each product is shown. Where a product is produced, reviewed or approved in another process, the responsibility is shown in parentheses, as in (P), (R) or (A).
16.4.4 Prepare the quality management approach
A key success factor of any project is that it delivers what the user expects and finds acceptable. This will only happen if these expectations are both stated and agreed at the beginning of the project, together with the standards to be used and the means of assessing their achievement. The purpose of the quality management approach is to ensure such agreements are captured and maintained. For more details on quality management, see Chapter 8.
Figure 16.5 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Review the tailoring approach included in the PID and its implications for quality management.
•Review the project product description to understand the customer’s quality expectations and to check that the project’s acceptance criteria are sufficiently defined.
•Review the project brief to understand whether any corporate, programme management or customer strategies, standards or practices relating to quality management need to be applied by the project (in particular whether the customer and/or supplier has an existing quality management system that should be applied to aspects of the project).
•Seek lessons from similar previous projects, corporate, programme management or the customer, and external organizations related to quality management. Some of these may already have been captured in the lessons log.
•Review the risk register and issue register for issues and risks associated with quality management.
•Define the quality management approach.
•Consult with project assurance to check that the proposed quality management approach meets the needs of the project board and/or corporate, programme management or the customer.
•Create a quality register in readiness to record details of all quality activities.
•If any new risks or issues are identified (or existing ones have changed), update the risk register, issue register and/or daily log.
•Seek project board approval for the quality management approach (although the project board may prefer to review it later as part of the PID).
Table 16.4 shows the responsibilities for this activity.
Table 16.4 Prepare the quality management approach: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The complete list of responsibilities for each product is shown. Where a product is produced, reviewed or approved in another process, the responsibility is shown in parentheses, as in (P), (R) or (A).
16.4.5 Prepare the communication management approach
The communication management approach addresses both internal and external communications. It should contain details of how the project management team will send information to, and receive information from, the wider organization(s) involved with, or affected by, the project. In particular, if the project is part of a programme, details should be given on how information is to be fed to the programme.
If a formal stakeholder engagement procedure is needed (such as that described in section 7.3.9), this should also be documented as part of the communication management approach and should record the types of stakeholder, desired relationships and key messages, approaches for communication, and methods for evaluating the success of communications.
Figure 16.6 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Review the tailoring approach included in the PID and its implications for communication management.
•Review the project brief to understand whether any corporate, programme management or customer strategies, standards or practices relating to communication management need to be applied by the project.
•Seek communication management lessons from previous projects, corporate, programme management or the customer, and external organizations. Some may already have been captured in the lessons log.
•Review the risk register and issue register for risks and issues associated with communication management.
•Identify and/or review stakeholders, and consult them for their information needs:
•identify desired relationships
•clarify key communication messages
•determine desired outcomes from successful communications.
•Establish the information needs associated with the quality management approach, the risk management approach and the change control approach.
•Define the communication management approach.
•Consult with project assurance to check that the proposed communication management approach meets the needs of the project board and/or corporate, programme management or the customer.
•If any new risks or issues are identified (or existing ones have changed), update the risk register, issue register and/or daily log.
•Seek project board approval for the communication management approach (although the project board may prefer to review it later as part of the PID).
Table 16.5 Prepare the communication management approach: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The complete list of responsibilities for each product is shown. Where a product is produced, reviewed or approved in another process, the responsibility is shown in parentheses, as in (P), (R) or (A).
Table 16.5 shows the responsibilities for this activity.
16.4.6 Set up the project controls
The level of control required by the project board after initiation needs to be agreed and the mechanism for such controls needs to be established, as does the level of control required by the project manager of the work to be undertaken by team managers. Project controls enable the project to be managed in an effective and efficient manner that is consistent with the scale, risks, complexity and importance of the project. Effective project controls are a prerequisite for managing by exception. Project controls can include:
•the frequency and format of communication between the project management levels (see Chapter 7)
•the number of management stages and hence end stage assessments (see Chapter 9)
•mechanisms to capture and analyse issues and changes (see Chapter 11)
•mechanisms to monitor tolerances and escalate exceptions (see Chapter 12)
•tolerances for delegated authority (see Chapter 12)
•how delegated authority from one level of management to another will be monitored (see Chapter 12).
Many of these controls will have been defined in the project’s approaches but not necessarily set up. The focus of this activity is to establish such controls and to make sure that they make sense as a coherent set. Figure 16.7 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Review the tailoring approach included in the PID and its implications for project controls.
•Review the quality management approach, change control approach, risk management approach and communication management approach to identify which controls need to be established.
•Actively seek lessons from similar previous projects, corporate, programme management or the customer, and external organizations related to project controls. Some may have been captured in the lessons log.
•Review the risk register and issue register for risks and issues associated with project controls. The aggregated set of risks will have an impact on the scale and rigour of control activities.
•Confirm and document the management stage boundaries required to provide the appropriate level of control.
•Allocate the various levels of decision-making required within the project to the most appropriate project management level. Establish any decision-making procedures that may be appropriate, possibly by tailoring procedures within an existing quality management system or other standard procedures.
•Incorporate the agreed decision-making authority and responsibility into the project management team structure and role descriptions where appropriate; this may include finalizing any roles not previously allocated, re-allocating roles previously filled and, if necessary, redesigning the project management team.
•Confirm the tolerances for the project and the escalation procedures (from team managers to project manager, project manager to project board, and project board to corporate, programme management or the customer).
•Summarize the project controls in the PID.
•Consult with project assurance to check that the proposed project controls are consistent with the nature of the project and meet the needs of the project board and/or corporate, programme management or the customer.
•If any new risks or issues are identified (or existing ones have changed), update the risk register, issue register and/or daily log.
•Seek project board approval for the project controls (the board may review them later as part of the PID).
Table 16.6 shows the responsibilities for this activity.
Table 16.6 Set up the project controls: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The complete list of responsibilities for each product is shown. Where a product is produced, reviewed or approved in another process, the responsibility is shown in parentheses, as in (P), (R) or (A).
16.4.7 Create the project plan
Before committing to major expenditure on the project, the timescale and resource requirements must be established. This information is held in the project plan and is needed so that the benefits management approach can be prepared and the project board can control the project.
Planning is not an activity that the project manager performs in isolation but, rather, something that should be done with close involvement of the user(s) and supplier(s). It is often useful to hold planning workshops to help identify all the products required, their details and the dependencies between them.
For more details on planning, see Chapter 9.
Figure 16.8 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Review the project brief to:
•understand what the project is to deliver and check for any predetermined milestones as defined in the project brief
•check whether there are any corporate, programme management or customer strategies, standards or practices relating to planning that the project needs to follow
•check understanding of any prerequisites, external dependencies, constraints and assumptions documented in the project brief
•check understanding of the selected solution.
•Review the tailoring approach included in the PID and its implications for planning.
•Seek lessons from similar previous projects, corporate, programme management or the customer, and external organizations related to planning. Some of these may already have been captured in the lessons log.
•Review the risk register and issue register for risks and issues associated with planning.
•Decide on the format and presentation of the project plan, given the audience for the plan and how it will be used (e.g. is it sufficient to use a product checklist for presenting the plan to the project board?). See the product description for a plan in Appendix A, section A.16, for more information.
•Identify any planning and control tools to be used by the project.
•Choose the method(s) of estimating for the project’s plans.
•Review the quality management approach, risk management approach, change control approach and communication management approach to understand the resources, standards, methods and costs for the work to be carried out.
•Create a product breakdown structure for the project product and its major components, write product descriptions for these, and devise a product flow diagram; include them all in the project plan. Identify the arrangements for the transition of the project product into operational use. If the project product is likely to require maintenance when operational, then plan for a suitable service agreement or contract to be drawn up between the support group and the user. In such instances, it will be necessary to include any agreement as a product in the project plan.
•Consider whether the project product description needs to be updated (e.g. if the understanding of the acceptance criteria has changed or been refined in the course of initiating the project).
•Create or update the configuration item records, if used, for each product to be delivered by the plan.
•Identify and confirm resources required. Confirm the selected people’s availability, their acceptance of these roles and their commitment to carry them out. See Chapter 7 for more details.
•Identify the activities, resources and timings for the project controls and include them in the plan.
•Document the project plan.
•Consult with project assurance to check that the proposed project plan meets the needs of the project board and/or corporate, programme management or the customer.
•If any new risks or issues are identified (or existing ones have changed), update the risk register, issue register and/or daily log.
•Seek project board approval for the project plan (although the project board may prefer to review it later as part of the PID).
Table 16.7 shows the responsibilities for this activity.
Table 16.7 Create the project plan: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The complete list of responsibilities for each product is shown. Where a product is produced, reviewed or approved in another process, the responsibility is shown in parentheses, as in (P), (R) or (A).
16.4.8 Prepare the benefits management approach
The outline business case produced during starting up a project needs to be updated to reflect the estimated time and costs, as determined by the project plan, and the aggregated risks from the updated risk register.
The detailed business case will be used by the project board to authorize the project and provides the basis of the ongoing check that the project remains viable. For more details on business justification, see Chapter 6.
Figure 16.9 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Review the project brief to check whether there are any corporate, programme management or customer requirements for the format and content of a business case.
•Seek lessons from similar previous projects, corporate, programme management or the customer, and external organizations related to business case development. Some of these may already have been captured in the lessons log.
•Create a more detailed business case with the additional detail gained, namely:
•the costs and timescale as calculated in the project plan
•the major risks that affect the viability and achievability of the project (from the risk register)
•the benefits to be gained
•the tolerances permitted for each of the benefits.
•Create the benefits management approach:
•review the tailoring approach, as included in the PID, and its implications for benefits management
•review the business case and check understanding of the benefits expected of the project
•identify the management actions required to ensure that outcomes are likely to be achieved
•identify how the realization of each benefit/dis-benefit is to be measured and capture the current baseline measures
•identify the timing of benefits reviews (most likely to align with management stage boundaries)
•if the project is part of a programme, the benefits management approach may be created, maintained and executed at the programme level.
•If any new risks or issues are identified (or existing ones have changed), update the risk register, issue register and/or daily log.
•Consult with project assurance to check that the proposed business case and benefits management approach meet the needs of the project board and/or corporate, programme management or the customer.
•Seek project board approval for the business case and benefits management approach (although the project board may prefer to review them later as part of the PID).
Table 16.8 shows the responsibilities for this activity.
Table 16.8 Prepare the benefits management approach: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The complete list of responsibilities for each product is shown. Where a product is produced, reviewed or approved in another process, the responsibility is shown in parentheses, as in (P), (R) or (A).
16.4.9 Assemble the project initiation documentation (PID)
There needs to be a focal point at which all information relating to the ‘what, why, who, how, where, when and how much’ of the project is:
•gathered for agreement by the key stakeholders
•available for guidance and information for those involved in the project.
This information is collated into the PID. The PID is an aggregation of many of the management products created during initiation and used to gain authorization for the project to proceed. It is not necessarily (and rarely) a single document, but a collection of documents or other forms of information (such as flip-charts, data in software tools, etc.).
The version of the PID created during the initiating a project process, and used to gain authorization for the project to proceed, should be placed under change control. It will be used later as a means to compare the project’s actual performance against the original forecasts that formed the basis of approval.
Figure 16.10 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Extract and, if necessary, revise information from the project brief.
•Include or reference information in the:
•project’s management team structure and role descriptions
•business case
•quality management approach
•change control approach
•risk management approach
•communication management approach
•project plan.
•Include or reference the project controls and summarize how the project has tailored PRINCE2.
•Assemble the project initiation documentation.
•Carry out a cross-check of the information in the various elements to ensure that they are compatible.
•Consult with project assurance to check that the assembled PID meets the needs of the project board and/or corporate, programme management or the customer.
•Prepare for the next management stage (which triggers the managing a stage boundary process).
•Request authority from the project board to deliver the project.
Table 16.9 shows the responsibilities for this activity.
Table 16.9 Assemble the project initiation documentation: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The complete list of responsibilities for each product is shown. Where a product is produced, reviewed or approved in another process, the responsibility is shown in parentheses, as in (P), (R) or (A).
The activities in this process may be combined, split or run concurrently to suit the project’s circumstances.
The number of management products created in this process can look daunting and, together, may imply a level of detail that is not always needed. This process lays the foundation and it is here that tailoring for the project is primarily decided.
Tailoring is needed to suit a project’s circumstances but it may not always be obvious, at the start of initiation, what the relevant factors are. At such an early stage in the project, there may not be enough information; tailoring needs will emerge as the initiation work progresses. For this reason, it is better to start ‘simple’ and then elaborate if needed, rather than create a management environment suitable for a hypothetical major project.
Some projects are too complex to have a full definition of the project’s output (and hence a project’s final products) agreed by the end of this process. In such cases, it is common to have a project lifecycle with a number of investigative stages to look at options and choose a solution. In these cases, the initiating a project process is only used at the start of the first stage, to set up the management and control environment.
16.5.2 Tailoring products in initiating a project
Just because PRINCE2 has separate management products in this process, it does not mean each management product is reflected in a discrete and separate document or even as a document at all, where information and collaborative systems are used.
Table 16.10 relates to the baseline management products which are created in this process, whereas Table 16.11 relates to the records management products.
Table 16.10 Guidelines for tailoring baseline management products in initiating a project
Management product |
Tailoring guidelines |
PID, comprising: •detailed business case •risk management •quality management •change control •communication management •project plan •project controls •tailoring of PRINCE2 |
The PID may be a single document which includes all the components, a set of separate documents or any combination of documents and data. Change control may be known by other names in some industries/environments (e.g. asset management or parts management). The project plan may be informal or formal, depending on the context. It may be a single document which includes the project product description, product descriptions and benefits management approach. The project plan may include components in any format commensurate with the complexity of the project, with views ranging from a simple list of accountabilities, products, activities and dates, Gantt charts or product backlog. The plan may be held totally or partially within a planning tool(s). |
Benefits management approach |
The benefits management approach may be combined with the detailed business case, either in the body of the document or as an appendix. |
Table 16.11 Guidelines for tailoring records management products in initiating a project
Management product |
Tailoring guidelines |
Risk register |
The risk register may be a part of a workbook containing issues, assumptions and decisions. |
Issue register |
The issue register may be a part of a workbook containing issues, assumptions and decisions. As issues do not all result in changes, the issue register may be split into a change register (for recording and tracking change requests) and an issue register for all other issues, such as suggestions, concerns or queries. Similarly, ‘off-specification’ issues may also be held in a separate log. |
Quality register |
The amount of information included in the quality register can vary considerably, depending on the extent to which quality metrics (e.g. ‘defect counts’) need to be analysed for process improvement purposes. |
16.5.3 Tailoring roles in initiating a project
This manual shows the creation of these management products as the responsibility of the project manager. Project support may be responsible for some supporting products, but in all cases the project manager is responsible to the executive for how the project is run. The project manager may therefore assign whoever is appropriate to the tasks. Often support may be provided by a higher-level programme office or similar.
For more guidance on roles, see Chapter 7.
16.5.4.1 Initiating a simple project
Initiating a simple project is likely to be less formal than for a larger project, with management products combined into a small number of documents. The project manager may also be acting as a team manager for one or more work packages.
16.5.4.2 Initiating projects when using an agile approach
At the start of the project it may not be certain that an agile delivery approach is appropriate for some or all of the specialist products. It is during the initiating a project process that the decision is likely to be made on what parts of a project are best approached using agile and which not. Agile is more likely to be appropriate when the end product needs to be developed iteratively, provided the project management team understand the approach and implement a control system which deals with a more volatile environment.
The project product description (and the business case) should be defined with more focus on how the outcome can be described so that the outputs can evolve during the project. If the project product description is based only on the solution, there is more likely to be a focus on this rather than the value to be delivered.
Product descriptions can be written in the form of epics or user stories as long as they meet the requirements of the product description outline. These then represent the project’s ‘requirements’.
The mapping of existing agile roles to the PRINCE2 roles should be defined and understood (e.g. how the team manager role will be fulfilled).
Levels of uncertainty need to be explicitly stated as these may affect the choice of agile techniques such as the use of prototyping, spikes or experiments and the choice of how long to make the management stages and the timeboxes within them.
16.5.4.3 Initiating a project from a supplier perspective
Some of the initiating a project process activities will be undertaken pre-contract as the supplier will need to formulate the approaches, plans and controls in order to assess the viability and desirability of the proposed contract, together with the costs and prices of the proposed solution. The initiating a project process is not completed, however, until contract negotiation has concluded and the customer’s project board authorizes the project.
On large projects, some suppliers may be identified during the course of the project and their contracts negotiated subsequently. The project board will have to allocate a budget, with defined tolerances, to account for these contracts.
16.5.4.4 Initiating a project within a programme
All the guidance provided above is applicable to a project within a programme. The main difference is that the programme manager may prescribe or constrain the project manager’s choices. In some cases, the PID (or parts of it, such as the detailed business case) might be produced by a member of the programme team, and may even exist in detail prior to initiating the project or be included in the programme’s business case.