PRINCE2 Principles PDF

Managing Successful Projects with PRINCE2 CHAPTER 2 ew P e on op ly leC C op no er yr t f t c ig or op ht r y © ed rig 20 ist ht 23 rib ut io n Definition: PRINCE2 principles The PRINCE2 principles are the guiding obligations that determine whether the project is genuinely being managed using PRI...

Managing Successful Projects with PRINCE2 CHAPTER 2 ew P e on op ly leC C op no er yr t f t c ig or op ht r y © ed rig 20 ist ht 23 rib ut io n Definition: PRINCE2 principles The PRINCE2 principles are the guiding obligations that determine whether the project is genuinely being managed using PRINCE2 and ensure effective application and tailoring of PRINCE2 to any project. PRINCE2 is suitable for every project, regardless of type, size, complexity, importance, level of risk, or delivery method (linear-sequential, iterative-incremental, or hybrid). Moreover, it can be used for all types of organizations, whether commercial, governmental, non-profit, or not-for-profit. Additionally, it is applicable for projects anywhere in the world, with its ability to incorporate country-specific regulations, business models, and cultures. To enable PRINCE2 to be used for such a wide range of projects, the method is flexible in how it can be used for any given project. Rather than prescribing what to do to align the method to the specific project, PRINCE2 offers guidance through principles. These principles enable the project management team to decide how PRINCE2 will be used on their project. The seven PRINCE2 principles are: ● ensure continued business justification ● learn from experience ● define roles, responsibilities, and relationships ● manage by stages ● manage by exception ● focus on products ● tailor to suit the project. How the method is applied and tailored depends on the nature of the project and factors internal and external to the business as shown in figure 2.1. Vi Chapter 2 - Principles PRINCIPLES 20 External (to project) Principles Project specific arrangements documented in… Organizational context e.g. sector, capability, culture, policies (e.g. management approaches) Project plan Internal (to project) ew P e on op ly leC C op no er yr t f t c ig or op ht r y © ed rig 20 ist ht 23 rib ut io n Typical contexts Tailor Commercial context e.g. contracts, relationships Delivery method e.g. lifecycle model, development techniques, terminology Stage plans Apply Using the method. For example, assigning roles, number of stages, number of teams/work packages, setting tolerances or choice of supporting techniques Team plans Project scale e.g. complexity, duration Figure 2.1 How to apply and tailor PRINCE2 to a project The seven principles offer flexibility, as they provide guidance on how the integrated elements of the method can be applied and tailored to find the best fit for the project and its context while keeping the integrity of the method. So long as the principles are followed, PRINCE2 is being used effectively. 2.1 Ensure continued business justification Key message A PRINCE2 project has business justification sufficient to warrant investment to initiate the project and ongoing investment through to successful completion. If it does not, it should be stopped. Vi There must be a justifiable reason for starting a project, and the justification must remain valid and be revalidated throughout the lifecycle of the project. The business justification drives decision-making to ensure the project remains aligned with the benefits sought and contributes to business objectives. Organizations that lack rigour in business justification may find that projects proceed even when there are few real benefits or when a project has only tentative associations with the business strategy. Poor alignment with business strategy can also result in organizations having a portfolio of projects that have inconsistent or duplicated objectives. 21 Chapter 2 - Principles Sustainability context e.g. business drivers and priorities Changing the method. For example, using alternative terminology or replacing a PRINCE2 technique Project initiation documentation Managing Successful Projects with PRINCE2 Compulsory projects, such as those driven by legislation or regulation, still require justification for the chosen approach to ensure it represents the best value for money. All parties involved in the project will need a balance between expected benefits, costs, and risks for them to have business justification for their involvement. ew P e on op ly leC C op no er yr t f t c ig or op ht r y © ed rig 20 ist ht 23 rib ut io n After the project is completed, the project should be reviewed to evaluate if the benefits have materialized sufficiently to warrant the final investment and what lessons can be learned from the project. Below are some examples of the application of the ‘ensure business justification’ principle. For a commercial project with one or more customers and suppliers, each party will need to have a clear business justification to undertake the project and to continue with it. The customer may want to enhance market share by introducing a new product. The supplier’s business justification might include non-financial benefits, such as gaining an impressive customer reference for promotional purposes or building experience in applying new technologies. For a co-owned project, such as a governmental project to jointly develop a new IT system across a number of agencies, if the business justification is lost for one or more parties, those parties should consider ending their participation in the project. In this case, the consequences of ending or withdrawing participation in the project, such as contractual obligations, will inform the decision and any approach to prematurely close the project. Throughout the project, each investing party will need to keep monitoring their own business justification to ensure that the project is still worthwhile for them. 2.2 Learn from experience Key message A PRINCE2 project team actively seeks, records, and implements improvements as a result of relevant lessons learned from prior projects and throughout the life of the project. It applies them in future projects and shares them for others to apply. Vi Chapter 2 - Principles The business justification for a project may change; therefore, it is important that what the project is delivering remains consistent with the evolving justification. If continuing with the project can no longer be justified, then it should be stopped and end in a controlled way. Cancelling a project in these circumstances is a positive contribution to the business as the project’s funds and resources can be reinvested in other more worthwhile projects. A common characteristic of projects is that they include an element of uniqueness. This makes projects challenging as the temporary team may not have experience of a project quite like the one being undertaken. To overcome these challenges, project teams need to find ways to learn from the experience of others and from the experience gained from the project as it develops. 22 Principles Learning from experience occurs throughout the lifecycle of the project: ● When starting a project Previous or similar projects should be reviewed to see if lessons could be applied. If the project is a ‘first’ for the people within the business or if there is any content which is new or novel, then it is even more important to learn from others. This could include projects delivered by people or organizations external to the business to identify relevant lessons. ew P e on op ly leC C op no er yr t f t c ig or op ht r y © ed rig 20 ist ht 23 rib ut io n in relevant reports and reviews and included at the end of each stage. The goal is to seek opportunities to implement improvements during the life of the project. The retrospective technique is an example of gathering lessons in agile approach. ● As the project closes The project team should share the insights gained during the project. The foundation for learning is data and the ability to gain insights from it. Projects should be clear about what data is required, how it will be analysed so that insights can be gained and applied, and what will happen to the data during the project and when the project closes. Project teams need to consider how to effectively share lessons with all those involved in the project, as people may have different learning needs and preferences. Some may learn best by observing, whereas others do so by experimenting. It is important to learn from both mistakes and successes to continuously improve and innovate. It is the responsibility of everyone involved with the project to identify lessons rather than wait for someone else to do so. Lessons that are not used to improve the project, or future projects, are only ‘lessons identified’ and not actually ‘lessons learned’. Below are some examples of applying the ‘learn from experience’ principle. In a smaller project with one co-located team, ‘lessons learned’ can be discussed on a regular basis in team meetings. Learning in this case happens on the job, potentially on a daily basis. In a large and complex project, the learning process will involve many project team members who could be spread across multiple teams and locations. This large-scale approach will make it harder to ensure everyone has access to the same learning experience. Vi Learning in larger projects may require more advanced communication, such as explanatory videos, presentation kits for project team managers, or tailored workshops in subgroups. Such projects may benefit from field trips, pilots, simulations, or go-live rehearsals as a source of learning too. 23 Chapter 2 - Principles ● As the project progresses The project team should continue to learn. Lessons should be included Managing Successful Projects with PRINCE2 2.3 Define roles, responsibilities, and relationships ew P e on op ly leC C op no er yr t f t c ig or op ht r y © ed rig 20 ist ht 23 rib ut io n A PRINCE2 project has defined and agreed roles and responsibilities within an organization structure that engages the business, user, and supplier stakeholder interests. Moreover, a PRINCE2 project management team initiates and builds relationships with and between internal and external stakeholders. Projects need people. It is important that the right people are involved, and they know what is expected of them and what they may expect from others in the project. Successful projects require an understanding of the relationships with and between stakeholders and ongoing activities to strengthen them. This is why ‘People’ is one of the five integrated elements of PRINCE2. Stakeholders can be individuals or groups within or external to the business. Stakeholders within the business could be a work council, sustainability board, diversity board, owners, department leaders, or other project teams; stakeholders outside the business could be trade unions, customers, suppliers, communities, interest groups, banks, or the media. All projects have the following primary stakeholders: the business, users, and suppliers (see section 1.5.1). All three stakeholder interests need to be represented effectively in the project management team; this is reflected in the design of a PRINCE2 project board (see section 6.2.1). Defining roles and responsibilities is particularly challenging as projects are cross-functional, may involve more than one organization, often have a mix of full and part-time resources, and may be spread across multiple locations. The management structures of the parties involved in the project are likely to be varied, with different priorities, objectives, and interests to protect. The day-to-day line management structures of the business may not be designed for, or suited to, project work. The assignment of roles to individuals throughout the life of the project and their responsibilities must be clear, unambiguous, and accepted. To be successful, projects must have an explicit project management team structure consisting of defined and agreed roles and responsibilities for the people involved in the project. Moreover, the projects must have an understanding of the relationships and a means for effective communication between them. The goal is to clearly articulate roles and responsibilities to provide a clear, coherent structure that all stakeholders understand and is suitable to enable effective project delivery performance against the project performance targets. Vi Chapter 2 - Principles Key message Below are some examples of applying the ‘define roles, responsibilities, and relationships’ principle. If the project is part of a programme, then some of the project responsibilities may be held by people in the programme management team. In this case, the programme’s business change manager (BCM) may undertake the project executive or senior user role on the project board to help align the project with the programme. The programme management office (PMO) could provide project support, or the programme’s design authority could be given decision-making responsibility for authorizing changes at the project level. Agreements need to be made about who accepts which project role and the authority 24 Principles and responsibility they each have. The goal is to enhance consistency and coherence between the project and the programme. ew P e on op ly leC C op no er yr t f t c ig or op ht r y © ed rig 20 ist ht 23 rib ut io n For projects that have development teams using agile development methods, the PRINCE2 team manager role may be held collectively by the development team. 2.4 Manage by exception Key message A PRINCE2 project establishes limits of delegated authority by defining tolerances for performance against its plans. Definition: Tolerance The permissible deviation above and below the plan’s target for benefits, cost, time, quality, scope, sustainability, and risk without needing to escalate the deviation to the next level of management. Tolerance is applied at project, stage, and team levels. PRINCE2 enables appropriate governance by defining distinct responsibilities for directing, managing, and delivering the project and clearly defining accountability at each level. Accountability is established by: ● delegating authority from one management level to the next by setting tolerances against the seven Vi aspects of performance (benefits, cost, time, quality, scope, sustainability, and risk) for the respective level (project, stage, team) ● establishing controls so if tolerances are forecast to be exceeded, they are flagged as being an exception and immediately escalated to the next management level for a decision on how to proceed ● establishing an assurance mechanism so that each management level can be confident that the exception controls are effective. 25 Chapter 2 - Principles The nature of the project will determine the number of stakeholders and the amount of change it creates for each of them. A project with a small number of stakeholders and a high degree of impact will have a very focused approach to engaging with them, perhaps on an individual and personal basis. A project with a large number of stakeholders and a wide range of impacts may have to use multiple approaches with a mix of personalized engagement and more general engagement through surveys and broadcast channels (such as emails). Managing Successful Projects with PRINCE2 The seven aspects of a plan’s performance requiring tolerances to be defined are: ● Benefits The degree to which it is permissible to underdeliver or overdeliver benefits; for example, the business case for a sales improvement project modelled with a plus or minus two percent range of increased income generation. hours and financial). ● Time The degree to which it is permitted to deliver earlier or later than an agreed target completion ew P e on op ly leC C op no er yr t f t c ig or op ht r y © ed rig 20 ist ht 23 rib ut io n date compared to the project plan, stage plan, or work package description. ● Quality How much something can vary from agreed acceptance criteria; for example, a project to produce a new sports watch might have a target that the watch should work underwater to a depth of 50 metres with a permissible tolerance of plus or minus five metres. ● Scope Permissible variation of the plan’s products; for example, a project requiring delivery of all the must-have mandatory requirements but permitted to deliver only 60 percent or more of its shouldhave and could-have requirements. ● Sustainability The degree to which the project product or project activities required to deliver the project can vary from sustainability targets; for example, a new production line that operates within five percent of an emissions target and was delivered using around 70 percent of workforce coming from the local community. ● Risk Limits on the plan’s aggregated risks; for example, a tolerance that the cost of aggregated threats must remain less than 10 percent of the agreed budget and that the cost of any single threat must be no more than five percent of the budget. The implementation of ‘manage by exception’ provides for efficient use of senior management time as it reduces senior managers’ time burden without removing their control. This ensures that decisions are made at the right level in the organization. The goal is to alert the next management level in the project as early as possible that the work will move outside of agreed tolerances, and a decision is needed on if and how to proceed. The decision-maker can decide to accept the deviation and its consequences or act to remove or reduce it. A project using an iterative-incremental delivery method with defined timeboxes will typically fix time and cost and vary in scope. In this case, time and cost will have much tighter tolerances set than the scope. An example of applying the ‘manage by exception’ principle is that the use of tolerances will differ depending on the project’s context, such as a project with a commercial arrangement between customer and supplier where the tolerances will be reflected in the contract. In this example, if the project manager learns that procured materials will be delivered late and the issue cannot be resolved within the tolerances, the project manager will need to alert the project board quickly. The contract may define any cost remedies available between the customer and supplier, but there may be consequences for the project’s stakeholders caused by the delay. In this case, the project board will need to decide what actions to take and provide direction to the project manager. By reviewing the tolerances at the end of every stage, the project is able to adapt and modify the next stage activities to reflect a changing operating environment. Vi Chapter 2 - Principles ● Costs The degree of permissible overspend or underspend against an agreed budget (both person- 26 Principles 2.5 Manage by stages ew P e on op ly leC C op no er yr t f t c ig or op ht r y © ed rig 20 ist ht 23 rib ut io n A PRINCE2 project is planned, monitored, and controlled on a stage-by-stage basis. Definition: Stage The section of a project that the project manager is managing on behalf of the project board at any one time. The focus on managing by stages ensures that the project is properly initiated before work starts on delivery of the project’s outputs. Every PRINCE2 project should have at least two stages: an initiation stage and one further stage. Many projects benefit from having more than two stages. Advantages of managing by stages are: ● It enables adaptability to changes in the project or business context. ● It provides review and decision points, giving the project board opportunities to assess the project’s viability at defined intervals rather than let it continue in an uncontrolled manner. ● It provides the ability to ensure that key decisions are made prior to the detailed work needed to implement them. ● It allows clarification of what the impact will be of an identified external influence, such as the organizational budget setting process or the finalizing of legislation. ● It facilitates the principle of manage by exception by delegating authority to the project manager at each stage. The choice of appropriate stages for a project will depend on a number of factors (see 7.2.3), including: ● minimizing risk exposure through the project lifecycle ● the size and complexity of the project (shorter stages offer more control, whereas longer stages Vi reduce the effort for senior management) ● any significant decisions and control points required during the project’s lifecycle; these will often be linked to key investment, business, or technical decisions ● sector or business policies and standards. The project board authorizes one stage of the project at a time and delegates the authority for day-today control of the stage, within agreed tolerances, to the project manager. As long as the stage is forecast to remain within tolerance, the project manager is authorized to make adjustments as required. The project board only authorizes the next stage if there is sufficient business justification and funds to 27 Chapter 2 - Principles Key message Managing Successful Projects with PRINCE2 continue. If the project no longer has a valid business case, the project board will determine whether and how to recover the project or prematurely end it. ew P e on op ly leC C op no er yr t f t c ig or op ht r y © ed rig 20 ist ht 23 rib ut io n 2.6 Focus on products Key message A PRINCE2 project focuses on the definition and delivery of products, in particular their user quality expectations and requirements. Definition: Product An input or output, whether tangible or intangible, that can be described in advance, created, and tested. PRINCE2 includes four types of products: ● Management products Are often documents or information needed to support the management of the project, such as a business case or a plan. ● Specialist products Are the products that are needed by the user to realize the benefits required of the project. ● The project product Describes the total output from the project as defined in the project product description (see section 7.3.2.1). ● External products Are products developed or provided outside of the project’s control but which the project is dependent on, for example, the publication of a new standard. Specialist products will be referred to throughout the book as simply ‘products’, except when a distinction is needed between management and specialist products. The term ‘project products’ refers to the specialist and management products created during the project. Vi Chapter 2 - Principles An example of applying the ‘manage by stages’ principle is when teams work in ‘sprints’ or ‘timeboxes’ while operating incrementally and iteratively to realize the agreed features and user stories. PRINCE2 can be tailored to work with sprints and user stories instead of work packages and product descriptions. The project manager will define how many sprints are required for each stage. In this way, the project is consistent with the principle of manage by stages. Projects that focus on what the project needs to produce are more likely to be efficient and avoid waste than projects that focus primarily on the work activity. This is because the purpose of a project is to fulfil stakeholder expectations in accordance with the business justification. Therefore, there must be a common understanding of the products required and the user quality expectations for them. The purpose of a project can be interpreted in many different ways, unless there is an explicit understanding of the products to be produced and the criteria against which they will be individually 28 Principles approved. PRINCE2 requires projects to be output-oriented rather than work-oriented. PRINCE2 calls these outputs ‘products’. This focus on products: ● ensures that the project only performs work that directly contributes to the delivery of a product ● helps manage uncontrolled change (‘scope creep’) by ensuring that all changes are agreed in terms of how they will impact the project products and the business case for the project ew P e on op ly leC C op no er yr t f t c ig or op ht r y © ed rig 20 ist ht 23 rib ut io n ● reduces the risk of user dissatisfaction and acceptance disputes by agreeing (at the start of the project) what will be produced by the project ● assists a pause or closure of the project. Agreement can be more easily met to pause or close a project after certain products are completed. It also allows easier and controlled resumption of the project. An output-oriented project is one that agrees and defines the project product prior to undertaking the activities required to produce it. The set of agreed products defines the scope of a project and provides the basis for planning and control. A PRINCE2 project uses product descriptions that provide the means to determine effort estimates, resource requirements, dependencies, and activity schedules. The focus on products supports almost every aspect of PRINCE2: planning, responsibilities, progress reporting, quality, change control, acceptance, and risk management. Below are examples of applying the ‘focus on products’ principle. In a small simple project, such as publishing a new management book, a single project product description might suffice. This description will determine, among others features, how many chapters will be required, the desired total number of pages, the language, and the number of graphics in colour versus black and white. Product descriptions for projects using an iterative-incremental delivery method, such as agile, may be in the form of requirements, features, epics, and user stories. For larger and more complex projects, the project product description will be divided into sub-products and then further subdivided to a level of detail to understand how each product will be sourced, developed, and approved. The further the products are subdivided, the harder it will be for the project board to be able to decide whether product descriptions are correct. This is because the content becomes more technical and will require specialist knowledge to understand. In this case, it is important that the supplier has the expertise to define the right products at each level, and the business establishes project assurance with the knowledge necessary to assure that the product meets the specification. Tailor to suit the project Vi 2.7 Key message PRINCE2 is applied and tailored to suit the project environment, size, complexity, importance, delivery method, team capability, and level of risk. 29 Chapter 2 - Principles (that is, the project does no more work than it needs to deliver its agreed products) Managing Successful Projects with PRINCE2 PRINCE2’s value is that it is a universal project management method that can be applied to take account of the project’s context, scale or size, delivery method, stakeholder landscape, complexity, importance, team capability, and level of risk. Furthermore, it can be used for any project type, geography, or culture. It can be used on any project because the method is designed to be applied and tailored to suit each project’s specific needs and context. ● the project management method used is appropriate to the project (for example, aligning the ew P e on op ly leC C op no er yr t f t c ig or op ht r y © ed rig 20 ist ht 23 rib ut io n method with the business processes that may govern and support the project, such as human resources, finance, and procurement) ● project controls are appropriate to the project’s scale, complexity, importance, delivery method, team capability, and risk (for example, the frequency and formality of reports and reviews). Tailoring requires the project board and the project manager to make proactive choices and decisions on how PRINCE2 will be applied. It may also involve adjusting the terminology to match terms used by the organizations involved or replacing some of the PRINCE2 techniques (such as the risk management technique) with alternative procedures such as those already used by the business or supplier(s). When tailoring PRINCE2, it is important to remember that effective project management requires information (but not necessarily documents) and decisions (but not necessarily meetings). If PRINCE2 is not tailored, it is unlikely that the project management effort and management approaches would be appropriate for the needs of the project. This can lead to inattentive project management at one extreme, where PRINCE2 is followed without question, or ‘heroic’ project management at the other extreme, where PRINCE2 is not really followed at all. The project manager is responsible for tailoring and will make recommendations having consulted relevant lessons and standards. The project board is accountable and needs to approve the recommendations at the end of the initiation stage and every time there is a proposed change to the management approaches. How PRINCE2 will be applied and tailored for the particular project is captured in the project initiation documentation. This ensures that all those involved in the project understand how PRINCE2 is to be used and how to carry out their responsibilities. Care should be taken that the proposed tailoring is consistent with PRINCE2’s seven principles and that the resultant method retains its integrity. An example of applying the ‘tailor to the suit the project’ principle is where the project has a commercial customer-supplier relationship. The project may need to align the project management processes, practices, and documentation to two or more quality systems, one from the customer and one from the supplier. For example, a supplier may wish to use their in-house product development framework based on an iterative-incremental delivery method using agile management approaches. To avoid potential confusion, the project manager might propose to: ● map and define terminology between PRINCE2 and the supplier’s agile management approaches ● add the project team roles of ‘customer subject matter expert’ and ‘supplier subject matter expert’ Vi Chapter 2 - Principles The purpose of tailoring is to ensure that: to the agile team, representing the customer and the supplier respectively ● add a coach to guide the teams in working effectively in the combination of PRINCE2 and the supplier’s in-house agile method ● collaborate and communicate according to agile ways of working, such as a daily stand-up and support agile reporting tools, such as information radiators ● define project procedures, such as working with sprints or work packages, product descriptions, or user stories, and how to use these in the project. 30