These changes are called outcomes. These outcomes allow the business to realize the benefits that are set out in the business justification for the project.
Examples of output, outcome and benefits Output New sales system Outcome Sales orders are processed more quickly and accurately Benefits Costs are reduced by 10 per cent, volume of sales orders increased by 15 per cent and revenue increased by 10 per cent annually.
Figure 6. This sets out not only the reason for the project, but also confirms whether the project is: desirable: the balance of costs, benefits and risks viable: able to deliver the products achievable: whether use of the products is likely to result in envisaged outcomes and resulting benefits. The business justification is usually documented in a business case. The senior user s is responsible for specifying the benefits and subsequently realizing the benefits through the use of the products provided by the project.
This requires that the business justification is not just developed at the beginning of the project, but that it is kept under regular review and updated in response to decisions and events that might impact the desirability, viability or achievability of the project. If the business justification ceases to be valid then the executive must stop or change the project following review by the project board.
PRINCE2 requires that two products are produced and maintained for the business case theme: Business case Provides the costs, benefits, expected dis-benefits, risks and timescales against which viability is justified and continuing viability is tested. It is acceptable to use an alternative document such as a corporate business plan to replace the business case for part of the project lifecycle.
Throughout the life of the project the business case is reviewed and updated as it develops and evolves see Figure 6. It is formally verified by the project board at each key decision point, such as at stage boundaries, and confirmed throughout the period that benefits accrue.
PRINCE2 does not define what techniques to use to demonstrate or prove that a project is viable, only that it should be done. Such techniques are often prescribed within organizations, either formally or through custom and practice. Appendix A, section A. In the context of Figure 6. Confirming benefits will mostly take place post- project, although benefits may be realized during the project. Development of the business justification may be delegated for example, to the project manager.
If the project is part of a programme then an approved business justification may be provided as part of the project brief. Whoever is given the task of developing the business justification, it is important to ensure that they have the appropriate business skills required e. An initial version of the business justification should be derived from the project mandate as part of the starting up a project process if it is not provided by some other pre-project processes.
Typically, this will be documented in a formal business case, although some organizations may use other documents, such as business plans. The initial business justification has to be approved by the project board in the directing a project process to initiate the project.
In most cases the project costs, timescale, products and risks will not be sufficiently understood to provide a robust justification of the project and this initial version will need further development and refinement as the project progresses.
Typically, a more detailed business case will be developed from the outline business case during the initiating a project process. Key message The business justification for a project should include not only the costs of developing the products produced by the project but also any changes to operational costs post-project.
Most organizations have policies that define how these costs should be accounted for in business justifications. The principle of this linkage is straightforward; however, reality is often much more difficult. In order for the benefits to be realized, the outcomes have to be achieved, which means that the outputs from the project actually have to be used and used in the way intended. Many organizations will be able to identify projects that have produced products that were never fully utilized, organizational changes that were never fully implemented and IT systems that were never fully used.
There are many reasons why this might be the case, including: The scope of the project explicitly excludes benefits realization. This will commonly be the case where the project is part of a larger programme and the project only delivers some of the products required to achieve the outcomes from the programme or project. For example, it is a common failure that project teams provide an IT system and training, but no post-training or ongoing support to ensure that any post-training issues are addressed.
Commitment to the changes introduced by the project is either overtaken by more pressing business-as-usual priorities, or simply just fades. Parts of the organization were never fully committed to the changes. The senior user, who is responsible for specifying the benefits from the project, is also accountable for confirming that the forecast benefits are realized.
This may involve a commitment beyond the life of the project as it is likely that many benefits will not be realized until after the project has closed. For this reason, it is usually advisable that the senior user comes from an area of the business impacted by the change.
It is first created by the project manager in the initiation stage and is submitted to the project board for approval when seeking project authorization. If corporate, programme management or the customer are to manage or participate in the benefits reviews, the project board may need to seek their approval. The benefits management approach may be managed by the project, by corporate, programme management or by the customer, and is likely to be managed beyond the life of the project.
Any benefits that can be measured during the life of a project should be confirmed by the senior user for formal reporting by the project manager in the end stage report s and project closure report.
When benefits can be reviewed during the life of the project, the benefits management approach should include appropriate mid-project benefits reviews.
Any residual benefits should be re-examined and their forecast updated as part of the managing a stage boundary process. Post-project benefits review s will involve corporate, programme management or the customer holding the senior user s to account by asking them to provide evidence of how the individual benefits allocated to them have been gained in comparison with those benefits promised to justify the cost and risk of the project when it was authorized.
By default, the executive is responsible for ensuring that benefits reviews are planned and executed, but there are circumstances where this may not always be the case. For post-project measurement activities, the responsibility for benefits reviews will transfer from the executive to corporate, programme management or the customer as the project closes as the reviews will need to be funded and resourced.
As described in Chapter 7, if roles are combined then all the responsibilities in this table must still be undertaken see section 7. Table 6. Accountable for the benefits management approach post-project.
Executive Accountable for the business case for the duration of the project. Accountable for the benefits management approach for the duration of the project unless being managed by corporate, programme management or the customer. Oversee the development of a viable business case, ensuring that the project is aligned with corporate, programme management or customer strategies, and secure the funding for the project.
Senior user s Accountable for specifying the benefits upon which the business case is approved. Ensure the desired outcome of the project is specified. Ensure that the project produces products that deliver the desired outcomes and that those outcomes will generate the desired benefits.
Provide statements of actual benefit achievements versus forecast benefits at benefits reviews. Senior Accountable for the supplier business case s if they exist ; see section 6.
Project manager Responsible for development of the business case and benefits management approach as delegated by the executive. Review impact of issues and risks on the continued viability of the business case. Assess and update the business case and benefits management approach at the end of each management stage.
Assess and report on project performance at project closure. Project assurance Verify and monitor the business case against external events and project progress. Ensure the project fits with the overall corporate, programme management or customer strategies. Monitor project finance on behalf of corporate, programme management or the customer. Ensure the value-for-money solution is constantly reassessed.
Monitor changes to the project plan to identify any impact on the needs of the business or the business case. Review the impact assessment of potential changes on the business case and project plan. Verify and monitor the benefits management approach for alignment with corporate, programme management or the customer. Project support The business case and benefits management approach should have a baseline and therefore be under change control.
Project support should advise the project manager of any proposed or actual changes to products that affect the business case. The structure, contents and format of a business justification will often depend on the maturity of the organization, the type of project and the delivery approach used. For example: Organizations with mature project management will often have annual or similar business plans, with an entry in the business plan constituting the initial business justification for the project.
Typically, a detailed business case would only be developed when the project has been fully scoped. This is where an agile approach may be particularly beneficial as, without it, the business case would not be justified.
In organizations with mature project management it will usually be the case that the structure, contents and format of the business justification will be mandated at some corporate level and aligned with the preferences of the governance body that authorizes investment in the project. For example, the finance function in the organization may own and mandate the structure, contents and format of a business case.
Even very simple projects need some form of explicit business justification, no matter how this is documented or expressed. The customer needs to ensure that its project is viable and risks are acceptable, bearing in mind the suppliers chosen. A supplier would have to ensure that it will benefit from the work it undertakes on the project. It may comprise just the details of the budget and timescales, a list of benefits and the benefits tolerance , and a statement of what the project contributes to the programme outcomes.
The justification aspects of the project business case should be in the programme business case. One way to present a business case is to show the best case, expected case and worst case of the amount of the project product requirement that will be delivered given a fixed cost and time.
When creating a business case, it is important to understand how incremental delivery of a product, and the value associated with it, could impact project viability positively or negatively and also the ability to achieve the early realization of some benefits. The selection of technique may be influenced by the type of organization e.
Examples of investment appraisal techniques Whole-life costs Analysing the total cost of implementation and any incremental transitional, operational and maintenance costs.
Net benefits Analysing the total value of the benefits less the cost of implementation, transition and ongoing operation, calculated over a defined period. Return on investment ROI Profits or savings resulting from investments expressed as a percentage of the initial investment. Payback period A calculation of the period of time required for the ROI to repay the sum of the original investment.
Discounted cash flow A means of expressing future benefits based on the current value of money. Sometimes discounted cash flows include risk adjustments as the business may not be confident that all the benefits will materialize. Net present value The total value of discounted future cash inflows less the initial investment. For example, if the discount rate is 6 per cent, the value of money halves approximately every 12 years. Sensitivity analysis Business cases are based on uncertain forecasts.
In order to identify how robust the business case is, it is useful to understand the relationship between input factors e. Sensitivity analysis involves adjusting the input factors to model the point at which the output factors no longer justify the investment. For example, a project might be worthwhile if it can be done in 4 months, but ceases to be worthwhile if it were to take 6 months. Every project needs effective direction, management, control and communication.
Definition: Stakeholder Any individual, group or organization that can affect, be affected by, or perceive itself to be affected by, an initiative i. In order to be flexible and meet the needs of different environments and different project sizes, PRINCE2 defines a set of roles that need to be undertaken, together with the responsibilities of each of those roles. The project should also provide value for money. The business viewpoint therefore should be represented to ensure that these two prerequisites exist before a project commences and remain in existence throughout the project.
The user presence is needed to specify the desired outputs and ensure that the project delivers them through the supplier. The supplier viewpoint should represent those who will provide the necessary skills and produce the project product. The supplier needs to have an understanding of all the relevant standards with which the output product needs to comply, and the project may need to use both in-house and external supplier teams to construct the project product.
In PRINCE2, the business, user and supplier interests are brought together on the project board, which is accountable for the success of the project see section 7. Managers at the level required to make decisions and commitments may be too busy to be involved on a day-to-day basis with the project. However, projects need day-to-day management if they are to be successful. The project management structure has four levels, three of which represent the project management team and a fourth that sits outside the project.
Figure 7. This information should, if possible, be recorded in the project mandate. Directing The project board is responsible for the overall direction and management of the project within the constraints set out by corporate, programme management or the customer. As part of directing the project, the project board will: approve all major plans and resources authorize any deviation that exceeds or is forecast to exceed stage tolerances approve the completion of each management stage and authorize the start of the next management stage communicate with other stakeholders.
Managing The project manager is responsible for the day-to-day management of the project within the constraints set out by the project board. Depending on the size and complexity of the project, the authority and responsibility for planning the creation of certain products and managing a team of specialists to produce those products may be delegated to a team manager.
There will be a wider range of stakeholders which may affect, or be affected by, the project. These stakeholders may be internal or external to the corporate, programme management or customer organization and may: support or oppose the project gain or lose as a result of project delivery see the project as a threat or enhancement to their position become active supporters or blockers of the project and its progress.
It is important to analyse who these stakeholders are and to engage with them appropriately. Example of stakeholder identification Stakeholder analysis identified the following stakeholders for a project to relocate a chemical factory: a number of unions an environmental pressure group an industry regulator a number of corporate, programme management or customer functions e.
Note that some of these were external to the project management team but internal to the corporate, programme management or customer organization. The PID sets out the project management team structure and roles. Communication management approach This describes the means and frequency of communication to stakeholders both internal and external to the project.
Both these products should be created during the initiating a project process. Appendix A sections A. As noted below, the roles may be combined within certain limits. Even though the project roles are mandated, the structure is not and is provided only as an example. Appendix C provides details of these roles and their associated responsibilities. For a specific project these role descriptions should be tailored and supplemented to include information that specifies the responsibilities, goals, limits of authority, relationships, skills, knowledge and experience required.
The project board has authority and responsibility for the project within the instructions initially contained in the project mandate set by corporate, programme management or the customer. They include: being accountable for the success or failure of the project in terms of the business, user and supplier interests providing unified direction to the project delegating, using the PRINCE2 organizational structure and controls designed for this purpose facilitating integration of the project management team with the functional units of the participating corporate, programme management or customer organizations providing the resources and authorizing the funds necessary for the successful completion of the project effective decision-making providing visible and sustained support for the project manager ensuring effective communication both within the project team and with external stakeholders.
This is usually done through the executive, senior user and senior supplier, although PRINCE2 does not require three people on every project board. The project board is not a democracy controlled by votes. The executive has to ensure that the project gives value for money, ensuring a cost-conscious approach to the project, balancing the demands of the business, user and supplier.
The executive is appointed by corporate, programme management or the customer during the pre-project process of starting up a project. The role of the executive is vested in one individual, so that there is a single point of accountability for the project. The executive will then be responsible for designing and appointing the rest of the project management team, including the other members of the project board.
If the project is part of a programme then corporate, programme management or the customer may appoint some or all of the project board members. The executive secures funding for the project and is responsible for the business case and continued business justification of the project.
The senior user role commits user resources and monitors products against requirements. For the sake of effectiveness the role should not be split between too many people. If necessary, more than one person may be required to represent the users. This role is accountable for the quality of products delivered by the supplier s and is responsible for the technical integrity of the project. This role will include providing supplier resources to the project and ensuring that proposals for designing and developing the products are feasible and realistic.
In most cases, the senior supplier also represents the interests of those who will maintain the specialist products of the project after closure e. In this instance the operations and maintenance interests are more likely to be represented by a senior user. In fact, the distinction is not really important; what matters is that operations, service and support interests are represented appropriately from the outset.
If necessary, more than one person may be required to represent the suppliers. If they have sufficient time available, and the appropriate level of skills and knowledge, they may conduct their own project assurance tasks; otherwise they may appoint separate individuals to perform these. The project board may also make use of other members of the corporate, programme management or customer organization to take on specific project assurance roles, such as appointing the corporate quality manager to monitor the quality aspects of the project.
Project board members are accountable for the project assurance actions aligned with their area of interest, even if they delegate these to separate individuals. Project assurance is not just an independent check, however. Personnel involved in project assurance are also responsible for supporting the project manager, by giving advice and guidance on issues such as the use of corporate standards or the correct personnel to be involved in different aspects of the project e.
Anyone appointed to a project assurance role reports to the project board member overseeing the relevant area of interest, and must be independent of the project manager.
The project board should not assign any project assurance roles to the project manager or project support. In a project where few changes are envisaged, it may be reasonable to leave this authority in the hands of the project board.
Technical knowledge may also be needed to evaluate potential changes. If it has not already been determined within starting up a project, the project board needs to decide, before the project moves out of the initiating a project process, if it wishes to delegate some authority for approving or rejecting requests for change or off-specifications. These delegated authorities must be written into the appropriate role descriptions. For projects that exist within a programme, the programme management should define the level of authority that the project board will have in order to be able to approve changes.
Refer to Chapter 11 for more information on change. This person has the authority to run the project on behalf of the project board within the constraints laid down by the project board. The role of the project manager must not be shared. The project manager will usually come from the corporate, programme management or customer organization, but there may be projects where the project manager comes from the supplier. Refer to section 7. The project manager is responsible for the work in all the PRINCE2 processes except for the directing a project process, and appointing the executive and the project manager in the pre-project process of starting up a project.
The project manager also delegates responsibility for the managing product delivery process to the team manager s. The project manager manages the team managers and project support, and is responsible for liaison with project assurance and the project board. In projects with no separate project support role, the support tasks also fall to the project manager, although they may be shared with team members. As the single focus for the day-to-day management of a project, there are many different aspects to the project manager role, some of which are shown in Figure 7.
The team manager role may be assigned to the project manager or a separate person. There are many reasons why the project manager may decide to appoint other people to be team managers rather than undertake the role themselves. Among these are the size of the project, the particular specialist skills or knowledge needed for certain products, geographical location of some team members and the preferences of the project board.
The project manager should discuss the need for separate individuals as team managers with the project board and, if required, should plan the role at the start of the project during the starting up a project process, or for each management stage in the preceding managing a stage boundary process. The project manager uses work packages to allocate work to team managers or team members.
They can be used formally or informally depending on the needs of the project. Defining the deliverables at the appropriate level will assist new team managers in becoming more effective as it is clear what has to be produced and, with the definition of reporting frequency and method, the feedback from the team manager can be clearly controlled.
If the team manager comes from the supplier organization, there could be a reporting line to a senior supplier. The structure of the project management team does not necessarily reflect line function or seniority but represents roles on the project. A team manager, for example, may be more senior in the corporate, programme management or customer organization than the project manager, or may be a senior representative from an external supplier.
In the context of the project, however, the team manager reports to, and takes direction from, the project manager. It could also provide specialist functions to a project such as planning or risk management. Unless performed by a corporate, programme management or customer function, project support is typically responsible for administering change control. The role of project support is not optional, but the allocation of a separate individual or group to carry out the required tasks is.
The role defaults to the project manager if it is not otherwise allocated. Key message Project support and project assurance roles must be kept separate in order to maintain the independence of project assurance. Some corporate, programme management or customer organizations may have a project office a temporary office set up to support the delivery of a specific project or a similar structure, which can fulfil some, or all, of the project support role.
For more information on the use of a project office, see Portfolio, Programme and Project Offices Cabinet Office, When combining roles, consideration should be given to any conflicts of responsibilities, whether one person has the capacity to undertake the combined responsibilities, and whether any bottlenecks might be created as a result. Also, it is not recommended to combine the roles of senior user and senior supplier as this can create conflicts of interest for an individual.
PRINCE2 provides role description outlines in Appendix C, and they should be tailored to the needs of the specific project and each specific appointment. In addition, each theme chapter provides the responsibilities relevant to that theme. It facilitates engagement with stakeholders through the establishment of a controlled and bidirectional flow of information.
The project manager is responsible for documenting the communication management approach during the initiating a project process. It is also important to review and possibly update the communication management approach at each management stage boundary in order to ensure that it still includes all the key stakeholders. When planning the final management stage of the project it is also important to review the communication management approach to ensure it includes all the parties who need to be advised that the project is closing.
If roles are combined then all the responsibilities in this table must still be undertaken. Table 7. Executive Appoint the project manager if not done by corporate, programme management or the customer. Confirm the appointments to, and structure of, the project management team. Approve the communication management approach. Senior user Provide user resources. Define and verify user requirements and expectations. Senior supplier Provide supplier resources. Advise on the technical aspects of the proposed products.
Project manager Prepare and update the communication management approach. Design, review and update the project management team structure. Plan and undertake stakeholder engagement. Prepare role descriptions.
Team manager Manage project team members. Advise on project team members and stakeholder engagement for their part in the project.
Project assurance Advise on selection of project team members. Advise on stakeholder engagement. Ensure that the communication management approach is appropriate and that planned communication activities actually take place.
Project support Provide administrative support for the project team. The right people with the right experience need to be in the right roles, in the right numbers and at the right time. Roles and responsibilities need to be carefully considered for all projects. For smaller, simpler projects, the primary concern often is how to ensure that all PRINCE2 responsibilities are fulfilled by a relatively small set of people.
Some points to consider include: Scaling the project management team is primarily about consolidating role and function. Roles can be combined but should not be eliminated. As the executive and senior user roles are both from the customer environment, these can often be combined. As the project manager is likely to be much closer to the project board than on larger, more complex projects, members of the project board are often in a better position to carry out their own project assurance rather than appointing another individual to fulfil this role.
For small teams it may not be necessary to appoint team managers. The project manager of a simple project can carry out those responsibilities. For example, there may be multiple senior users. In such circumstances, the primary concern is ensuring that individual accountabilities, limits of delegation and authority, and governance are absolutely clear. In contrast, the standard practice in project- focused corporate organizations is to work with project teams.
The level of overlap between the interests of the business, user and supplier stakeholders will change according to the type of corporate, programme management or customer organization and project. For example, there are likely to be more overlapping interests between the business and an in-house supplier than an external supplier. A project which forms part of a programme may be impacted by the programme structure and its various reporting requirements.
The programme and project management team structures and roles need to be integrated such that: there are clear lines of responsibility from top to bottom i. The integration of roles may involve the following: The programme manager may be the executive for one or more of the projects.
Within a programme, there may be multiple project boards, a single body directing several projects effectively replacing multiple project boards or a combination of the two.
A business change manager from the programme may fulfil the project role of senior user or have input into the appointment of the senior user for one or more of the projects, or be the executive for one or more of the projects. The purpose of a design authority at a programme level is to ensure that there is appropriate alignment and control when changes are being planned and implemented.
A single programme office may take project support responsibilities for all projects. Programme manager, business change manager and design authority are defined in Managing Successful Programmes Cabinet Office, and fulfil programme-level requirements. What are the roles of business change manager and design authority? The business change manager is a senior role drawn from the area of the business affected by the programme.
The design authority provides expert advice about, and may have responsibility for, some corporate function, service, standard or strategy that will be affected by the programme. The choice of project structure and appointments will depend on the needs, complexity and scale of the programme.
Stakeholder analysis for the project may be performed by the programme, or the programme may require the project to take a lead with certain stakeholder groups with which it has good engagement.
The aim is to ensure that both organizations establish and maintain sound business justification for their work and that their individual governance is respected.
It is important that the project manager has a good understanding of their obligations under any contract with the supplier organization. The customer may choose to stay at a distance from the working level and expect the supplier to provide the management of the project.
The customer is likely to increase the rigour in project assurance and indeed may choose to appoint one of its own staff to fulfil the role of project assurance. Ensure that every member of the project team understands their project responsibilities regardless of their job title and description. There may be a joint project board with representatives from the customer and all the suppliers that the customer has engaged.
The executive on this joint project board may be supplied by the customer and the senior suppliers will represent each of the suppliers. If there are multiple suppliers, all of them may be represented on the project board as it provides a forum for them to integrate direction and decision-making.
If there are more than three or four suppliers, however, then it will be typically more effective for the contracts manager responsible for the performance of all the supplier contracts to sit on the project board on their behalf, or it may be appropriate to appoint a prime contractor. During procurement, the project may need a temporary appointment from within the customer organization say, from its procurement team for the senior supplier role until a supplier has been appointed.
The project manager will need to understand: how a self-organizing delivery team operates and how this relates to the team manager and change authority roles the responsibilities of roles in the agile approach being used that, in an agile environment, the user is often represented by a single person, often referred to as the product owner. However, in the context of a project, a wider view of the customer is likely to be needed due to the cross-functional nature of projects how agile team leaders liaise with the project manager when more than one team is involved.
This empowers the project management team and enables it to self-organize within clearly defined boundaries. It does not matter what a role or job is called as long as all the responsibilities outlined in Appendix C are fulfilled on each project.
Your name will be printed on your certificate and the address you enter is the one where the certificate will be sent. The invigilator will provide you with a unique candidate number. This number uniquely identifies you and you must write this number onto the candidate details form.
Once you have completed this form, the invigilator will check your photo-ID and collect up the forms. From then on, everything you write must be in pencil — ideally HB, as this is the only type which can be scanned easily. You will then be given an answer sheet where you must fill in your candidate number at the top — see the picture on the next page. When the exam starts, you will fill in your answers on this sheet. There are only 2 correct ways to complete your answer sheet: either completely fill in the oval shape, or draw a thick horizontal line through the oval.
Any other way and you run the risk that the machine which scans your paper may not read it properly and so you could fail. See the example below. After filling in your candidate number on the answer sheet, the exam is ready to start. At this point the invigilator will give you the question booklet. This will contain all of the 75 questions. You must write your candidate number on the front cover. This booklet may not leave the room, so if you go to the toilet during the exam, you must leave this booklet in the examination room.
It must also be handed back to the invigilator at the end of the exam along with your answer sheet. In which of the following processes does the Project Board choose a suitable risk response? Controlling a Stage b. Managing a Stage Boundary c. Directing a Project d. Starting Up a Project. Which of the following tasks form part of the product-based planning method? Writing the product descriptions ii. Creating a product flow diagram iii. Designing the plan iv. Creating the product breakdown structure.
For the above question, read the statements i-iv, and then decide which three form part of the product-based planning method. I suggest that you read each of the 4 options and tick the ones you are sure form part of the technique. If there are only 2 options you are sure about, at least you have reduced your last decision to a choice between the 2 remaining options, so pick one of them and then mark your answer paper accordingly.
The number one revision method is to practice those exam questions! As the questions are compiled from a limited question bank, the more practice questions you attempt, the more prepared you will be.
Secrets to successful outsourcing: Part 1. Secrets to successful outsourcing: Part 2. Managing Risk Mini Quiz. Project Management Qualifications: Are you on the right track? Example risk management approach and risk register — health service conference.
Example business case — health service conference. Example project product description — health service conference. Sample Project Brief. Example project plan — health service conference. Treading the Learning Path.
0コメント