APM PMQ Exam Preparation
1.1 differentiate between types of permanent and temporary organisation structures (including functional, matrix, and project)
■ Permanent structures have stable teams for routine/operational work whereas specific initiatives, like projects, will have temporary teams. These will be established to manage activities and resources, in order to deliver specific objectives within predetermined time frames. Business as usual (BAU) or operations within an organisation are permanent structures that need specific resources to carry out routine tasks. In this case, a stable team is best to fulfil the role. By being stable, the team will be specialists within the role and therefore bring efficiencies to the tasks. A project environment is temporary, where the tasks are varied and unique, therefore the environment is more suited to temporary teams who bring different skills to the tasks as required. The matrix structure is one of the most common temporary structures used to manage projects, where authority is balanced between the functional line manager and the project manager. The project manager works across both temporary and permanent structures.
■ A matrix structure provides a mix of skilled resources on a temporary basis to the project whereas a project structure provides skilled resources permanently to the project. Having a temporary set of resources can be an advantage to the project as they only need to be part of the team for the specific tasks required, and then return to the permanent organisation structure or be assigned to another project. In a project structure, if there is no available task for a more permanent team member, they can still be assigned to the project but not providing output. Within the matrix, however, allowing the resource to leave the project when there are no suitable tasks available, runs the risk of not getting the same individual back on the project when they are next needed, therefore missing continuity and potentially decreasing productivity.
■ While the matrix structure is particularly effective the individual is dual reporting into the project manager, as well as their functional line manager, getting directions from both. This requires good interpersonal relationships, as well as regular effective communication between all areas of the organisation. This results in more complex communication channels than would exist in a functional structure and could allocate more work for the individual than they have capacity for doing, so it can be challenging for the individual. Alternatively, having the chance to communicate and be visible to senior managers within an organisation can be advantageous to an individual as they can learn from the advice and instruction given. In a functional organisation, the individual will take instruction from a functional line manager only and therefore the line of communication is more straightforward.
■ A project or matrix structure will provide more varied amount of work than a functional structure. For an individual working on a project in a project structure, they may not only get to work on the tasks that exactly match their capability, but they will also likely work on many different tasks on the project to help progress the work. Within a functional or matrix environment, the individual will be allocated tasks that match their capability, and these tasks could be repetitive. Although, in the first instance, this would be good for the individual to establish their skills, over time they will find the work monotonous.
1.2 explain the way in which an organisational breakdown structure is used to create a responsibility assignment matrix
■ The OBS details the organisation for the project and the resources available. The WBS details the tasks needed on the project to deliver the scope of work in a hierarchical structure. When an OBS is combined with a WBS, it clarifies the roles against the tasks. The project manager can further combine the OBS and the WBS in a RAM, allocating the tasks in the WBS to team members defined in the OBS. For each task, the project manager will decide whether the team member is Responsible, Accountable, Consulted, or Informed. By creating a RAM, the project manager and team are clear on who is responsible for each task defined in the WBS, and the level of accountability or contribution expected from named roles or individuals within the project. Initial escalation routes are also clear, so it aligns with good governance.
■ For the team to fully understand their roles and responsibilities, the project manager could use a workshop to discuss and understand everyone’s input to the project delivery. Within the workshop, the project manager could present the OBS and WBS and together with the team members, decide on everyone’s role within the project. This could be captured as a RAM with everyone buying in to who is responsible for a task, who is accountable, who could be consulted and who needs to be informed.
1.3 explain the role and key responsibilities of the project manager
Role:
■ Manage the project day to day to ensure successful delivery of outputs. The project manager is appointed to this role to provide a single point of contact responsible for leading the project to deliver the project objectives. The project manager communicates with all the project stakeholders keeping them informed of progress or providing them with information in accordance with the governance of the organisation. The project manager will organise, motivate, and lead the team in their activities, ensuring the right skills and knowledge are available to perform the work required.
Responsibilities over the course of the life cycle:
■ Defining and planning the project by creating the project management plan (PMP) during the definition phase. The PMP contains the information identified and defined by the project manager and the project team and is used to guide the project. It documents how the project should be delivered, who is involved, how much it will cost, what processes should be followed etc. The project manager creates the PMP to ensure that the information in the business case is fully understood and the project’s objectives are fully defined, to enable the project to deliver to time, cost, and quality/performance objectives.
■ Create a project schedule during the definition phase. The project manager will need to work within the initial timescales outlined within the business case for the project. To create a project schedule,the project manager will need to define the project scope and have estimated the tasks defined for the project. The project schedule will comprise of a series of tasks for the project with interdependencies where necessary. In creating the project schedule, the project manager will understand the critical path for the project and identify any risks there might be to deliver on time.
■ During the definition phase define the project scope and clarify in the business case. To get the best possible plan in place for the project, the project manager will need to work with the team, subject matter experts and the end users to define the project scope in full. This can be done using the product breakdown structure (PBS) and work breakdown structure (WBS), ensuring work packages are allocated and the responsibilities identified to deliver the project successfully.
■ Estimate project tasks during the definition and deployment phases. The project manager will need to estimate the project tasks to understand the overall cost of the project. Estimates will also need to be done to understand the amount of time the various project activities will take. The project manager may be able to provide these estimates, or they may need to coordinate activities with various project stakeholders to get the best possible estimates for the project. By estimating project tasks, the project manager can then create a realistic schedule and budget, which is monitored and reported against.
■ Monitor and control the project progress during the deployment phase. The project manager will need to monitor project activities, both against the timeline as well as against the budget allocated to that activity. They will understand the progress against that activity and, if necessary, employ some controlling actions to remedy issues. The project manager will also need to report progress to the various project stakeholders in accordance with the project communication plan, managing sponsor and user expectations. They will need to work with the project sponsor, informing them of progress, seeking direction when necessary to aid success and enabling timely decisions to be made to ensure project success. Reporting should also be done in accordance with organisational governance requirements.
■ Motivate and lead the project team throughout the life cycle. The project manager is responsible for building and leading the project team, motivating them to execute their tasks as efficiently as possible throughout the project. By ensuring the team is motivated to do the work, they are more likely to find creative solutions to project challenges.
■ Identify and manage risks throughout the project. The project manager needs to identify uncertain events which can influence the project objectives. By doing this, they can then assess these risks and decide on an approach to mitigating them. This helps increase the likelihood of project success by taking a proactive approach to dealing with project challenges. The management of project risks is an ongoing process as not all risks will be identified at the start of the project; the project manager will need to ensure that there is a regular review of risk management and keep the sponsor and senior management team informed of progress/problems/issues.
1.4 differentiate between the responsibilities of the project manager and the project sponsor throughout the project
■ Business case - The project sponsor develops the business case during the definition phase and maintains ownership of the business case throughout the project. Whereas the project manager is responsible for delivery of outputs capable of achieving the business case benefits during deployment, the project sponsor will identify the business change and coordinate the justification of this change within the business case. This can include the appointment of a project manager to support and contribute to the contents required of the business case. It is valuable for the project manager to get involved at this concept phase so that they fully understand the justification for the project, the high- level scope of work and the high-level risks. Once the business case is approved for the project, the project manager will take responsibility for the delivery of the outputs of the project to achieve the benefits as defined in the business case.
■ The project sponsor provides ongoing support to the project manager throughout the project life cycle whereas the project manager focuses on the delivery of the project outputs. Once the business case is approved, the project manager takes responsibility for the delivery of the project. However, the project sponsor will perform a support role for the project manager throughout the project life cycle as well as overarching governance. This allows the project manager to focus on the delivery of the project outputs by planning what needs to be done and monitoring and controlling the project activities against the plan.
■ The project sponsor is a decision maker on behalf of the business at phase reviews whereas the project manager provides the input to phase reviews. They will review the information and progress achieved so far and review whether the project is on track to deliver the benefits as defined in the business case. The project manager will provide the sponsor with all the relevant information so that they are able to make an objective decision to either go on to the next phase of the project life cycle or terminate the project if necessary.
■ The project sponsor communicates the vision and sets the high-level expectations during the definition phase. The project manager works to get the best from each member of the project team throughout the project. The sponsor is likely to be a member of the senior management team within the organisation and fully understand the organisational strategy. Therefore, the sponsor will be best placed to communicate the vision for the project and the high-level expectations of what the outputs and benefits deliver. The project manager is closer to the project team and will therefore communicate the vision to the team; while doing this they will also try and understand the strengths of each individual team member and empower them.
■ The project sponsor is responsible for securing funding for the project while the project manager manages and reports on the budget. The sponsor will work with the senior management team of the business to get the right funding for the project; they are best placed to do this as they are likely to be senior themselves. The project manager will work with the funding provided, defining the project scope, timescales and resources needed. Then they will manage the project against the budget and report on progress to the sponsor.
1.5 describe other roles within project management (including users, project team members, the project steering group/board and the product owner)
■ Users: identify project requirements ensuring objective separation of musts and wants. Actively participate as a member of the project team, identifying project constraints and dependencies. As subject matter experts, answering any questions the project team might have about the scope of work or the benefits required. Define the project’s acceptance criteria during the concept and definition phase of the project. Users are usually involved in testing the project outputs and assisting the project manager with handover and acceptance of deliverables into business as usual (BAU).
■ Project team members: provide input to planning, as required. Perform project tasks as instructed by the project manager or the team leaders to deliver project outputs. Report on progress of achievement against the project plan, or their part of it and managing communication with stakeholders as assigned in the communication plan. Support in identifying project risks, report to the project manager for inclusion onto the project risk register and take ownership of risks, if best placed to do so. Identify changes and report to the project manager so that changes can be assessed formally through a change control process. Contribute to the evaluation of the project at all stages and reviews.
■ Project steering group/board: can also be known as the governance board, project board or steering committee. They have responsibility for the project’s feasibility, business case and achievement of outcomes. Guide the project in line with the strategic aims of the business. Review project reports and support the project manager with any higher-level decisions that need to be made that have potential to impact the business case. Ensuring that strategies to address potential threats are approved and threats are regularly reassessed, resolving any disputes that may arise. Authorise the business case on behalf of the organisation, sanctioning a release of funds for the project to progress. Decide on any escalated issues from the project manager, either by giving the project manager resources to address the issue removing the challenges affecting the project objectives or rejecting the issue.
■ Product owner: leads the focus on product development acting as the intermediary between stakeholders and project team members, creating vision and defining goals for the operability of the project’s outputs. Acts as the on-site customer for iterative or agile projects; iteration planning and prioritising activities for the next iteration. Accepts incremental delivery, performing a role to accept the function or scope as complete. Define scope of work (stories) and may assist with estimating and sequencing. Communicates with stakeholders to ensure that the project remains aligned with business objectives.
1.6 describe the functions and benefits of different types of project office (including project/programme/portfolio management office (PMO), embedded PMO, central PMO and hub-and-spoke PMO)
PMO functions:
■ The PMO will consist of administrative personnel who can support the project manager by performing the administrative activities. Examples of these are: taking minutes at meetings and distributing actions to various stakeholders; distributing project reports to the relevant stakeholders; arranging team meetings; and distribution of new information to the relevant stakeholders.
■ Collecting progress information. The PMO could assist the project manager by collecting and analysing information from the project team and inputting into the reporting template(s) for the project. They may even populate tracking metrics from the information provided by team leaders and interdependencies to present to the project manager. The project manager can then use this information and finalise the report by adding any other progress that they may think necessary for onwards submission to senior stakeholders.
■ Centre of excellence and ownership of tools and techniques. The PMO could be the formal owners of the company’s tools and techniques, procedures and processes. By being the central function for these artefacts the PMO can ensure that every project has the right tools available to them. The PMO could also review lessons learned from projects and if necessary, add/update the central pool of tools, techniques, procedures, and processes so that the business is continually improving and moving forward to target higher levels of maturity. They will also provide training and support to projects.
■ Assurance. The PMO are independent of projects and therefore can conduct and support audits on projects. They can also perform health checks and reviews to support phase reviews and inform senior stakeholders of project status. They may also support change control audits, checking traceability of change.
PMO benefits:
■ Frees up the project manager’s time. Providing support with administrative activities on projects can help free up the project manager’s time. Having personnel who are focused on administrative activities is also likely to ensure that the documentation set for the project is up to date and that the project team are in receipt of the right information as the PMO will have the appropriate time to perform these tasks.
■ Provision of a consistent set of processes across the business produces efficiencies. The PMO support the project by providing the most appropriate processes, the consistency will support resources moving from one project to another, and the familiarity of these make the resources more efficient.
■ Sharing and applying lessons learned to new projects. By having a central function available to collate project information, items like lessons learned can be kept centrally meaning they are more likely to be readily available to new projects. The shared information about what works and what does not work in similar contexts will support new projects.
■ Embedded PMO benefit: An embedded PMO is where the PMO functions are delivered under the control of the project/programme/portfolio manager. This is more effective and responsive for the project/programme/portfolio that it supports, however the project/programme/portfolio will need to justify the investment. The resources within an embedded PMO may have a more detailed understanding of the project/programme/portfolio that they are supporting and may be able to provide more targeted input to support the project manager.
■ Central PMO benefit: A central PMO is flexible and effective in supporting many projects, providing the service to multiple projects. Projects due to their size may not always have the luxury of having the support of a PMO, however with a central PMO the function is available to all projects.
■ Hub-and-Spoke PMO benefit: A hub-and-spoke PMO is a hybrid form of Central and Embedded, where there is a central PMO supporting the business and a smaller embedded version sitting within the individual project or programme. This can provide an effective way of supporting the project/ programme while still supporting the central function with feedback on project information and the effectiveness of processes, with both the business and the projects benefitting from this arrangement.
1.7 explain why aspects of project management governance are required (such as the use of: policies, regulations, functions, processes, procedures and delegated responsibilities)
■ Use of policies within an organisation: the policies of the business provide guidelines as to what the business expects of projects. They outline the boundaries for the business, influence how projects are conducted and demonstrate the culture of the organisation. Projects can adhere and refer to these policies directly, however it is more likely that processes and procedures are derived from these policies to provide more specific instruction to support governance of projects. This can involve having a recognised project life cycle to follow and a way to transfer governance through phases with various control points, such as decision gates, audits, and evaluation reviews ensuring effective quality management.
■ Use of regulations ensure conformance to standards and facilitates full disclosure in reporting. By conforming to organisational standards, the projects will provide sufficient reporting and control activities to ensure that senior stakeholders are kept informed of progress. These stakeholders are also provided with enough information to make decisions. The regulations will also ensure that the work adheres to legal, regulatory, corporate, ethical and professional standards.
■ Use of defined processes, procedures and functions standardise methods of working and provides a structured methodology for the delivery of projects. This ensures consistency of practice throughout the whole organisation. Within an organisation, it is best practice to have a bank of processes, procedures, and standardised functions in place for the project community to follow and use. These could include best practice principles to be undertaken with the project management plan (PMP), ways to manage project risks, how a project should monitor and control the budget, which life cycle to follow etc. Using standardised functions allows methods of working to also be standardised. It’s therefore easier to move resources between projects, provide oversight of the project and allow easy comparison between projects.
■ Use of delegated responsibilities clarifies roles and increases efficiency. Good governance expects that the roles and responsibilities of the team and wider stakeholders are clearly defined. Doing this will ensure that everyone has clarity on what is expected of them, allowing prompt attention and control of risks and issues as well as efficient and effective decision making. Use of a responsibility assignment matrix (RAM) can support this activity as it can show whether the project has the right capacity and capability to deliver the work.
2.1 differentiate between linear, iterative and hybrid life cycles
■ A linear life cycle is sequential whereas an iterative life cycle repeats one or more phases of a project life cycle. A linear life cycle may be chosen for a project where the expectation of each phase is known and therefore provides a clearer framework for the team to follow. This is suitable for stable, low-risk environments. Control and information are passed on to the next phase in a linear life cycle when predefined milestones have been reached and accomplished. The final desired state or project output is only available during the transition (final) phase of the life cycle. An iterative life cycle repeats one or more of the phases of a project or programme before proceeding to the next one with the objective of managing uncertainty of scope by allowing objectives to evolve as learning and discovery takes place.
■ A linear life cycle is suitable for projects with greater structure whereas an iterative life cycle is beneficial for evolving objectives or solutions and is commonly used in agile development projects. Linear life cycles are suited for projects with clearly defined outputs and assumes the availability of relatively perfect knowledge upfront; this is likely to have been defined early in the concept phase and developed within the definition phase of the life cycle.
■ In a project with clear scope, a linear life cycle is used as the clarity of scope allows the project to move through the phases of the life cycle smoothly but is therefore resistant to change. It can also create silos by dividing knowledge into distinct phases and can prevent the sharing of knowledge between individual phases of work. An iterative life cycle allows the project manager and team to develop functions of the project iteratively, so is best used when the project scope is vague, and the solution is unclear. This way, the project manager and team can observe the benefits the staged functionality delivers and tweak the next iteration accordingly. Uncertainty regarding the scope is managed by allowing objectives to evolve over the course of the life cycle as learning and discovery take place.
■ A hybrid life cycle adds iteration to a linear life cycle enabling a mix of approaches. This can allow the project manager and team to choose the best of both linear and iterative life cycles to develop the project in the best possible way. For example, if the requirements are not clear for the project, then using an iterative style to gather the requirements and following it up with deployment is beneficial. Alternatively, if there is already a fixed requirement set, the iterative style can be used during deployment to develop the output. This allows the project team to develop the functionality of the project iteratively, allowing deployment of initial capability followed by successive deliveries that add further functionality.
2.2 explain why projects are structured as phases in a linear life cycle
■ Clearer identification of priorities and appropriate focus on the work which is currently taking place. Within a project environment it can be tempting to move forward into the doing of the work to create outputs without adequately spending the time developing the initial idea or a detailed plan. For example, by putting the structure of a linear life cycle in place, the project manager and team are guided to consider all that is needed in the earlier phases. This helps them to be better informed and put better plans in place to generate the right output.
■ More effective stakeholder communication. For example, project reviews could be undertaken with the end users during each phase enabling more regular consultation and greater transparency on the expected delivery outputs. Organisations can use phase reviews at the end of each phase of the linear life cycle to review the project and check that it is still on track to deliver the benefits as defined in the business case. The end of each phase in a linear life cycle will have predefined milestones and requirement of what the project should have achieved. This transparency will allow for maximum control and governance over the project.
■ More effective risk assessment – a staged approach to risk management ensures that focus can be maintained on critical areas of risk over the course of the life cycle. This in turn facilitates greater control as the sponsor and the project manager can review objectives and tolerances and make appropriate changes to baseline requirements where necessary to ensure the project can continue.
2.3 differentiate between a project life cycle and an extended life cycle
■ A project life cycle contains the phases up to handover and closure, whereas an extended life cycle goes beyond the handover and closure phase to include the benefits realisation phase.
■ A business delivering the project on behalf of a customer may use the standard project life cycle, as they are likely to complete the contract at the handover of the project to the customer (end user). The extended life cycle is suited to projects that are funded within the organisation and are making a change to the business, for example, an extension to a production line. In this case, it is best if the project uses the extended life cycle so that the project team supports the embedding of the project. This way, the team can also trace the immediate benefits realised as the project goes operational and gives immediate feedback to the organisation on the realisation of benefits.
■ Within the project life cycle, accountability for the output is handed over, whereas in the extended life cycle governance and accountability for adoption of the output stays within the project until the change is fully embedded. For example, the project could be part of a programme; in this situation the project will only be concerned with delivering the output into the programme, and therefore the standard life cycle is appropriate. However, if the project is expected to incorporate the management of change and the realisation of benefits then the extended life cycle is more suitable. Within the extended life cycle the accountability and governance of the project benefits stays with the same team and therefore prevents the formation of knowledge boundaries between project teams and operations.
■ Scope planning, benefits planning and financial planning for projects with extended life cycles needs to be completed early on, to incorporate the supplemental activities during the early stages. The income, capital expenditure and operational expenditure considerations associated with the supplemental activities need to be addressed and accounted for during the concept and definition phases. The responsibilities for the benefits realisation should also be assigned during these phases.
2.4 outline the role of knowledge and information management to inform decision making
■ Status reporting - Knowledge and information management can help the project manager to better understand the status of the project in relation to cost, schedule and quality against the acceptance criteria in the project management plan (PMP).
■ Estimating - Knowledge and information management can help make available data from previous projects which can facilitate more realistic schedules and costs to be established for the project. This can be done by reviewing past projects performed by the organisation and understanding how long tasks have taken, which in turn informs plans for the new project.
■ Risk identification - Knowledge and information management activities can help the project manager to identify risks on a new project with facilitated risk workshops for example, and to determine the need for any subsequent corrective action to be undertaken or escalation to be made.
■ Problem solving and option appraisals - Knowledge and information management can help the project manager to generate options and solutions to solve project problems and issues. The project manager will not only use their knowledge of what worked in the past, but will harvest ideas from the team members and subject matter experts who will bring their own information and knowledge to support the project.
■ Availability of information - Knowledge and information management can help the project decision makers at key points, such as gate reviews, by ensuring the relevant information is available in an appropriate format.
■ Knowledge and information management can help the project manager to understand when best to schedule quality assurance and quality control activities for the project. Again, this can be done by assessing what was done on past projects and by understanding the optimum times within a project life cycle to schedule these activities to maximise the findings.
2.5 explain the benefits of conducting reviews throughout the life cycle (including decision gates, benefits reviews and audits)
■ Decision gates in linear life cycles will be event driven and lead to increased senior stakeholder involvement. Decision gate reviews are held at the end of each stage within the life cycle. They are held primarily to gain agreement from the sponsor and wider governance board, which often will be the senior management team within the business, to move onto the next stage. These reviews will check that the project is still on track to deliver the benefits as defined in the business case. The benefit of these reviews is that the senior management team are involved in the decision-making process and their experience and understanding of the business strategy will support the project going forward, or, if necessary, the decision to stop the project will be made.
■ In an iterative life cycle, decision gates will be time-bound rather than event driven. Time-bound project or product reviews may be undertaken by the team at the end of each timebox. These reviews enable rapid checking of iterations or deliverables and agreement of changes to be incorporated in the next timebox and to consider how they would work more effectively.
■ Benefit reviews will be held during benefits realisation typically 6–12 months after handover and may be repeated during the operational life. These are intended to check that the project achieved the business benefits identified within the business case and to put into place any actions or improvements needed to support the realisation of the benefits. These may be carried out by the project sponsor and to be reported back to the business, using the information to support any further improvements needed.
■ Reviews or stage reviews are held during the life of a project to ensure that various criteria, important at that point, are met. The sponsor is accountable for ensuring the relevant authorisations are in place between stages to prevent work being completed out of compliance or at risk. It is important to involve both the project team and the wider business in these reviews. Various types of review can be held during the project life cycle, each being conducted for a specific reason. For example, project evaluation reviews can be held either regularly or on an ad-hoc basis. The reasoning behind these reviews would be to check the progress of the project against the project success criteria and against the timelines and budgets baselined in the project management plan (PMP). These reviews are a learning opportunity and will inform the senior management team of the status of the project, and will ensure that any project support needed, or improvements required are understood and actioned.
■ Audits provide independent compliance assessment. Projects audits are held to check that the project is following the agreed governance and processes as defined within their quality management plans and that these processes are aligned with achieving the objectives and realising the intended benefits. Audits will be conducted by personnel independent of the project or by the Project Management Office where there is one. By performing audits, the business is provided with an independent assessment of compliance which will increase stakeholder confidence in the project and how it is being managed. Independent audits can also benefit projects as best practice and knowledge can be identified and shared within the organisation.
2.6 explain why projects may close early
■ No longer aligned to organisational objectives and business strategy. A project can be implemented over long timescales; during this time, a business will be routinely checking that they have the right strategy in place to deliver organisational objectives. Therefore, this could be a circumstance where the project, although it may be on plan, may no longer feed into and align to the business strategy. At this point, the project may be closed early.
■ Planned benefits no longer available. A project’s benefits will be defined during the concept phase of the project and the project is justified because of these. However, as the project is developed there is a need to keep checking that the benefits are still available to the business when the project is delivered. Circumstances outside the project may change, for example, the project may have been defined to deliver a market-leading product, but another organisation could bring a better product to the market earlier. At this point, the organisation may choose to close the project early.
■ Results of earlier work are not favourable or become less favourable as more information is known. Evidence may come to light highlighting that the level of investment required can no longer generate the value needed. For example, a project, due to its uniqueness, may encounter many challenges over the course of its development. These challenges may cause the work to go over budget or affect the schedule. They could also force the project to reconsider the scope of work. The governance of projects within an organisation should put periodic checks on project progress; projects might also need to meet certain criteria to get through phase reviews. If the challenges encountered and the methods of overcoming them have changed the project beyond what is acceptable to the organisation, then they may choose to close the project early.
3.1 differentiate between projects and business as usual (BAU)
■ A project is timebound whereas business as usual is ongoing. When a project is justified in the concept phase, there is also input on when the business needs the project to be delivered. The timescale is decided based on the need for the project outputs and the benefits that follow; this timescale could also feed into the return-on-investment calculations to check on the overall viability. Putting more detail into the project schedule is therefore a priority for the project manager when planning the project, in order to meet the defined milestones. Business as usual is generally the operation of the business, for example, a production line within a factory. This type of work is a continual set of tasks.
■ A project is unique whereas business as usual is repetitive. A project delivers a set of outputs in a defined timescale with a new project team. One or more elements within the project environment will be different which is why each project is unique. Its intent is to deliver output that will make a step change within the business or for a client’s business. Within business as usual, the same set of tasks will be repeated in the same way in similar timescales. This is important as this makes the business as usual (BAU) team efficient and ensures that the output is the same.
■ A project’s team is dynamic whereas business as usual will have a stable team. Due to the unique nature of the project, the project team will need to be multi-skilled, it is also likely that the team may increase and decrease as the tasks and schedule demands. This will ensure that the project is being performed as efficiently as possible. Within the business-as-usual environment, the work is ongoing and repetitive, so it is best that a stable team, skilled appropriately, is allocated to these tasks.
3.2 differentiate between project management, portfolio management and programme management
■ Project management is focused on delivery of specific objectives for change, whereas programme management is focused on achieving beneficial change through both projects and business as usual (BAU) activities. Project management will follow processes and methods to support the delivery of the project objectives. The project manager will also use their skills and experience to lead the project to a successful delivery. Programme management will coordinate a set of related projects and business as usual ensuring that the priorities are clear and communicated across all the related projects and business-as-usual processes/tasks/actions. When the projects deliver their outputs, these will then be used to achieve the benefits.
■ Programme management is focused on coordination of projects and business as usual, whereas portfolio management is focused on an organisation’s capacity to deliver. Programme management will understand the beneficial change to be delivered and will communicate the priorities and manage the high-level risks across the projects and business as usual within the programme to achieve this. Portfolio management is focused on the overall strategy for the portfolio, prioritising projects and programmes based on the resources available to deliver.
■ Portfolio management is focused on the selection and prioritisation of projects and programmes to deliver strategic objectives, whereas project management is focused on delivery of change to achieve specific objectives. Portfolio management selects and prioritises the various projects and programmes based on the calculated return on investment. The project will already have been justified and given the go- ahead and therefore the project manager is focused on the delivery of the outputs. Although successful delivery of outputs will likely support delivery of strategic change, this isn’t necessarily guaranteed.
■ The reason that there are differences between how projects, programmes and portfolios are managed is to ensure that the span of focus is appropriate to the requirements, skills are correctly deployed and decisions are taken by those in the most suitable positions. Corporate governance is met by setting authority at different levels within the organisation.
3.3 outline the relationship between programmes, projects and strategic change
A programme is a unique, transient strategic endeavour undertaken to achieve beneficial change and incorporating a group of related projects and business-as-usual activities.
A project is a unique, transient endeavour undertaken to bring about change and achieve planned objectives and may or may not be part of programme.
Both projects and programmes can bring about strategic change; the decision to choose either a project or programme depends on several factors:
■ If the scope is complex and there is a need to embody the change organisationally then a programme is the best choice. If the scope is simpler and the embodiment of the change is not as wide ranging, then a project is the best choice.
■ If the scale and complexity of the requirement is large then a programme should be considered whereas a project is more suited to a smaller scale, simpler requirement.
■ If the risks are identified as quite low, then a project may be the best route for the change required, however if the risks are severe, then it may be better to deal with the change in a programme.
■ If the strategic change needs to be delivered through business as usual (BAU) activities, as well as a project, then a programme would be recommended.
3.4 describe situations where the use of programme management may be appropriate
■ When the scope of the business change is not fully defined. By considering this situation as a programme, it is possible to define an early project in the programme as a ‘fact finder’, for example a feasibility study which provides further information about what is required to deliver the business change. Once these early projects are completed, the subsequent project or projects can then be planned with more certainty given that the scope is better defined.
■ Where there is a higher amount of uncertainty. By splitting the overall requirements into several phases and defining each phase as a project, it is possible that the level of uncertainty can be spread across the projects and managed accordingly. Each project will follow the same risk management process for the risks contained within each phase. This will allow the earlier projects to mitigate the threats and hopefully reduce the risk level across the programme.
■ Where there is a complex set of dependencies and outputs. By understanding the various dependencies and outputs, the programme manager can divide the programme into several projects and simplify the complexity by allocating each project their set of requirements and outputs. In dealing with these within the projects, if further problems arise, then these can be escalated to the programme manager who can consider options such as solving the problem on the current project or pushing it onto the next project to be included as a requirement.
■ Where a more effective change delivery is required as project interdependencies are managed to greater effect, allowing them to have the greatest chance of delivering their benefits without adverse effect on business as usual. It is likely that projects within the programme will have a complex set of dependencies and outputs, which would be more difficult to deliver as individual projects.
3.5 describe situations where the use of portfolio management may be appropriate
■ Ensuring the business meets legislation. Within any organisation, there is a need to be compliant with relevant legislation. A business may set a specific portfolio which has the responsibility for ensuring that the organisation is compliant. By coordinating the project and programmes to deliver compliance in this way, the business is streamlining the activities needed, ensuring consistency. Earlier projects may be investigative and trigger the need for further projects and programmes. For example, a banking environment could set up a portfolio to manage all the projects, programmes and business change activities needed to comply with GDPR.
■ Focus on moving into a new market. If an organisation has a strategy to move into a new market, then by setting this up as a separate portfolio, it is shielding the rest of the organisation from this work, allowing them to continue as normal. Within this new portfolio, the organisation will choose to allocate a number of resources, both people and funding, in order to pursue this goal. The goal can be achieved by setting up several projects and programmes, e.g. marketing, research, product development etc.
■ Where resources are limited. A portfolio will balance the usage across the projects, programmes, and business as usual to optimise benefits. Resource restrictions could be due to investment, skills or capacity limitations and a portfolio will balance any or all of these.
■ To structure the organisation’s investments. By placing the different investments and initiatives into portfolios, the organisation will optimise strategic benefits or operational efficiency. These can be measured and managed within the portfolio and the projects and programmes adjusted accordingly. This could mean creating and closing projects and programmes as required.
3.6 explain tools and techniques used to determine factors which influence and impact projects (including PESTLE, SWOT and VUCA)
■ PESTLE, refers to the Political, Economic, Sociological, Technical, Legal and Environmental influences that could impact the project
Political – a change of government may impact how funding is acquired for some types of project. Alternatively, a change in portfolio direction within an organisation (internal politics) could change the scope of a project, or even lead to its closure
Economic – understanding the impact of local, national and world market conditions on project funding. For example, ensuring that the stakeholders are adequately engaged in order to keep advocating the project in line with market conditions
Sociological – there is a need to understand the impact of the project on society, for example, the project could be the construction of a new rail line; some stakeholders will be supporters of the project, however, others will see the disruption as a negative and will protest the project. By recognising this, the project manager is better able to deal with the emerging risks from this situation
Technological – it is important to know the technological requirements of a project. It may have been planned using emerging technology, which would increase the risk. Conversely, it may be using tried- and-tested technology, which could become obsolete
Legal – regulatory considerations will need to be taken on most projects: health and safety, employment and contract law may apply. For projects being developed in foreign countries, the project manager will need to comply with the local legal system
Environmental – the project may well be constrained by environmental considerations, e.g. waste disposal. These need to be considered in the definition phase of the project life cycle so that the scope of work and estimates have been adjusted accordingly
■ SWOT, refers to understanding the Strengths, Weaknesses, Opportunities and Threats relating to the project.
Strengths – what are the strengths of the organisation? How will this influence/impact the project? Are there advantages to support the project?
Weaknesses – what are the weaknesses of the organisation? How will this influence/impact the project? Are there disadvantages to address and manage?
Opportunities – what are the elements in the world outside the organisation that the project could exploit?
Threats – what are the elements in the world outside the organisation that could be problematic for the project?
■ VUCA, refers to Volatility, Uncertainty, Complexity and Ambiguity relating to the project.
Volatility – what is unstable about this project? For example, the price of materials. By considering this, the project manager can either adjust estimates or identify risks in this area.
Uncertainty – what are the risks inherent in the project? What areas will have known activities with uncertain outcomes?
Complexity – how complex is the project? What is the source of the complexity? How can the project manager manage these complexities?
Ambiguity – even though the project manager and team have considered the risks currently known
for the project, there will remain things which are unable to be identified for the project. The project manager needs to consider how much the project could be impacted by these and put in place action to investigate.
By understanding the project environment, the organisation can decide on whether the objectives of the project are achievable. If they are achievable, then the project can be planned to deal with the points identified.
3.7 explain the impact of the legal and regulatory environment on projects (such as the impact on working conditions, risk management, governance and sustainability)
■ Working conditions: creating the right working conditions for the project in accordance with legislation. By putting the right working conditions in place for the project, the team members know that the organisation has their best interests in mind and consequently morale and productivity is boosted for the project(s). Healthy working conditions will also protect the wellbeing of the project team leading to less chance of accidents at work, and less illness, e.g. stress. All personnel must understand their duties of compliance.
■ Risk management: regulation may require specific risks to be assessed or shared with nominated roles. Within a project environment it is important that the project manager follows the processes and procedures as defined by the organisation, such as GDPR and health and safety. One of these regulatory aspects may be to manage project risks in accordance with a defined process. Within the overall organisational risk management policy, risks will need to be identified and assessed in accordance with the scoring mechanisms defined centrally. High severity risks will need to be shared with the senior management team, or project sponsor. This will help the business understand their overall risk profile across all the projects in the business and will also support the project manager to identify appropriate responses to mitigate the risk.
■ Governance: following processes and standards set by the organisation compliant with regulations. By doing this, the project manager and the team are following what is considered as best practice for the organisation, and therefore they will be familiar with these processes and standards and will be efficient in using them on the project. This will help the sponsor to make informed decisions about the business case realisation or appropriate corrective actions. An aspect of governance is likely to be the regularity of reporting for the project; by following this requirement, the project manager and team will know what needs to be reported and when. This helps the overall organisation know the status of all the projects being developed within the organisation and will therefore help inform areas like risk mitigation planning, change control and continuous improvement.
■ Sustainability: this involves balancing environmental, social, economic, and administrative aspects of project work to meet the current needs of stakeholders without compromising the needs of future generations. This involves both individual and organisation responsibility to ensure that the outputs, outcomes and benefits of a project are sustainable over their life cycles and during their creation, disposal and decommissioning. When considering various business cases for investment, the sustainability element of the project may well be a factor when deciding on the allocation of funding. Sustainability is more obvious in some industries than others, for example large-scale engineering and construction projects will often have an immediate impact on the environment, and therefore are also likely to have more legislative requirements to accommodate too.
4.1 explain the benefits, to a project, of a communication plan
■ Enhances stakeholder engagement: the communication plan will be created having identified and assessed the stakeholders of the project and therefore the target audience. Once this is done, the project manager and team can then decide the best way of engaging with the stakeholders and by documenting these actions in a communication plan, nothing gets missed. By implementing the plan, the project manager ensures that the stakeholders are adequately communicated with over the course of the project, with relevant information, so enhancing their engagement.
■ Records the best method of communication: once the stakeholders are identified and assessed, the communication plan can be used to record the best method of communicating with them. For example, within the office environment, provision of information by electronic media could be appropriate, however for stakeholders without frequent/consistent access to technology, the best method of communication could be face-to-face meetings or telephone discussions to avoid misunderstandings and potential sources of conflict.
■ Ensures a consistent approach to communication and responsibilities for delivering communication are assigned: once the communication is planned and documented in the communication plan, the project manager and team can then deliver messages to stakeholders using that framework in a structured and systematic way which has been approved in advance. By doing this, the plan ensures that even in the absence of the project manager, someone from the project team could pick up the communication plan and ensure that the right information is gathered and provided to the relevant stakeholders, avoiding the possibility of conflicting messages being delivered from different areas of the project.
■ This framework should set out the timing for the message: the communication plan should also document the regularity of information from task owners and teams to the various stakeholders. By doing this, the expectation of the stakeholder has already been identified and agreed. For example, the sponsor may need regular weekly meetings with the project manager as well as a monthly report. By documenting the requirement, it helps ensure that the project manager knows what information goes where and when and to which stakeholders.
4.2 explain the relationship between stakeholder analysis and an effective communication management plan
■ The stakeholders can be identified in several different ways. These can include workshops, discussions, review of organisational structures, review of previous similar projects or liaison with communication functions. These can either be easily identifiable groups or individuals or be less visible and will require greater thought.
■ It is important to identify the role of different stakeholders in relation to the project as well as their individual objectives and needs to establish the most appropriate means of engagement with them. This will help to foster positive stakeholder relationships and thereby improve the perception of the project, promoting support and motivation for the project.
■ Stakeholder identification is an integral part of project risk management as negative stakeholders can effectively present a high risk to a project. The project manager will need to identify these and establish mitigation.
■ Stakeholder analysis considers the status of a stakeholder and their interests in the project and the potential impact of those interests on project viability. It should also be noted that many stakeholders will have conflicting interests and therefore it is impossible to please everyone, but the aim should be to ensure the highest possible satisfaction amongst stakeholders is achieved. This can be done by assessing their level of power or influence on the project and by also understanding their level of interest in the project. A more in-depth assessment could also understand their attitude towards the project. By understanding these two or three parameters, the project manager and team can then decide how they should engage with the stakeholder and document this within a communication management plan.
■ Maintaining relationships through the communication plan - A stakeholder with high power, high interest and positive attitude to the project may need regular communication to keep them engaged and on side. This stakeholder could be the project sponsor for example, and therefore this level of engagement would enable the sponsor to be fully informed and aware of the project status, consequently championing the project and supporting the project manager. This would be documented in the communication management plan, for example a weekly report by the project manager. By documenting, if the project manager is not available, a member of the team can see what needs to be produced and action the report.
■ Maintaining relationships through the communication plan - A stakeholder with low power, low interest and positive attitude to the project may need to be monitored and provided with some communication on an ad-hoc basis. By documenting this in the communication plan, it will capture who is responsible for this and what kind of media they could use. This would ensure that these types of stakeholders do not get ignored as a situation could arise on the project that could shift their level of power/interest/attitude and when this happens, at least the communication avenue is already open.
■ Building an understanding of the issues - A stakeholder with low power, high interest and positive attitude to the project would need to be kept informed of anything that could be affecting them. For example, this type of stakeholder could be a supplier where their remit is to deliver the goods or services in accordance with the contract. It is important to note in the communication plan how the project team plan to engage with this stakeholder and who should engage with them. Too many conversations between the project team and the supplier team can lead to conflicting information being given and therefore confusion, errors or unnecessary changes to the specification.
■ Building positive relationships - A stakeholder with high power, low interest would need to have considerable communication in the plan to ensure that they do not inadvertently cause issues due to being ill informed. It is not enough to simply send information as active engagement will be needed to develop their interest and ultimately to gain their support.
4.3 state factors which can positively or negatively affect communication
■ Location - Project team members can be located in different offices and locations around the world. This can negatively affect communication. The project manager can put systems in place to overcome the issues related to distance, such as virtual meetings.
■ Time zones, cultural diversity and language – These need to be considered and planned for. Project team members may not always speak the same language which could adversely affect project communication.
■ Skill and technical capabilities - Having a project team of varied skills and capabilities is inevitable, and this can lead to confusion over technical jargon used on the project. This will negatively affect communication if these terms are used without providing the necessary accompanying information such as technical summaries and glossaries and checking in advance that the participants have understood the technicalities to be discussed.
■ Body language - Non-verbal signals can affect communication and sometimes can have a greater impact than the words themselves. It is important to be able to control non-verbal signals so that these align with the message.
■ Physical environment – A suitable, safe and comfortable environment with necessary facilities will enhance the team’s experience. Distractions and noise can lead to a loss of focus and messages not being received correctly.
■ By being aware of the potential barriers, the project manager can ensure these are mitigated, for example by ensuring communication is more precise or that all parties have had the relevant training to operate the technology being used.
4.4 state sources of conflict within a project
■ Concept phase between the project sponsor and the organisation: Conflict securing funding or support for the project and obtaining business case approval
■ Concept phase between the end user and the project sponsor: Conflict agreeing the high-level scope of the project and balancing varying stakeholder influences
■ Definition phase between the project manager and project sponsor: Conflict if the scope of the project does not align with the project budget and project priorities
■ Definition phase between the project manager and the project sponsor or organisation: Conflict establishing the various project management plan components, for example, agreeing the resource plan and securing these resources for the project
■ Deployment phase between project manager and suppliers: Conflict maintaining resource availability and commitment
■ Deployment phase between the project manager and the team members: Conflict if the plan, processes and methods are not being followed or not delivering the progress expected and deadlines are not being met
■ Transition phase between the end user and the project manager: Conflict if the project does not meet its acceptance criteria, or end-user expectations.
4.5 explain ways in which conflict can be addressed (such as Thomas Kilmann Conflict Mode Instrument)
■ Avoiding the conflict. An individual may choose to avoid the conflict by ignoring or withdrawing from it or choosing to suppress it. This could be considered suitable when an issue is trivial, more important issues are pressing, or they want to avoid an overt disagreement. An individual might choose to avoid conflict with another person by retreating from the situation, trying to stifle conflict or put problems on hold with a view to avoiding overt disagreement.
■ Accommodating the conflict. An individual will choose to yield to the other person’s point of view because they believe that the relationship with the other person is more important than the situation, to maintain cooperation, harmony and stability.
■ Compromising. This is a middle position within the Thomas Kilmann model. In the compromise situation, both parties will try to find a mutually agreeable solution to the situation through negotiation. Both parties will exchange concessions to reach a middle ground. No one party wins or loses.
■ Collaborating. When collaborating, both parties are willing to work together in a highly cooperative, highly assertive way until they resolve the situation. They will strive for an integrated win-win solution which satisfies both parties. The conflict will require time to explore the issues and find a consensus-based solution through sharing of ideas and information. This approach will develop strong relationships. This is a ‘win-win’ approach.
■ Competing is when the parties compete so that one party wins and the other loses, adopting a battling and competitive style and forcing submission of the other party. This may be necessary where a quick solution or decision is necessary, where emergencies occur or where unpopular decisions need to be made for the overall benefit of the project or the organisation. This is a ‘win-lose’ approach.
4.6 explain how to plan and conduct negotiations (including ZOPA, BATNA and ‘Win Win’)
It is important to plan for a negotiation scenario, to ensure that the best outcome is reached for both parties. When planning for negotiation, the following should be considered:
■ Your own objectives and criteria – fully understanding your objectives and desired outcome is imperative prior to negotiation as well as your best alternative to a negotiated agreement (BATNA)
■ BATNA – best alternative to a negotiated agreement – this is the best fallback position for the negotiation; it is also good to understand what the other party’s fallback position might be. By understanding the BATNA for both parties, then the Zone of Possible Agreement (ZOPA) is identified.
■ ZOPA – Zone of Possible Agreement – by understanding the ZOPA in any negotiation, parties understand their bargaining range where both parties’ minimum targets overlap. When there is an overlap, there will be a successful outcome to the negotiation. Final agreement can take place anywhere within the ZOPA range.
■ BATNA and ZOPA both enable negotiation. If neither party is prepared to move from their most favourable position (MFP), then negotiation cannot take place.
■ Other party objectives and how these might influence one’s own objectives – Forming an understanding of the other party’s objectives will help support the direction to take during the negotiation. For example, understanding what concessions may need to be made and setting out the bargaining framework for these. Doing this ahead of the negotiation will allow planning some ‘what if’ scenarios to pre-empt what could happen during the negotiation.
■ Win-Win scenarios – These would be achieved through a collaborative approach using problem-solving skills, more advanced communication and by developing strong trust-based relationships.
5.1 explain how leadership impacts on team performance and motivation (using models such as Maslow, Herzberg and McGregor)
How leadership is exercised in a team has a big impact on how the team is motivated, therefore affecting team performance. Examples of leadership qualities are being a good communicator, someone that leads by example, providing clear vision and direction and feedback. A good leader is someone who encourages and supports, making people feel valued. They have an ability to empower and to adapt to both the changing needs of people and different focus points throughout the project.
There are many theoretical models that discuss leadership and how this relates to the project team, some of which are summarised below:
■ Maslow: using Maslow’s hierarchy of needs, the leader can support team performance by identifying which level of need the team member is seeking to address. Within the hierarchy, each need must be satisfied in turn and once satisfied then ceases to continue to motivate. Motivation will derive from individuals looking to move to the level above. The leader should first seek to satisfy the lower-level needs, for example survival, security, and safety, before focusing on satisfying the individual’s higher- level needs, such as social needs like belonging, acceptance and ultimately self-actualisation (just satisfying self-esteem by praising an individual will not motivate them to do better unless the lower-level needs such as survival are satisfied). By recognising each of these levels in turn, the leader will again seek to get the best out of each individual.
■ Herzberg: according to this theory an effective leader would need to address “hygiene factors” for the individual and then focus on “motivators”. Hygiene factors to consider are working conditions, clear and transparent company policies, good working relationships, a fair salary etc. By addressing these hygiene factors, the leader removes potential job dissatisfaction, and they can then focus on motivators for the individual such as increasing job satisfaction providing opportunities for tangible results and recognising individuals when they achieve their goals. This will improve team performance by helping indifferent team members move into a motivated space.
■ McGregor: this theory considers that effective leadership comes from adapting the leadership style to the individuals in the team. The leader would determine whether their team members are theory X workers, where they dislike work and are naturally unmotivated to work, or theory Y workers, where they are self-motivated and creative, they are likely to enjoy work and take pride in what they do and will actively seek out greater degrees of responsibility. In reality, each team member will sit on a spectrum ranging from theory X to theory Y and therefore the leader needs to make sure that they adapt their leadership style accordingly. For example, if the leader thinks that everyone is a theory X worker, they will adopt an authoritative and autocratic style of leadership; where this could work for some, it may demotivate and under-utilise theory Y workers. Conversely, if they adopt an inclusive empowering and participative approach, theory X workers could miss a sense of structure and lose focus in the work. By understanding which approach to take with each individual and understanding that there will be middle ground between theory X and theory Y, the leader can adapt their approach accordingly and therefore get the best out of each team member.
5.2 explain why it may be necessary to change leadership styles to effectively support the management of a project
Leaders may need to adapt their style and approach depending on the level of skill and motivation of their team and the work at hand needing to be undertaken. This is called situational leadership and may happen in order:
■ To get the best out of project team members. A good leader will be quick to understand the project team’s individual strengths and weaknesses. By working with each team member, the leader will deploy differing styles of leadership depending on the individual. For example, a new team member with an appetite for learning and advancing within the project environment may need to be given a high amount of direction initially so that they fully learn and understand the tasks allocated to them. The leader can then progress into a coaching style. When a team is fully established and skill and motivation is high, the leader could take on an engaging style, and delegate responsibilities for tasks.
■ To deal with critical, urgent, or changing situations. With safety concerns, a leader may need to adopt a directive style to ensure actions are carried out as required. The style of the leader may also need to be more directive when the project team are responding to a change within the project. With any change, the team may need to be guided to understand the change, providing structure to deal with it. Once they are happy with the change and the way forward, the leadership style can change to a supportive, coaching, or engaging style empowering them to make the right decisions for the change.
■ At times of uncertainty within a project, the team may need the leader to create a supportive environment through coaching and engaging so that the team feels safe when working. By being supportive and less directive, the leader is demonstrating that they trust the team to cope with this project circumstance. This will make the team members feel valued and empowered.
5.3 describe the characteristics and benefits of effective teams and teamwork
Characteristics of teams and teamwork:
■ Clear roles and responsibilities – To ensure that every member of the team knows exactly where they fit in and what is expected of them. The project manager will need to understand the team member’s skills and knowledge to match these to the tasks allocated. The project manager will also need to understand the project tasks so that they are able to define the resources that will be required. Having clear roles and responsibilities will help ensure that team members are able to be effective and productive in their role, it will also ensure that all required project roles have been identified and allocated.
■ Open and clear communication – Will ensure that everyone understands the activities and that any problems that block progress are raised and quickly resolved. The project manager can facilitate this behaviour by leading by example and being open and honest with the team members. Open communication will promote innovation as individuals will be more motivated to try new things. Communication is also about listening to the needs of others, asking the right questions, and allowing the team a voice.
■ Common goals – which have been communicated to them via the project manager. All team members will know what is required to deliver the output necessary to achieve this goal.
Benefits of teams and teamwork:
■ Improved motivation through a sense of purpose and belonging – In an effective team, members will have a shared sense of accomplishment that will come through achieving a positive result, and the role that they play. This sense of purpose can help team members to strive to complete the project activities as efficiently as possible while delivering to the quality expected. A strong sense of belonging can also lead to good teamworking and collaboration, as the group works together and supports each other.
■ Good problem solving –A project manager can facilitate this by fostering an environment with open communication with workshops and meetings and by empowering the team members to work towards the common goal. Team members will be motivated by this and will therefore be more likely to share ideas, knowledge and experience to overcome problems. Teams are also more likely to feel more confident in being creative and innovative than someone working alone due to the sense of the risk being shared.
■ Increased productivity – An effective team can achieve more when the workload is shared according to assigned roles and responsibilities and skills and strengths. Productivity can be further increased by a team that understands each other’s strengths and weaknesses so that overall progress can be monitored and any issues addressed. Building trusted relationships and encouraging open communication allows the project manager and the team to provide support for each other, discuss project progress openly and suggest good ideas for solving any problems.
5.4 explain factors which impact on the leadership of virtual teams
■ Building trust can take longer with a virtual team so the leader will need to be aware of this and coordinate activities to help develop the trust. It can be difficult to develop trust between the team members when they are not co-located because they will not be seeing every aspect of each other’s daily work. It can also be more difficult to detect conflict developing within the team. The leader will need to hold regular team meetings allowing everyone to contribute, albeit virtually. They could also create opportunities for the various team members to talk directly with each other so that a level of mutual understanding starts developing. This could be a mixture of formal and informal meetings; chat options such as Microsoft Teams and making use of collaborative workspaces.
■ Culture can be different across a virtual team. The leader will need to instil the right behaviours, dealing with the various cultures as necessary and being appreciative of cultural nuances and expectations. The leader should promote listening and sharing each other’s perspectives. They can also ensure they convey project messages clearly, while respecting the culture and values of each team member. Building a clear identity for the project team can help with establishing team norms of behaviour, and common values, across different countries and organisational/department cultures.
■ Communication can be difficult with a virtual team. The leader needs to agree norms of communication to ensure that the same message can be understood by all the different members of the team. This can be more challenging with virtual teams as the leader may not be able to deliver the message in the same way, or at the same time, if the teams work in different time zones. It’s important to consider how to ensure consistency whilst adapting the needs of virtual teams, perhaps by using a combination of communication methods and checking in to ensure common understanding. Technologies can support this, such as virtual meetings, collaborative workspaces, email, chat technology, calls etc.
■ Ensuring contribution of all team members is more difficult with a virtual team. This can be due to individuals’ comfort using technical solutions, personal behavioural preferences or managing those who speak most and loudest or those who don’t speak at all. The leader should provide collaboration tools to suit all the virtual team, ensuring everyone is trained and comfortable with the technology. Opportunities to collaborate outside of meetings can be valuable, for example, sharing information ahead of time, allowing questions via email, using different virtual meeting tools etc.
5.5 explain factors which influence the creation, development and leadership of teams (using models such as Belbin, Margerison- McCann, Myers-Briggs, Hackman, Tuckman, Katzenbach and Smith)
There are many factors to consider when creating, developing and leading a team. The leader will need to understand the individuals within the team and their technical skills and experience. However, there is more to an individual than just the knowledge and experience they bring, for example, their social role, their level of motivation and what is going on in their home life. The leader will also need to understand the project itself and the context and environment in which it is being delivered. This context will also help the leader in prioritising the work that needs to be done, how direct they may need to be or how much support they are able to get from the organisation for the project.
Other factors that could be considered are the individual’s social role (refer to Belbin) and the clarity of the task (refer to Hackman).
There are many theoretical models that discuss leadership and team behaviours, some of which are summarised below:
■ Belbin: this model shows a number of roles that are optimal for an effective team. Individuals tend to have roles that they are most comfortable with, some roles they can perform for a limited amount of time, and some that they are least comfortable. From a leader perspective, if they understand how each individual in the team tends to behave and contribute and where their strengths lie, they can develop the team by utilising these strengths and behaviours. For example, if they have a team member who has high standards and a keen eye for detail, they may be exhibiting Completer Finisher tendencies. Regardless of their skill-led responsibilities on the project, they could also be used in a Reviewer role, contributing even more to the team’s objectives. It could be worthwhile in asking the team to undertake an assessment to identify their preferred roles.
■ Margerison-McCann: this model is similar to Belbin and works on understanding an individual’s preferred role within a team. The model explores how individuals relate to others, how they gather and use information, how they make decisions and how they organise themselves and others. If the leader understands these aspects of each team member, then they can select the team based on the complementary natures of the individuals. A mix of organisers, controllers, explorers, and advisers will ensure that the team is as high performing as possible.
■ Myers-Briggs: this model recognises that how individuals perceive a situation, along with their communication preferences, will influence how they react to the situation. If a leader understands this, then they are best placed to influence the perception or manage the reaction. The team member can be integrated into the project team and the project environment and is more likely to perform in accordance with the values of the team and the leader. If this can be done for all team members and they understand each other, then the team will develop quickly and the performance increase.
■ Hackman: this model suggests that five conditions need to be put in place for the team to be effective: the team must be a real team, rather than a team in name only; the direction of work is clear; its structure supports teamworking; the organisation is supportive; there is coaching available within the team. As a leader, the challenge is not only to put these conditions in place, but also to maintain them throughout the project.
■ Tuckman: this model recognises how a project team may take time to mature into a performing team. It is useful for the leader to find ways of getting the team through the Forming, Storming, Norming phases quickly because when they reach the Performing stage of team development, this is where they are extremely productive, supportive and trusting of one another. Within this phase, they feel they can achieve anything and work together to solve any challenges on a project. The leader may have to instigate different activities to get the team to this stage, for example team-building exercises, progress meetings which reward and recognise success, ensuring clarity of roles and responsibilities etc. The project manager has an important role in the fifth phase of Adjourning by preparing the team to disband.
■ Katzenbach and Smith: this model recognises that the more effective the group are as a team, the higher the performance. The leader can support this by developing the level of commitment, accountability and the skills within the team. They can put actions in place to ensure team members are clear on specific goals and the approach to the work, that they understand who is accountable, and have the right mix of skills to perform the work. This will increase the effectiveness of the group and therefore drive performance.
6.1 explain the importance of a business case throughout the project life cycle
■ Justifies the initial and continued investment in the project. During the concept phase the business case will contain enough information for the organisation to understand whether the project has enough justification for the funding/investment it needs. The business case should contain enough information to shape the project and provide enough detail to the senior management team for them to be convinced that the project gets the go-ahead. It contains detail such as the benefits that would come from successful project delivery. As a document, it will be reviewed periodically throughout the life cycle to ensure continued investment for the project. It will also be reviewed at the end of the project to check the deliverables against the business case.
■ Reviewed at gate reviews to check the viability of the project. The business case documents key information about the project, for example, high-level scope, deliverables, options for the project, return on investment, success criteria and benefits. During the definition phase the business case informs the development of the project management plan (PMP) and enables the project manager to agree success criteria with the project sponsor and other stakeholders. In the definition and development phases, the business case can be reviewed against progress made with the PMP, as well as checking progress against the benefits outlined. If the benefits are no longer viable, then the senior management team may stop the project.
■ As a contract between the project and the business. It ensures stakeholders are clear on what benefits should be achieved once the project has delivered the outputs as part of the deployment phase. The project manager will use the business case, which defines why the project is needed, as the starting point for developing the project management plan.
6.2 explain what is meant by benefits management (including identification, definition, planning, tracking and realisation)
■ Identification: Project benefits should be justified and measurable. Benefits depend on the delivery of outputs and the achievement of outcomes. Requirements are captured from sources such as the business case, and stakeholders. If benefits are not identified, then they will not be managed and return on investment could be missed.
■ Definition: This benefits management plan will define how the benefits will be managed through transition into operational use and the roles and responsibilities involved. It will also define how the benefits should be measured and the regularity of the management overview. Putting this plan together provides clarity on how benefits will be managed throughout the project and into business as usual (BAU). Each benefit (and disbenefit) should be documented in terms of priority, inter-dependencies, value, timescales, and ownership.
■ Planning: This stage involves capturing baseline measurements and agreeing targets. The plan should also outline the timeline and milestones for realising benefits and their dependencies on project outputs. It is important to understand this so that if the project outputs are challenged or changed during the deployment phase, the impact on benefits can also be assessed.
■ Tracking: Project benefits should be monitored as the project moves from handover to business as usual. Early in the life cycle the project manager and the sponsor agree what benefits are tracked and how to enable the necessary baseline measures to be set up. Monitoring can also be done throughout the deployment phase of the life cycle to ensure that the project outputs are still supporting the benefits identified at the start of the project. By tracking throughout, it will help to inform the project when changes are needed to the project scope or timescale.
■ Realisation: The realisation of benefits will come when the project outputs are embedded and the operation changes for the better. A change manager may be put in place to track the realisation and ensure that the change is permanent. The bulk of benefits may only be realised after the project is completed and therefore long-term actions and monitoring may be needed for continued realisation. This data will support new projects in the future, helping understand fully the actual return on investment of this type of project.
6.3 explain investment appraisal techniques used by a project manager (including Internal Rate of Return (IRR) and Net Present Value (NPV))
■ Net Present Value: A technique which uses the value of money across time to calculate the net return of a project over time and is often referred to as calculating the time value of money. In this calculation, the project manager will need to know how much the project is likely to cost and will also need to predict how quickly the project will generate an income/benefit and how much this income/benefit will be. As money devalues over time, this will need to be taken into account by discounting the income/benefit generated. The reduced returns are referred to as the discounted cash flow and the actual discount rate chosen is either the interest rate charged for the capital, or the return rate expected by an alternative opportunity. When analysing projects for investment, projects with a higher positive NPV are better candidates for funding. By using the NPV method to analyse return on investment, the time value of money is accounted for, which gives a more realistic view of the return than if a payback method is used.
■ Internal Rate of Return: A technique similar to Net Present Value, however it focuses on finding the discount value that will return a Net Present Value of zero. It is useful for comparing various investment options with equal timing and equal risk. When comparing projects, the higher the IRR percentage the more favourable the project is. Most organisations will have an IRR target, for example, projects generating IRR of less than 10% may not be an attractive option for investment. This target rate will also take account of other factors such as risk, margin, inflation, currency exchanges and any other aspect known at the time of the appraisal.
■ By using the IRR method to analyse return on investment, the time value of money is accounted for, and by working with a percentage value, it is easier to compare the projects. These techniques enable organisations to make an objective decision as to whether a project should be carried out from a financial point of view.
6.4 explain an information management process (including collection, storage, curation, dissemination, archiving and the destruction of information)
■ Collection: Consider what information is required and who would provide this.
The first stage in an information management process. The project manager should consider what information is required for the project and ensure there is a uniform filing structure available within the project’s document control system to accept this information. When this is done, they can then decide who to get the information from, and the regularity. The format of the data may be different from the various sources and therefore it may need to be handled/treated differently prior to storage. Consideration might also be given to understanding how and whether the data needs to be analysed. Additionally, there should be an effective way of classifying collected information to enable the project team to differentiate between information that must be acted upon, and is time sensitive, or information that is simply recording events.
■ Storage: Consider how information needs to be stored. At this stage, the project manager needs to understand how the data should be stored, e.g. digital or hardcopy. Other considerations would be around the security level of the storage and how to control access to the information. Data needs to be classified to establish any legal implications of storing such data, and the project manager would have to be aware of such legislation and ensure compliance. The project manager may also have to consider how often the information needs to be backed-up, although if stored digitally, this requirement might be taken care of by a central facility. If there is any special handling required for the project information, then this can be considered and actioned at this point.
■ Curation: Consider how to present the information.
During this stage, the information has already been collected and stored with consideration given on how to manage the data throughout the project life cycle including when it will no longer be required. The curation activity is to use the project information available and present it in a way that is useful to the audience, e.g. Red/Amber/Green reporting, Plan on a Page. Deciding on this will help the project manager understand how much time will be needed on project reporting and who is best placed to do this.
■ Dissemination: Consider who needs the information and how it is distributed.
It is important to know who should get information and how often they need it. This can be done by referring to the project’s communication plan. Consideration of how the information is distributed should be made, for example the security of the data and the method used to send the data. An audit trail of who receives the information, what version of the information and when they received it may be necessary for some projects.
■ Archive: Consider what information will need to be archived, in what format and for how long.
Projects generate a vast amount of information and data. When the project is handed over, the project information will usually need to be stored for a set period of time. The system used for the archive needs to be suitable, for example, aligned with safety and security of the information and any organisational, legal or regulatory policies. The project archive needs to be organised in such a way that information can be recovered as and when required – an auditable trail.
■ Destruction: Consider when and how the data will be destroyed.
At some point, the project information will no longer be required. It will then need to be destroyed in accordance with any regulatory or legal requirements. This may be several years after the project has been completed and the project manager is unlikely to be available for this activity. It is likely that this activity is the role of a central function within the organisation, for example, the PMO. The project needs to ensure that the central function is aware of the regulatory requirements for destroying data.
6.5 explain factors which would typically be reported on to help ensure successful project outcomes
■ Progress against the schedule: Understanding how the project’s tasks are progressing against the schedule will help the project manager assess progress on the overall project. If the project tasks are not progressing in line with the baseline plan, the project manager or task leaders may choose to put some controlling actions in place, e.g. changing the plan or adding more resources to the task. Early actions will support getting the project back on track, ensuring successful outcomes.
■ Project actual spend against the planned spend: this will allow the stakeholders to understand how the project is performing against a set spendcurve. If the project is overspending, the project manager will need to assess whether the overspend is valid or not, and if necessary, corrective action will be taken to bring costs back in line with agreed cost plan.
■ The project may use and report on earned value to not only track project spend but also to understand the value of the work achieved. If the project is under-spent against the planned spend line, knowing the value of work done at this point in time will help build a bigger picture of the current project status. For example, if the value of work done is equal to the spend then the project is achieving as estimated.
■ Number of non-conformances found in a quality audit or quality control activity. By understanding these numbers, the project manager will understand the quality of the outputs being generated. If there is a low number of non-conformances, then the project manager can be assured that the team are following the right processes in the right way to deliver the project output. They can also be satisfied that the output is being generated as expected. If the number of non-conformances is high, then the project manager needs to consider some recovery actions as it is likely the project will not deliver the output as planned.
Significant risks and issues. The risks and issues facing the project need to be monitored and managed.By including these in a project report, the sponsor and senior management team is given visibility. They can then see that the project manager is controlling the situation or if there is a need for further support to be given to the project, this can be provided in a timely way.
6.6 explain the relationship between the deployment baseline and the development of a project management plan in linear and iterative life cycles
■ The project management plan (PMP) details the who, how, when, where, what, how much and why. The deployment baseline details the scope, quality, resourced schedule, and associated cost. Both are written by the project manager and approved by the project sponsor. The PMP supports establishing a deployment baseline through clarifying stakeholder expectations, and then becomes the baseline which can be used as a reference point to manage progress.
■ For a linear life cycle: the deployment baseline is developed with a focus on fully-developed scope and quality. The project follows each phase of the life cycle in sequence. Within the early phases (concept and definition), the project baseline is developed. Given the use of a linear life cycle, there is an assumption that the scope is developed fully during the definition phase. Based on this well- defined scope and quality requirements, the project is fully defined and planned from start to finish. When all the elements of a full integrated project management plan, including scope, quality, resourced schedule, and associated costs are understood, a baseline can be established from which deployment can be managed and controlled.
■ For an iterative life cycle: the deployment baseline is developed based on the resources and schedule available to the project. The use of an iterative life cycle is suited to projects where the scope is not fully known or defined. What is fixed for projects in this scenario may be the resources available to develop the project and the schedule. From here, the deployment baseline focuses on the timeline and splits the project into several iterations. These iterations will help develop the project’s functionality, adding on to each previous iteration. Achievement of scope and quality may vary as the project develops and the team acts on new knowledge. Any work not achieved in an iteration is returned to the backlog.
6.7 explain the importance of producing a project management plan
To guide the project team. The project management plan (PMP) once produced and approved will guide the project team through execution. The PMP acts as a valuable source of clarification for the project manager of what is expected of them and the team by the project sponsor. It can also be used as induction material for new members of the team. It contains details of the scope of work, the project schedule, the budget and the roles and responsibilities of the project organisation. By defining this information in the PMP, the project team have a single point of reference that everyone can access to understand what is going on, when and what is expected of them.
■ To measure progress against the plan to monitor and control the project. When the project management plan is approved and baselined, the project can then progress in accordance with the PMP and progress can be measured and any variation can be reported against the plan. If the project deviates from the baseline, the project manager can then consider actions to bring the project back on track.
■ A contract between the project manager and the project sponsor. It is important for the project manager to fully understand what is expected of them prior to committing to deployment. The PMP acts as a valuable source of clarification in this respect, outlining agreement of the deployment plan, and delivery of outputs.
6.8 describe the typical contents of a project management plan
■ Scope: A description of the scope would be taken from the business case at first and then as the project progresses and nears deployment, it would become more refined. Also contained here would be detail of the acceptance criteria and any constraints.
Risk management plans: How the project intends to manage the risks and opportunities to minimise threats and maximise opportunities. Its contents will define how the risks will be identified, assessed and managed for the project. It will also define roles and responsibilities and regularity of risk management within the project.
■ Budget: The forecast costs of delivering the planned products of the project will need to be detailed and documented in the PMP considering the cost breakdown structure (CBS) which shows how the budget has been allocated to the work. To get to this budget, the scope of work will need to be defined and then estimated thoroughly. Some tasks may need to be performed by suppliers for the project and therefore the suppliers will need to provide estimates for the project which need to be incorporated into the overall budget. Budget forecasts for the project would be presented for the project duration.
6.9 explain approaches to producing estimates (including parametric, analogous, analytical and Delphi)
■ Parametric method: Used when there is a statistical relationship between historic data and other variables to calculate an estimate.
The method relies on having a set of historic data or ‘norms’ and therefore is not applicable to all situations. When applying ‘norms’ care is required to ensure that the actual conditions of the work being estimated are like-for-like and take account of such things as, skill levels and lost time factors. Where it is suitable, it can be quite accurate, e.g. construction of a house can be estimated on a square metre basis, given a bank of historical data.
■ Analogous method: Use of metrics from previous comparative projects to inform the estimates for the project.
This method is reasonably quick and is likely to be a way of getting initial estimates and is often referred to as an order of magnitude estimate. It can be common for this type of estimate to provide the basis for the decision to proceed with the project. The project manager will need to understand, at a high level, what the scope and deliverables are. They will also need to understand how the project compares against previous projects developed by the organisation, or others with information available.
■ Analytical method: Use of detailed work breakdown structures (WBS) with tasks being estimated at the lowest level and estimates rolled up to project level.
The project will need a detailed and accurate work breakdown structure to use an analytical or bottom- up method for estimating.
The project manager, depending on their experience and expertise, may be able to estimate the project on their own by analysing each of the project tasks and attributing an estimate to each and then rolling up these estimates to get a full estimate for the project. However, it is more likely that they will use project team members, such as workstream leads, subject matter experts or suppliers to provide estimates for the tasks in their domain, gather these estimates and then roll them up into an overall estimate for the project.
This estimating method is likely to be used when a more thorough cost estimate is required, or if there are no previous metrics to rely on. However, the method can be time consuming, and the project manager should guard against all contributors adding contingency within their estimates, which would provide an over-escalated overall estimate for the project.
Delphi method: Use of a set of experts to independently provide estimates for a task or project. The project manager may need to use the Delphi method to estimate specialist or new tasks for the project. The experts will each be asked to provide an estimate for a specific task along with their rationale. These estimates are then collated and summarised and re-sent to each expert who would be asked to revise their estimate. The idea behind this is that over time the experts’ estimates will converge for the activity and will therefore be more accurate.
It is recommended that the experts remain anonymous throughout the process so that no perceived bias is introduced. It can be a quick way of estimating, however maintaining the large data set can be challenging.
6.10 explain the reasons for and benefits of re-estimating throughout the project life cycle
■ Greater involvement of project team with clarifying scope: As the project progresses further, project team members will become part of the project organisation. They can apply their specific technical expertise to clarify what is required to achieve scope. Re-estimating, at this point, helps the project team to understand the impact of the clarification of scope on budget and timescales. The benefit of this is to increase the accuracy of the estimates against further clarified scope by technical expertise providing increased confidence in the delivery and confirming that the project will still be able to meet the success criteria. Alternatively, if the clarification has pushed the project boundaries, then it gives the project manager and team an opportunity to identify any further risks (threats or opportunities) that might become apparent, given the situation.
■ Increased likelihood of adhering to overall estimate: Re-estimating throughout the life cycle provides visibility of anticipated estimating variances enabling more targeted actions to be taken in response. Using the latest productivity data, allows the project team to have a better understanding of the final outturn costs and associated timescale for the project. The benefit of this is that it gives the project manager and stakeholders more confidence of the project’s performance in relation to the published estimates. If there is then a project-wide effect due to the estimating variances the project manager has the information to escalate to the project sponsor and, if necessary, draw down more funding from the business or negotiate more time to complete the project. The alternative to this would be to re-examine the scope of the project and de-prioritise.
■ Realisation of an accepted risk: Re-estimating at this point will allow the project manager to understand the impact of the realised risk on the project. The benefit of doing this is that the project manager will then be able to discuss the situation with the project sponsor and, if necessary, draw down contingency set aside for the project.
■ Reduced contingency reserves with an opportunity to incorporate lessons learned: At early stages of the life cycle there is a great deal of uncertainty and several assumptions are made to achieve an estimated value for time and cost. To manage this uncertainty an amount of contingency is reserved. As the project progresses re-estimating will take account of clarified scope to create a new estimate. As uncertainty reduces, the level of contingency can also reduce to match the increased certainty. At the end of stages the work which remains can be re-estimated to establish actual effort and cost of the work performed in relation to the estimate for that work. Variances and trends can then be incorporated into the estimates ahead with a view to adjusting these incorporating the review findings. The benefit is that the forecasts are more realistic and consider the current circumstances removing contingency reserves that are no longer needed.
6.11 explain the relationship between stakeholder analysis, influence and engagement
Stakeholder analysis supports stakeholder influence and engagement by identifying the views of stakeholders towards the project. This allows the project to develop the most appropriate engagement strategy, which will be different for different types of stakeholders, enabling the project team to plan the most appropriate engagement to optimise the effectiveness of their effort. Project managers should be aware of all stakeholders and their likely objectives, including everyone whose actions may change the course of the project.
■ A stakeholder analysed to have high power, high interest and negative attitude to the project may need intensive engagement from the project manager, and possibly the project sponsor or the senior management team, to try to change their attitude to be more favourable. The reason for doing this is so that the stakeholder does not create obstacles for the project so causing delays and costing money.
■ A stakeholder analysed to have high power, high interest and positive attitude to the project may need regular engagement to provide them with enough information to be able to support the project. This engagement would be designed to maintain the stakeholder’s commitment to the project, so that they can continue to champion the project and support the removal of any obstacles that could cause delays or cost money.
■ A stakeholder group analysed to have low power, high interest and positive attitude to the project may need regular engagement with just enough information to keep them on side. There is still a need to keep these stakeholders informed, as miscommunication or lack of communication can cause concerns within stakeholder groups. These concerns due to lack of communication could make the group negative towards the project, which could then cause challenges.
■ A stakeholder group analysed as having high power, low interest and a neutral attitude to the project will likely need to have regular engagement of specific information. For example, this could be a regulatory body like the Environment Agency or Health and Safety Executive. Providing specific information to these groups meets the regulatory requirement and keeps the stakeholder groups neutral towards the project.
■ A stakeholder group analysed as having low power, low interest and a neutral attitude to the project will likely need to have little engagement. Provision of some information will be needed but this can be just a newsletter or similar. This will free up resources to focus on engagement with others with more power and interest.
6.12 explain the importance of managing stakeholder expectations to the success of the project
■ To increase the likelihood of the project outputs being accepted. For smooth acceptance of the project outputs, it is important for the project manager and team to identify and engage with the end users and project sponsors as key stakeholders throughout the project. From the outset, the project manager should ensure that the output is meeting their needs as defined in the business case. By doing this, when the project is ready for handover and acceptance, the sponsor and end users are already familiar with the deliverables and they have sufficient satisfaction to enable a smooth transition into the operational environment.
■ Improved communications planning to obtain the appropriate level of support from stakeholders. Throughout the project the project manager will need to engage and liaise with the project sponsor and other stakeholders, to ensure that they are up to date with the project progress and understand the challenges the project may be facing. Not all stakeholders need to be aware of everything, but they will need to be ready to support the project as and when required. By keeping the sponsor and other stakeholders appraised as appropriate, they get early warning of any support the project may need when facing challenges and therefore help the project to deliver successfully.
■ To ensure the scope of work meets the needs of the project, reducing risk of misunderstanding the requirements. By communicating with the many stakeholders, the project manager is increasing the likelihood of having understood the requirements of the project thoroughly. Engaging with the right stakeholders to identify and assess any potential risks the project can be more accurately assessed, reducing the risk stakeholder needs are not being met. Getting to a fully defined, clear scope of work for the project means that the project will be better planned and more likely to be successful.
■ Ensuring a productive team is formed. Knowing the most appropriate engagement strategy to adopt for stakeholders will help to define whether they need a place on the project team, for example, considering suppliers as part of the project team. By keeping the team engaged with what the project is trying to achieve, and how successful they are, the project manager will keep the team invested in supporting the project delivery and maintaining motivation. By doing this and managing their expectations on what remains to be done, the team are more likely to remain focused to support and successfully deliver the project.
6.13 explain why a project manager would use earned value management
Helps the project manager measure and understand accomplishment against the plan. To use Earned Value Management on a project, the project needs to be planned both from a cost and schedule viewpoint. When this has been done, the project manager can then regularly measure the progress of the project in terms of Earned Value and using simple calculations to understand the project’s accomplishment against time and cost plans. These calculations are very dependent on the accuracy of the data. Once calculated they can be used to indicate to the project manager whether the project is ahead or behind the plan. This provides indication of whether the project manager needs to consider taking action and if so where to remedy performance issues.
■ Enables trend analysis to support project control. Earned Value can be monitored on a regular basis against the spend curve, which shows the cumulative funds that the project expects to consume throughout its duration. By doing this, the project manager can spot the progress trend for a project. If the project is varying by a tolerable amount away from the planned line, then the project manager may choose to monitor the situation. However, if this trend continues to deviate further from the plan, the project manager may revisit the planned line and the productivity and re-estimate the project. They may also choose to add more resources or consider other suitable actions to get the project back on track.
■ Enables understanding of performance variances against the plan. By looking at achievement of planned scope to the required quality and actual cost of the work that has been performed, the project manager can understand performance variances for schedule and cost. The project manager can also use these indices to reforecast the project and provide revised estimates at completion for the project. These can then be communicated to the sponsor.
■ Provide a pictorial representation of the project progress. By tracking the project’s Earned Value on an Earned Value graph, the project manager may choose to publish this as an indication of progress to the project team. This can provide the team with satisfaction, the motivation to remain on track or even improve productivity. Organisationally, these graphs can be shared with the senior management team, to support effective communication with stakeholders by giving them a quick summary of each project’s progress, allowing them to concentrate where support may be needed.
6.14 interpret earned value data (including variances and performance indexes)
■ When cost variance is negative, then the project is spending more than it is earning. Cost variance is a calculation of Budgeted Cost of Work Performed minus Actual Cost of Work Performed. When cost variance is negative, then the actual costs incurred so far are greater than what has been earned or achieved. This could be because the original estimates were incorrect for the project. Alternatively, the project team may have a different capability to what was originally planned and are therefore less productive than planned.
■ When cost variance is positive then the project is spending less to achieve what was planned. This means that Earned Value is greater than the Actual Costs incurred so far. This could mean that the original estimates were incorrect, or the project team are being more productive than envisaged.
■ When schedule variance is positive, then the project is ahead of the plan. This is a calculation of Budgeted Cost of Work Performed minus Budgeted Cost of Work Scheduled. With the schedule variance indicating that the project is ahead of plan, the project manager could choose to release resources back to the business. A more rounded picture can be understood when Cost Variance is also considered.
■ When schedule variance is negative, then the project is behind the plan. This means that the project, if it does not recover, will not deliver on time. This could be because the original estimate was incorrect, or it could be because there are not enough resources allocated to the work.
■ When schedule performance index (SPI) is > 1, then the project is ahead of schedule. SPI is a calculation of Budgeted Cost of Work Performed divided by Budgeted Cost of Work Scheduled. For example,
if SPI is 1.25, then the project is 25% ahead of plan. This could be because there are more resources allocated to the project than planned or because the resources are being more productive than planned.
■ When schedule performance index (SPI) is < 1, then the project is behind schedule. SPI is a calculation of Budgeted Cost of Work Performed divided by Budgeted Cost of Work Scheduled. For example,
if SPI is 0.35, then the project is 35% behind plan. This could be because not enough resources were allocated to the project than planned or because the resources have encountered challenges effecting productivity.
■ When cost performance index (CPI) is > 1, then the project is underspending to achieve what was planned. This is a calculation of Budgeted Cost of Work Performed divided by Actual Cost of Work Performed. For example, if CPI is 1.25, then the project is spending £1 in order to achieve £1.25 worth of work. In other words, the project is running at 125% productivity. There could be various reasons for this including the initial estimates were incorrect, or because resources are being more productive than planned.
■ When cost performance index (CPI) is < 1, then the project is overspending to achieve what was planned. This is a calculation of Budgeted Cost of Work Performed divided by Actual Cost of Work Performed. For example, if CPI is 0.85, then the project is spending £1 in order to achieve 85p worth of work. In other words, the project is only at 85% productivity as opposed to 100%. There could be various reasons for this including the initial estimates were incorrect, the team is new to the work, resources have been unproductive or because there has been a problem during the development.
6.15 explain the benefits of using the interpretation of earned value data
It enables objective measurement of project status to be compiled and communicated to stakeholders. Creating a consistent approach to reporting so that, at a senior management level, project progress can be compared across a set of projects, providing an easy-to-understand current status reporting system for projects. At the organisational level, if projects are providing commentary against the information coming through from Earned Value management, then the senior management will receive a consistent set of metrics and informed interpretation from each project. This will allow the organisation to consider which projects need more support, which can be left to run as they are and where appropriate transfer best practices.
■ Supports better forecasting against time and budget, establishing a basis for estimating when the project will complete and final cost. By calculating schedule performance index (SPI) and cost performance index (CPI), the project manager can use these indexes to support the forecasting estimates at completion for cost and time. By using SPI and CPI, the project manager is assuming that progress to complete the project is the same as what’s been achieved so far, this rate can be calculated for the whole schedule, providing an estimated duration, completion date and a final estimated cost for the project.
■ Earned Value data can provide an early warning to the project manager. By firstly getting an understanding of the percentage complete for a task from each task manager, the project manager can then turn this percentage complete into Earned Value for the task providing greater visibility of discrete areas of the project that are impacting performance. Resources can be managed in these areas specifically and the earned value results monitored to verify resourcing decisions. By subsequently calculating cost and schedule variance, the project manager can quickly understand whether the project is on track or not. If the project is not on track, then the project manager can also use the data to understand whether they are ahead or behind on the plan and put in place suitable control actions where necessary.
6.16 explain the role of contingency planning in projects
Contingency is the resource set aside for responding to identified and unidentified risks which are also referred to as ‘unknown-unknowns’. It is needed to cover the gap between the identified risk’s exposure and the mitigated risk’s exposure and depends on the level of confidence the business might have in the project’s ability to reduce the risk. This resource can also be held in management reserve which also includes the unidentified risk provision. Contingency is not ‘hidden’ extra time or money to deliver planned scope, it is clearly identified. Organisations will normally proportion contingency between the project manager, project sponsor or programme manager and the governance board.
Contingency is most typically expressed as:
■ Budget contingency – a monetary allowance for dealing with uncertain events that have an impact on project costs or financial benefit. This budget can be used to deal with the impact of a realised risk, for example, to add more resource onto a project to try to recover from the situation.
■ Time contingency – a schedule allowance for dealing with uncertain events that have an impact on project timescale. This allowance can be added as an extra float on the associated tasks within a schedule or as an extra activity on the schedule within a sequence of tasks. The extra activity or float can be used to complete the impacted tasks and still allow the remainder of the project to continue as planned.
■ However, when using an iterative life cycle and timeboxes to drive a project, it is relevant to consider contingency in terms of scope or quality. In this scenario, within a timebox, lower priority scope may be left out of the cycle if the estimates are not correct or to ensure that higher priorities are developed.
7.1 explain how to define scope in terms of outputs, outcomes and benefits (including use of product, cost and work breakdown structures)
■ The scope of the project will be defined by the outputs, outcomes and benefits to be delivered. The project outputs are the deliverables which will be used to produce outcomes in terms of changed circumstances, behaviours or practices. These aim to create benefits in the form of measurable improvements perceived as positive by stakeholders in line with the defined acceptance criteria.
■ The product breakdown structure (PBS) can be used to identify the scope of what will be delivered where the main end output of the project is placed at the top level. The project manager and team will then seek to define all the components at the next level down and so on until the level is reached which identifies individual products. An example of how this can be done is through creative workshops or as standalone activities by the team leaders. The project manager can then bring all the information together in this hierarchical PBS which can be reviewed against the defined acceptance criteria and quality control methods. The completed PBS can be used to obtain stakeholder agreement of all deliverables and to reach agreement on what is in and out of scope. There should be a process of reviewing and agreeing scope with stakeholders until the project closes, in order to help mitigate any risk of change due to a lack of clarity and subsequent time delay, cost increase or benefit reduction.
■ A work breakdown structure (WBS) defines a baseline scope of work and is used to capture the activities or work to be completed to deliver the project requirements, its outputs and benefits. The lowest level of detail normally shown in a WBS is a work package. The project manager may choose to produce a WBS once a PBS is already developed. The project manager and the team can then look at each product defined in the PBS and document the work needed to generate it and to identify the most suitable technical resource. They may choose to group work that needs a similar skill. For example, whereas a PBS for a house might be split into components such as walls, windows, roof and electric sockets, the WBS could be split into construction, electrical and plumbing. By defining the work in this way, it allows for easier allocation of resources, estimating and scheduling of work packages.
■ A cost breakdown structure (CBS) can be used to show either the costs assigned to work packages, using the WBS such as people, equipment, materials or other required resource, or the costs assigned to functional areas and third parties using the organisational breakdown structure (OBS). The CBS provides a financial view of the project, and the project manager can use this to track the project spend to understand achievement against the estimates produced.
7.2 explain how to establish scope through requirements management processes (such as gather, analysis, justifying requirements, and baseline needs)
■ Gather requirements – Collect requirements from the various project stakeholders and ensure that all possible requirements for the project are gathered and documented in a standard way. Making sure that all stakeholders have been identified and consulted is important; this can be challenging as they may not always be immediately available for these discussions, may not be fully aware of all their requirements or may have conflicting opinions.
■ Analyse requirements – using specific value-based techniques such as function analysis and function cost-analysis to fully understand the requirements and the value they will contribute to the overall objectives of the project. The project manager and team may choose to group similar requirements or even use a labelling system to sort the gathered requirements. This step typically also involves testing any assumptions made. During the analysis, any gaps should be identified, or conflicting requirements resolved; and functionality and value of alternative ideas should be assessed. It is important to communicate any findings back to the source stakeholders and build consensus. It is also important to achieve a baselined set of options for functional requirements.
■ Justify requirements – This stage seeks to prioritise the functional requirement set. With a large set of functional requirements documented for the project, there is now a need to link the requirements to the benefits and project success criteria. This will help the team differentiate the needs from the wants for the project. Techniques such as the MoSCoW (M – Must have; S – Should have; C – Could have; W – Won’t have) approach can be used to prioritise the functional requirement set. Again, feedback to the source stakeholders is advisable to mitigate any disputes later in the project life cycle at completion or during transition.
■ Baseline requirements – Once the functional requirement set is prioritised and agreed, it will then form the baseline for the project. It is from this baseline that the project manager and the team can now work to determine the principal project deliverables. Some examples of why it is important to baseline the functional requirements, are firstly so that progress can be measured against this ‘fixed’ set and, so that the project manager and team can easily identify when there is a change to these which ultimately will help to mitigate scope creep.
7.3 explain how to manage scope through configuration management processes (such as planning, identification, control, status accounting, and verification audit)
Scope management is closely linked to configuration management by planning, protecting and controlling changes. The activities of configuration management contribute to scope management as follows:
■ Planning – This stage seeks to define the procedures and processes to follow for configuration management of the project including clear roles and responsibilities. The configuration plan can form part of the quality management plan. By using central policy, processes and procedures, it is likely that the project configuration management process will be more efficient as all team members will be familiar with what is needed and therefore everyone involved will be working with the correct version of the configuration.
■ Identification – This stage seeks to break down the project into configurable items and to give each item a unique reference. When scoping the project, the project manager and team can identify the deliverables of the project. As a minimum, identifying each deliverable as a configurable item and giving these a unique identifier as well as version number will contribute to the monitoring of change and therefore how the scope is developing for the project.
■ Control – This activity seeks to ensure that changes to the items are controlled. The control activity will work alongside change control for the project, so when a change is identified, the interrelationships between the configuration items is understood and therefore the impact of the change is assessed and addressed when the change is made. This will ensure that nothing is overlooked when change is applied.
■ Status accounting – This ensures traceability of configuration items throughout their development. This step within the process supports record keeping and document control for the project as the configuration of the project is tracked through development and recorded routinely. This will help with maintaining a robust audit trail as users can consult the configuration record to obtain an updated status account of an item at that point in the project.
■ Verification audit – This ensures that the deliverable conforms to its requirements and configuration information. When delivering the project, particularly if it is made up of many parts, it is important that the completed deliverables match those documented in the latest configuration information for the project. Audits should be undertaken throughout the life cycle during change control or at a minimum at the end of each life cycle phase to maintain full end-to-end configuration management of the project and to ensure that management products are being used in line with their current configuration status.
7.4 explain different stages of a typical change control process (such as request, initial evaluation, detailed evaluation, recommendation, update plans, and implement)
■ Request – It is important to document the change in a change request, so that it is clear what the change is and the source of the change. A change may be requested by both internal and external stakeholders who should provide relevant information on the nature of the change and reason for it. This information can be captured within a change request form. The request is logged or entered into a change register which records all requests and their status (e.g. submitted, under evaluation, approved, rejected or deferred). The change request will be given a unique identifier and assigned an owner to evaluate it. It is important that all changes are formally logged to avoid the implementation of informal changes which have not been fully considered and evaluated.
■ Initial evaluation – It is important to review the change request to determine its necessity, feasibility and potential impact on project outputs and to understand why the change has been raised, e.g. whether it is a mandatory legislative requirement or whether it is to resolve an issue, or is customer driven. If necessary, further clarification or information may be requested to support the change request to decide whether it is worthwhile proceeding to a detailed evaluation. The proposed change may be deferred or rejected at this stage, in which case the reason for rejection will be recorded and the requesting stakeholder informed of the reason why.
■ Detailed evaluation – The project team makes a detailed impact assessment of the change request, including understanding the impact on the project baseline success criteria such as the benefits, scope, schedules, costs, quality, resources, risks and stakeholders. The change is evaluated in detail to determine the likely impact on the ability to achieve the business case and deliverables. This is likely to involve the specialist input of several key individuals and work-stream leaders, including supplier representatives for a partially outsourced project and may include identifying and evaluating different options for implementing the change. Impacts on other projects and business-as-usual activities should also be considered, as well as the impact on work already completed and any relationship to other proposed changes. The project manager will collate the results of the evaluation for consideration by the appropriate approving body. The project management plan (PMP) should define the approval threshold levels for changes of different levels of impact.
■ Recommendation – The results of the evaluation are presented as a recommendation to the sponsor or wider governance board, or any other appropriate body such as a steering group or external client representative, depending on the agreed thresholds. It should recommend whether the change should be approved, rejected or deferred. The authorised body, often the sponsor, perhaps with inputs from others as required, makes the final decision and has ultimate authority to accept the recommendation made or decide otherwise. The sponsor is accountable for ensuring that the decision is then communicated to all affected parties.
■ Update plans and implement – Once a change is approved, the baselines and budgets are updated, including the business case if necessary, for example, where a change impacts project benefits. New risks may also need to be raised and added to the risk register because of the change. The actions necessary to implement the change can then be undertaken in accordance with the updated plans. Configuration records and versions need to be updated accordingly to reflect the latest version of all relevant project documents which have been updated to incorporate the change. There should be updated and clear roles and responsibilities for the subsequent actions needed to implement the change.
8.1 describe ways to create and maintain a schedule (including critical path, and Gantt charts)
■ Identify the tasks that will need to be done and estimate the duration (effort) of each task to deliver the project. This can be done using a work breakdown structure (WBS), an effort estimate for each task and a resource list with availability for each task. The WBS is a hierarchical representation of the work that needs doing and can be generated by the project manager or project team. It is important to capture all the activities required on the project. If task and resource lists are not available an initial schedule can be created, but it will be considered an estimate until task duration and resource is confirmed.
■ Determining the logical relationship between tasks (dependencies) in relation to their delivery. There will be a logical order to the progression of work on a project, e.g. when building a house, simplistically the walls will have to be built prior to adding the roof onto the house. The logic can be captured in a network diagram. The interdependencies of the tasks in a network diagram are more often captured as a finish-to-start link, as the example given above. However, tasks could be given a start-to-start link, a finish-to-finish link, or a start-to-finish link. Understanding the tasks required and the logical order they need to follow enables the project manager to create a schedule of activity to be maintained for the project to successfully deliver.
■ The critical path approach is the identification of the shortest time to complete all activities in a logical order. It is created by understanding the links and dependencies between the project tasks, which enables a network to be determined, then estimates of duration can be agreed. The critical path is the sequence of dependant activities with a start-to-finish link whose duration, when added together, provides the overall duration of the project. The critical path will be the longest pathway of activity in the schedule. Establishing this enables the project manager to maintain delivery of the schedule to deliver the project to the baselined project management plan (PMP).
■ A Gantt chart provides visualisation of the tasks as bars on a timeline to monitor and control the scheduled activities during their delivery. This is usually done using project planning software, for example, Microsoft Project or Primavera, or simply by using a spreadsheet. It shows the dependencies between the tasks and the milestones to enable resources to be allocated to each activity. Each task as defined in the WBS is allocated a line or bar which maps against the project’s calendar.
■ Assigning resources that are required to carry out the work. The necessary resources are analysed and assessed within the estimating activity. The project manager will also have identified the types of resources required, e.g. people, materials and machinery to complete each task. This information can then be added to the Gantt chart, so that the number of resources required each day or week for the project can be totalled. The schedule can then be adjusted, if necessary, to create the most optimum resource profile.
■ During the project, the schedule will need to be updated to reflect changes to scope, time, resource availability or priority. This will be done through change control and the new versions of the critical path and Gantt chart will be baselined in the updated PMP and communicated to the stakeholders and project team.
8.2 differentiate between critical path and critical chain as scheduling techniques
■ Critical path scheduling places the emphasis on the activity, whereas critical chain scheduling places the emphasis on the resources. By using critical path scheduling the individual can understand the shortest time to complete all the project activities in a logical order. The project manager then manages the activities on the critical path so that they don’t overrun and consequently impact the end date. They may therefore add and reduce resources as necessary to maintain the critical path, whereas in critical chain scheduling the project manager attempts to keep resources at a constant utilisation and as soon as they are allocated to a task, they need to complete the work as soon as possible. The focus is on encouraging resources to gain maximum productivity regardless of dates.
■ Critical path scheduling allows the float to be held at each activity, whereas critical chain scheduling strips the float from each activity and includes it as a buffer for a chain of activities. By keeping the float in each activity, it is important that the estimates are as good as possible. With the float kept in this way, the resource profile for the project may have more peaks and troughs, however when tasks start and end are more predictable. Within critical chain scheduling, with resources having a constant utilisation, they are challenged to complete each task as soon as possible and therefore any float in the estimates for a task is stripped out and kept at the end of the project as a buffer.
■ When a project manager uses critical path scheduling, they will need to monitor each task on the project, putting in controlling actions to try and keep the task as scheduled. With critical chain scheduling, the project manager could simply monitor the buffer provided. The rate of consumption of the buffer is used to consider how the project schedule is controlled. In the critical path method the start and finish of activities are the focus for reporting, whereas in critical chain the rate at which the buffer is being consumed is reported to stakeholders.
8.3 describe how resources are categorised and allocated to a linear life cycle schedule
■ Allocation of resources – Resources are considered as all the labour and non-labour items required to undertake the scope of work to the required quality. Resources can be human (labour), materials, plant or equipment and facilities such as specialist test sites. The appropriate elements will need to be scheduled for a task, e.g. putting a roof on a house could require skilled labour, materials (e.g.roof trusses) as well as specialist equipment (e.g. a crane). Consideration should also be given to the relationship between resources and project logistics, as resources generally require space within which to operate, and materials need space to be stored. By detailing this information on the project schedule, it helps the project manager and team to coordinate all the resources needed for each project task.
■ How many resources are needed – This is understanding the estimate for the tasks. A project manager can choose to allocate more resources onto an activity to shorten the timescale to complete the activity. There is a need to be mindful of the task at this point, as it is not always possible to ‘load’ the activity, as too many resources can also be a hindrance to getting the job done.
■ Availability of resources to support the schedule – This is understanding the scope of work for the project and specifically each task to be done and then deciding how many resources should be allocated to these tasks. During the concept stage in a linear life cycle it is assumed resources will be available. As the schedule is further developed, if the assumed resources are not available to support the project, the schedule may need to be altered. The project manager can apply resource levelling/ smoothing techniques here if needed. Lack of resource availability could be due to high demand, such as a particular skill or a shortage such as limited number of specialist cranes for a particularly high building. Where resources do constrain the project delivery rate, they are known as ‘critical’ resources.
■ Cost of resource – Once the schedule is built and the number of resources allocated to each task within the timeline, the project manager can then extrapolate the data to understand the overall cost of the project. By understanding the costs across the timeline, including the split between fixed and variable costs the project manager can define a total spend profile for the project which will help with monitoring the progress of the work. These costs can also help the organisation to release funds for the project at phase reviews by providing a spent to date and costs forecast for the future position to be validated against the business case.
8.4 describe how resources are categorised and allocated to an iterative life cycle schedule
■ When resources are needed – Within an iterative life cycle a set of resources will be defined and will work on several iterations within a fixed time window until more knowledge is understood as the scope of the project is not fully defined. Therefore, the project will need to be adaptive to the knowledge as it is gained. In an iterative life cycle, time and cost are fixed and resource allocation is managed within this constraint.
■ Ensuring requirements are prioritised and implemented within the pre-allocated resources – Depending on what is already known about the project scope, an estimate of how many resources are needed to run through an iteration of the project will be completed. This fixed number of resources are then allocated to each time box (iteration) of the project with a view to further developing and understanding the functionality. If during the iteration the number of resources is not deemed to be enough, the requirements of the iterations will be prioritised varying the scope and quality achieved as required.So, scope is varied as opposed to the number of resources. The de-prioritised scope may then be scheduled for a subsequent iteration.
■ Funding for the project – In an iterative project life cycle, the release of funds may be more frequent due to the close interaction with the project sponsor as the work is completed in iterations. The level of information needed to draw down on funding will depend on the governance, however, if the number of resources allocated to each iteration is known, this will support the decision making.
8.5 differentiate between resource smoothing and resource levelling
■ Resource smoothing is used when time is more important than cost and assumes that all resources are available, whereas, resource levelling has a fixed amount of resource available. When planning a project, the project manager should consider the resource profile generated when combining the project schedule with the estimates of effort for each task. A resource profile which sees the level of resources on the project flex from lots of people to a few people and then increase again can be difficult to manage. It is also not likely to get the best work out of the project team. If all the resources are available to the project manager, then the best approach to dealing with these peaks and troughs is a smoothing exercise. This looks at each task’s float to see if they can be moved to get the best profile applying resources on critical activities across the whole schedule rather than in selective areas.
The project manager may also need to reconsider the logic of the tasks within the schedule to create an optimal profile. Alternatively, when the project manager is constrained by a fixed number of resources for the project, they must consider resource levelling. Again, this will involve looking at the resource profile generated by the initial planning exercise and reordering tasks where possible to level the profile; this could mean that the project end date slips.
■ Resource smoothing protects the end date of the project whereas resource levelling may move the end date. When the project manager is employing a smoothing strategy for the resource profile, the assumption is that all resources are available for the project. The need to smooth the profile is to improve productivity on the project, which could be lacking if the profile is a series of peaks and troughs. By smoothing, the optimum profile is achieved without moving the end date of the project. When levelling the project, the project manager is constrained by the number of resources available, and therefore, depending on the number available, there is a general acceptance that with the levelling exercise the project end date will be delayed.
8.6 differentiate between cost planning for iterative life cycles and cost planning for linear life cycles
■ In a linear life cycle, cost planning can vary and is influenced by the scope whereas in an iterative life cycle cost planning is fixed and the scope will vary to deliver features within the available costs. It’s key to understand the relationship between fixed and variable costs when cost planning to appropriately factor in these costs. Fixed or non-recurring costs happen once in a project life and contribute a single cost, such as technology set up, site activation, etc. Variable or recurring costs occur periodically as an event in a project and contribute multiple costs with a cumulative effect, such as maintenance of technology, production line tasks, etc. Although the costs are estimated at the start of linear life cycle, it is likely that emerging scope, risk and changes of resources can lead to changes in the overall costs. With an iterative life cycle the costs are fixed while the scope is developed and varied.
■ In a linear life cycle, funds will be released either for the whole life of the project or at the relevant decision gates, whereas in an iterative life cycle, the release of funds may be more frequent due to the close interaction with the sponsor as work is completed in short intervals. As the project is estimated at the start of a linear life cycle, the business case is developed and the return on investment is also calculated. This allows for the funding to be ring-fenced for the project and either given as a whole to the project manager, or released at each decision gate, when the costs spent to date are understood and costs forecasted for the future are approved. Within the iterative life cycle, the funds will be released as the project develops and each timebox adds functionality. This allows the sponsor to make more informed decisions on the worth of the return on investment.
9.1 explain the purpose, typical content and importance of a procurement strategy
■ To ensure that the projects, programmes and portfolios within an organisation have the best resources to satisfy the project needs and level of complexity, as well as ensuring the most suitable contractual arrangements are established in relation to the level of risk and required level of collaboration. It is important to have a procurement strategy established as early as possible in the project life cycle. This will help to mitigate the potential of tender delays and long lead-in times, as failure to get the right resources on time and within the costs allocated could lead to the failure of the project.
■ To determine whether ‘make or buy’ is more suitable – Outlining the reasons for ‘make or buy,’ assessing whether the goods or services can be made in-house using the organisation’s internal skill and capability or whether these need to be sourced from an external supplier. Prior to buying in goods or services from a supplier, the project will need to decide on whether the market is able to provide the services needed by exploring the ‘external potential to provide’ and whether this is the right option for the project. Factors that may be considered are internal utilisation, capability and capacity and whether it’s best to allocate risk internally or externally with the supplier. Other points to consider are the levels of control desired and whether it has commercial sensitivity.
■ To define the forms of contract and contract conditions – such as the payment mechanism which will be used to reimburse suppliers. This should ascertain how and when the supplier will be paid, how the allocation of risk is determined within the payment mechanism and how supplier performance will be incentivised. When going out to tender with suppliers, it is important for both parties to understand the contractual terms, for example how the goods/services will be paid for, how underspend or overspend on projects will be accounted for, who will take the risk of quantity measurements and pricing, and whether there are any penalties or bonus incentives to motivate performance.
■ To determine the most appropriate supplier selection route whether using single, integrated, or multiple suppliers – the procurement strategy should provide a process which is transparent, objective and structured to get the best value supplier from the market. This process will ensure that the buyer gets the right supplier for the work and will also ensure that this has been done in the fairest way possible. The supplier selection route should consider factors such as the preferred type of contractual relationship whether collaborative or transactional, the level of price/quality competition needed and the level of reliance on any supplier in relation to performance that the customer is willing to accept.
9.2 differentiate between different methods of supplier reimbursement (including fixed price, cost plus fee, per unit quantity, and target cost)
■ A fixed price reimbursement method works on an agreement with a supplier, fixing the price upfront and is based on a fixed scope. There is a need to ensure that the scope is detailed enough to control the cost risk. The supplier will be paid this price against the delivery. This is deemed the lowest-risk option for price control as the supplier will quote their final price for the work and therefore give the buyer price certainty on the likely outturn costs. This may be outweighed by the higher schedule and technical performance risk. With the fixed price method, the buyer can be hands-off in the management of the supplier as the risk is with the supplier to deliver the output, this may be at the detriment of schedule and technical performance.
■ A cost-plus fee method works on the buyer paying the supplier for the actual costs incurred on the task to deliver the scope plus an agreed fee or percentage to cover supplier margins. This method can be used when the scope is not fully defined and there are time constraints. With a cost-plus fee or percentage method, the buyer will need to manage the supplier closely, providing them with instructions to deliver the project; this is a high-risk contract for the buyer as the contract is entered into without knowing what the final costs are likely to be.
■ A per unit quantity allows the buyer to agree a fixed price for ’units’ required for the project. This is a high-risk contract for the buyer as they may not know how many units are required and therefore the outturn costs for the project will remain uncertain until the end of the contract. An example of a per unit quantity might be for urgent or emergency works. This might be a quicker way of getting the resource to support the project than trying to get a specification in place for the resource to tender against and provide a fixed price for the work required.
■ A target cost contract is a cost reimbursable contract where both parties reach an agreement on the target cost of the work and agree how any overspend and underspend will be shared. Any costs over the target cost will be funded by both parties, if final costs are less than the target, then both parties will share the surplus. With a target cost contract, the risk is shared between both parties highlighting the benefit of strong collaboration. With the other types of contracts, the risk is largely with one party or the other.
9.3 differentiate between different contractual relationships
■ Comprehensive contracts - A project may use one supplier who would be responsible for all parts of the project. This would be an easier interface to manage and is more collaborative, builds strong relationships and reduces procurement costs, but by putting the responsibility for all elements of the delivery in the hands of one supplier, there may be greater risk to consider, such as the performance, availability and capacity of this single supplier.
■ Sequential contracts – These could be used for sequential project deliverables to be allocated to different suppliers in the order these are delivered. For example, design and construction could be contracted out separately to different suppliers. The benefit of this is that spend commitment is phased and therefore avoids high financial commitment upfront before knowing the feasibility of the ultimate project. This route would have a more complex set of interfaces to manage and interactions between suppliers. There is the potential here for claims between suppliers, with the potential of each party blaming the other for any errors, inconsistencies or defaults.
■ Parallel contracts – These assign a similar scope of work to two or more specialist suppliers, and they work in parallel to deliver the complete project. This might be the best option if the scope has not been fully defined or if individual suppliers have been unable to demonstrate the required capabilities to fulfil all requirements. This will require a more ‘hands-on’ approach from the customer as they will be managing all communications directly with each specialist supplier as well as managing all relationships between parties. The client can logically share or separate the types of work spreading the risk of poor performance.
■ Partnering/joint venture – Projects will be completed by a number of organisations working together and forming a partnership. Using this type of collaborative working model can be beneficial where the total work to be completed is too large or complex to be taken on by one organisation or supplier.
■ A project using a single supplier route, or a ‘preferred supplier’ may get less competitive prices than those using a multiple contractual relationship model, and would be more transactional in nature. The project may decide that lack of competitive pricing is outweighed by the ease of managing a single supplier and the collaborative relationship that can be built over time. Other considerations are the additional cost involved in contract negotiation and additional management, and therefore a more competitive price model from a multiple supply chain, may be outweighed by the cost of managing this.
9.4 explain a supplier selection process
Purpose of a process:
■ To ensure openness, objectivity and fairness in the selection of a supplier. Having a process where the requirements are clear and all providers have equal chance of success; there should be clear instruction issued to each supplier invited to tender for the work. This will ensure that each supplier understands what is needed from them; and the team within the buying organisation fully understanding their roles within the process, how they should engage with the supplier and how their bids will be evaluated. Following this transparent process will provide confidence to all stakeholders involved that everyone has the same information and evaluated in the same way. By adhering to the process, the buying organisation can provide proof of fair play should the need arise.
■ To get the most appropriate supplier for the project. The buying organisation will take time to not only define their requirements for the work but also to establish their selection criteria for the bids and to identify the providers that have the required capability. A pre-qualification questionnaire is often used to assess provider capability and reduce the initial shortlist. This is done ahead of the tender documents being issued and consideration is made as to the priorities of the project and how this would be factored into the selection criteria. Once the bids are received, a thorough review and evaluation against the criteria should provide clear scores against each supplier providing confidence that the most appropriate supplier is selected for the project.
■ To ensure the supplier is responsible and aligns with the buying organisation’s requirements. The process is designed to ensure that the requirements of the buying organisation are clear and that these have been fully reviewed before including them in the tender documents for the supplier to provide their proposal. If there is ambiguity, then there is opportunity within the process for the suppliers to ask questions and for the buying organisation to provide answers to all the suppliers. Clarity on the information needed in response to the bid will allow the suppliers to demonstrate their capabilities and how they will meet the requirements within their proposal. This is then evaluated by the buying organisation to ensure alignment.
Stages of a process:
■ Research – This stage will lead to a long list of potential suppliers that are deemed to have the required capability. The buyer needs to fully understand their requirement and clearly define it: what they need from the supplier, when they need it to be delivered and to what standard. The project manager will need support from technical leads and subject matter experts to fully define the requirement with the clarity needed to allow it to be used in a tender process. This is done to ensure that the supplier will deliver exactly what is needed and there will be no ambiguity during the development causing difficult contractual problems.
■ Pre-qualification – This stage will look to reduce the long list by ascertaining the production capacity of the providers, willingness to tender, financial stability, technical expertise and references. This will result in a shortlist being created.
■ Tender – The shortlisted suppliers will be asked to provide a full bid against the defined set of requirements. The buying organisation will need to understand the priorities of the project and agree the criteria against which each supplier will be judged. This will ensure that when the tenders are evaluated they are assessed against what is important to the project and the buying organisation. By understanding how each supplier meets these criteria, the buying organisation can gain confidence in the supplier and will have reduced the risk of selecting the wrong supplier for the work. Factors such as track record, price, skills of personnel, capacity and safety performance may be considered. The requirements should be clear, and all providers given an equal chance of success. The tender document will not only contain the requirement but will also explain how the tender should be responded to, by when, and what type of contract will be offered. It may also outline the priorities of the project to the supplier. This information will be required by the suppliers to decide on their offering to the project. By providing a common set of instructions to all potential suppliers and ensuring adherence to these instructions, the buying organisation ensures that a fair selection process is adhered to. Records must be maintained and archived to offset any potential challenges by unsuccessful providers. Evaluation should be made against the criteria established earlier in the process and include an appropriate analysis of risk in addition to time, cost and quality. A scoring mechanism can be used against the selection criteria. They will score each bid against this, so that there is a fair evaluation and a quantitative outcome.
■ Award – After evaluating and scoring the bids, the buyer will make a final decision on which supplier is best for the project. At this point, further engagement may be needed to negotiate and finalise the deal. This is an opportunity for both parties to clarify any points and to ensure that these have been documented. Following negotiation and agreement of the contract to supply goods and services a contract will be awarded. It is important that both parties are happy with the offering and the terms of the contract to ensure smooth management during the project. At this point, the process will move onto contract award.
■ Manage – Active management of the contract must begin as soon as the contract has been awarded.
■ Close – Once all goods and services have been delivered and accepted against the acceptance criteria and all financial agreements have been honoured and settled, accounting for the inclusion of any additional cost to either party due to change, repairs, defect close out, delays the contract can be closed.
10.1 explain each stage in a risk management process (such as identification, analysis, response, and closure)
■ Initiation – This involves establishing the risk management plan specific to a project and could be deemed as the first stage in the risk management process. The initiation phase will consider what process to follow on the project to ensure it fits its specific requirements. This should establish roles and responsibilities involved in risk management, how risks are assessed and the impact of these evaluated against the agreed tolerances of the organisation. The regularity of reporting and escalation points should also be considered and documented.
■ Identification – This stage, as comprehensively as possible identifies the risk events relevant to a project. There are several risk-identification tools and techniques such as brainstorming, checklists and SWOT analysis. By deploying these methods and identifying knowable project risks with input of a wide range of stakeholders, the project manager will try to identify, without bias, as many project risks as early as possible within the project life. This is an ongoing process and risks should be identified and reviewed throughout the project life cycle. Once identified, risks should be documented in the project risk register. The risk register should include as a minimum the description, probability, impact, response actions, fallback, status and the names of individuals with responsibility for the risk’s management with clear distinction between causes, risk events and effects. A risk owner, the person best placed to assess and manage the risk, should be defined for each risk.
■ Analysis – This stage includes the assessment of the relative impact of the identified risks. This will be undertaken by the project manager, with the support of the project team and/or subject matter experts, using either qualitative and/or quantitative techniques. Qualitative analysis considers the significance impact on objectives. This could be in form of a simple calculation of the probability or likelihood of the risk event occurring multiplied by the impact of the risk event on schedule, cost, benefits and potentially other objectives. Risks are usually analysed and plotted in a probability/impact grid; the grid typically plots five degrees of impact and probability ranging from very low to very high often categorised using red, amber and green coloured areas of the grid. Good practice would be to agree the risk thresholds as part of the risk management plan for the project at the outset and the approaches for each of the grid areas. For example, any risks appearing in the ‘red’ area of the grid being considered to have potentially critical consequences on project objectives would be deemed considerable enough to require escalation. Quantitative risk analysis may also be used to determine the combined effect of risks on objectives and for focus on specific risk-based decisions using techniques such as Monte Carlo simulation, decision-trees and sensitivity analysis.
■ Response – This stage considers the most appropriate response that could be put in place to deal with the risk event whether proactive or reactive, considering also whether the risk is deemed a threat or an opportunity. Proactive responses could include avoiding or reducing a threat or exploiting or enhancing an opportunity. Reactive responses could include making provision of contingent funds on the basis that the risk is seen as acceptable and can be managed in this way. Putting a risk-efficient overall project solution in place in the form of these responses should reduce the likelihood of the threat occurring, reduce its impact, or even eliminate it altogether, so increasing the likelihood of project success. However secondary risks and residual risks which may emerge as a consequence of the response should be considered along with any separate responses needed to deal with these. Where the significance of these is deemed similar or greater than the original risk it could be considered that the original response was ineffective.
■ Closure – This stage closes the risk in the risk register once it is eliminated, responded to, has occurred, or the stage of the project in which the risk was likely to occur has passed. It is important at this stage to record information relating to the risk, the rationale for closure and lessons learned. It is important to keep the project’s risk register current to avoid unnecessary work in tracking risks that will no longer occur. Keeping the register as an auditable record of how risks were identified, responded to, and controlled on the project will also help with future projects that the organisation will implement, supporting the continual improvement of project activities and the processes supporting them. Any remaining risks at project closure should be communicated to those involved in the adoption phase.
10.2 explain proactive and reactive responses to risk (such as avoid, reduce, transfer or accept and exploit, enhance, share and reject)
■ Avoiding a project threat – This is a proactive response which seeks to eliminate the risk by changing the cause of the threat. This is where the probability of the risk occurring is reduced to 0%. In other words, the risk can no longer occur. This requires a change during the project, often changing the scope or the technical solution to remove the risk because that needs to be avoided. For example, a project risk might be that the novel technology needed for the technical solution is too immature; to avoid this threat, the project may choose to consider a different technical solution using proven technology.
■ Reducing a project threat – This is a proactive response whereby actions either reduce the impact
of the threat in terms of its probability of occurring or its impact on the project are considered and implemented. The risk and the actions considered will need to be monitored to ensure that the actions taken do in fact reduce the risk as expected. The response action could potentially be a cost to the project, so a decision would need to be made as to whether the cost of the action is worthwhile and will cost less than the risk’s expected value, or whether the risk should be accepted with contingency put aside.
■ Transferring a project threat – This is a proactive response which transfers the risk from one party to another. If a threat is identified which is outside the capability/capacity of the host organisation, they may decide to transfer the risk to an external supplier, who is deemed more capable of managing it. This approach may not prevent the risk from occurring, and therefore the project manager may still need to understand how the other party is dealing with the risk, as it may still impact the project. However, it will be the supplier who will need to carry out appropriate action to deal with the risk and bear the cost of any action. Another way to transfer a risk could be to take out insurance. Transferring risk requires a balanced approach however and it is likely that some element of residual risk will remain on both sides
■ Accepting a project threat – This is a reactive response whereby the risk is accepted with a contingency plan to be implemented should the risk materialise. This is a response to a threat where the project manager and sponsor agree that there is no viable approach to avoid or reduce the threat or the probability and / or the impact is very low. The threat will remain on the risk register and will continue to be monitored in case either the probability or the impact changes and a more proactive approach needs to be chosen instead. This response is usually only agreed by the sponsor in two situations: either, where the risk is within the risk tolerance or, where the cost of trying to reduce the threat is too high. Where a decision is taken to accept the risk, contingency plans can be established in relation to schedule and cost, and the status of the risk should be actively monitored on a regular basis and any impacts from this risk on stakeholders should be reported accordingly.
■ Exploiting an opportunity – This is a proactive response to maximise both the probability and impact of the opportunity. In other words, to make the risk happen by implementing a response to exploit the risk and gain maximum benefit/advantage. However, the implications on the project of this response need to be clearly understood and agreed to by all stakeholders. This is because, to exploit an opportunity, often requires a change during the project. For example a change in scope, acceptance of more risk or a change in the timescales or budget in order to make the opportunity occur may only benefit certain stakeholders.
■ Enhancing the opportunity – This is a proactive response which can be either strategic or tactical to enhance the opportunity by increasing its likelihood and/or impact. For example, an opportunity identified could be to deliver the project early and achieve a reward payment from the client. The project may choose a tactical approach to enhance this opportunity by revisiting the project schedule and fast-tracking tasks whilst also adding more resources to tasks to shorten their duration. It is important to consider the cost of these actions here and it should not be greater than the reward payment on offer.
■ Sharing an opportunity – This is a proactive response to collaborate to increase the chances of the opportunity being realised through sharing some of the responsibility for the positive risk with another party who may be better placed to help realise the benefits associated with it. Cost investment on both sides is likely to be required. For example, if a contract has a bonus to be gained from delivering early, the project could share the opportunity with the supplier, incentivising them to finish earlier in support of the end goal.
■ Rejecting the opportunity – This may be when the proactive pursuit of the opportunity is rejected because it is deemed of little value or the benefits associated with it are not deemed significant enough to justify action. This may be because the cost or time invested in the action might outweigh the benefits associated with realising the opportunity. The project team would typically take advantage of the opportunity should it arise naturally but not take any proactive steps to pursue it further.
10.3 explain the benefits of risk management
■ Enables better informed and more realistic plans, schedules and budgets, therefore increases stakeholder confidence – By actively and visibly managing risks for a project as soon as practicable, the project manager is giving more credibility to the plans thereby increasing the confidence of stakeholders by demonstrating that they are doing everything they can to deliver the project. Identifying, assessing and responding to the risks identified in the most appropriate way will minimise threats and maximise opportunities. Stakeholder confidence will be increased as they will be informed of the risk factors, tolerances and required contingencies in relation to budget and time and can therefore proactively support the project manager to manage these.
■ Increases likelihood of a project adhering to its schedules and budgets – By identifying risks, the project manager and team can work together to understand response actions to overcome these uncertainties and include these in the planning. The outcome is that more realistic plans are established, and the team can therefore foresee a higher probability of achieving a successful project outcome. The team’s confidence, commitment and morale will increase as a consequence. These actions could be to, for example, add more resources to a task to ensure it is completed in the required timescale, or alternatively extend the date of a milestone. There are many more actions that can be taken to mitigate risk, depending on the risk itself. However, by taking these actions, the project manager is striving for the best possible outcome and increased chance of success for the project by setting out realistic and achievable targets.
■ Allows a more meaningful assessment and justification of contingencies – By following a meaningful risk management process that identifies and quantifies the amount of contingency required, the project manager is following a best practice approach that will help support the project in achieving its objectives as the level of contingency will be specific to the risks, the project objectives and agreed tolerance thresholds. A meaningful assessment of risk will ensure greater accuracy in the allocated contingency, whether cost or time related. The actions to respond to the uncertainties identified will either stop the threat from happening or reduce the threat to a manageable level, so increasing the likelihood of project success by protecting the project budget and programme.
10.4 explain the key aspects of issue management
Key aspects of issue management:
■ Risk and issue classification - Identification, analysis and management of issues should not be confused with identification, analysis and management of risks. An issue develops when a risk or group of risks actually occur and identified response plans are insufficient and/or are exceeded. The next step would then typically be to escalate the issue for resolution.
■ Necessity of escalation to improve the resolution process– By escalating the issue to senior management, the project manager can, for example, continue with other elements of the project knowing that the issue is now with a senior person who will take on the resolution process. The senior person will be accountable for this issue and may use their contacts/resources to help in resolving it. Senior management will have organisation-wide resources available to them to help in resolving issues affecting the project. If an issue has a high impact on a project, by escalating this to senior management, it may increase the speed at which it is resolved. Senior management will have more power to resolve issues which may be beyond the capabilities of the project manager. They will also be taken more seriously due to their relative seniority within the organisation.
■ Importance of traceability of issues through to closure – By having a clear process for identifying, registering, analysing and prioritising issues, the project manager ensures that issue resolution is being managed. Where issues have been escalated beyond the project manager’s remit, this process enables the project manager to continue to track and monitor resolution and therefore ensure that nothing is missed.
■ Prioritisation of issues over risks – it is understandable that a project manager might prioritise issues due to their immediacy and the potential of causing imminent threat to project objectives however this should not be the default position and if it is, this could indicate that the project’s plans and controls are either not being followed correctly or they are not suitable for the project.
Issue management process:
An issue occurs when the tolerances of delegated work have been, or definitely will be, exceeded. There are various steps that can be taken within an issue management process:
■ Log and analyse the issue – The project should keep an ‘issue register’/log in a similar way to risk and change registers. This allows the project manager and team to record the issue, to analyse it and prioritise it where necessary and then to track its status until it is resolved. Priority on resolving issues will be based on its impact on success criteria and benefits in the business case. Once the issue is raised, good practice would be for the project manager to ascertain the impact of the issue and its cause as quickly as possible. Issue registers will be a source of knowledge for future projects within the organisation as they can help with identifying risks on these projects.
■ Escalate the issue – The issue will need to be escalated to the project sponsor who in turn will likely escalate to the governance board or the organisation’s senior management team for resolution. This is likely to depend on the levels of authority defined for each role. The sponsor/senior management team involvement will help the project manager define the best course of action to resolve the issue and its root cause.
■ Assign actions – After deciding on the best way forward, actions will be allocated to the person or group who is best placed to address the issue and implement a resolution in a timely manner. For example, an issue with a key supplier not delivering outputs as expected could be allocated to the Procurement team to resolve.
■ Take issues through the change control process – Issues that result in changes to scope or the baseline plan will need to be taken through formal change control. This process will ensure that the change to the baseline is captured and that all project outputs and tasks have been checked to ensure no further adverse impact.
■ Manage issue to closure – The project manager will need to ensure that the issue is monitored and managed until it is resolved. They will need to monitor the status of the issue making sure that it continues to be tracked regardless of who is dealing with it. The issue register is a vehicle for supporting this activity.
11.1 explain what is meant by quality planning
■ To guide the planning of quality control and other assurance activities that are performed to check that outputs meet requirements – The ultimate reason for quality planning is to help drive project outputs that are fit for purpose and meet the specification and standards required of them. For the project manager, this is activity that should be considered and defined during the definition phase of the project life cycle, after scope definition as this will influence work tasks on the project schedule. By identifying the tasks needed to support quality management of the project at this point including agreed acceptance criteria and the methods of verifying that the outputs meet requirements, adequate estimates can be calculated and included in the project budget for these activities.
■ To identify the requirements for resources needed – Once the quality tasks are identified for the project, it is also important to identify the resources involved. In a similar way to any other project task, there may be a need for particular test equipment, a specific skillset for the defined work that may be provided by the delivery organisation or be part of the supply chain, or certain stakeholder approvals. For example, project quality assurance should be performed by someone independent of the project and therefore early identification of when this activity will take place and who is required to support will allow for better planning. By defining roles and responsibilities and obtaining stakeholder agreement, team members understand what is expected of them during project delivery to facilitate handover of agreed project outputs on completion.
■ To identify when quality activities, such as control and assurance, should occur in the project life cycle – Assurance activities ensure that the processes being followed are adequate and that they are being followed correctly and consistently and control activities check that the output (deliverables) produced meet the requirement. Placing the frequency of the tests, checks or audits that will be carried out on the project schedule as separate tasks will be useful for project personnel to understand when tasks are planned to be completed and when tasks are under review.
11.2 differentiate between quality control and quality assurance
■ Inspection ownership - Quality assurance is performed by a person independent of the project, whereas quality control can be performed by a member of the project team. Some benefits of having independent quality assurance activities are: a fresh pair of eyes on the project, there is no bias and they also bring experience and knowledge with them while auditing the project. This helps identify how the project is performing and provides ideas to overcome any non-conformances found. Quality control can be performed by a member of the project team; this can be done at any point where there is output generated, and can then be reviewed, inspected or tested for quality.
■ Timing - Quality assurance activities can be done earlier in the project life cycle as soon as project management activity starts whereas quality control activities can only be conducted once the delivery of project outputs has commenced. Quality assurance activities should be scheduled as early as possible in the project life cycle to assure the consistent and standardised procedures and processes are being followed as set out in the quality plan, quality control is focused on preventing problems being passed onto customers. By performing this assurance activity early, the cost of changes is far less, should there be a need for this. Quality control activities must wait until the project has generated output. Quality control activities can be the reviewing of documents, inspection of output or even the running of tests on the output. Even though quality control is an important activity to find any defects in the output, if these are found after the output is developed then the cost of rework is far greater.
■ Flexibility - Quality control is less flexible as the result will be a pass/fail result following the testing of an output prior to this being delivered to the customer. Quality assurance could, on the other hand, ascertain that the correct processes are being followed to a lesser or greater extent whilst still delivering an acceptable output.
■ Purpose - Quality assurance will focus on auditing the processes used and how they are followed, whereas quality control will focus on testing the output. Quality assurance attempts to build in quality through the consistent use of standard processes and procedures supported by training and feedback. Quality control tests could range from a review of documents, inspection of output or testing of output against the acceptance criteria defined in the quality plan. Quality control tests will involve checks and inspections being carried out on delivered outputs.