PRINCE2 FLASH CARD SUMMARIES

Transcription

1 PRINCE2 FLASH CARD SUMMARIES The Perfect Way To Grasp The Key Learning Elements of PRINCE2 Copyright David Geoffrey Litten

2 First Edition 2008 Copyright of text and diagrams 2008, David Geoffrey Litten. Published by Casablanca Publishing. All rights reserved The right of David Geoffrey Litten to be identified as the author of this work has been asserted in accordance with the Copyright, Designs and Patents Act 1988 All PDF files and Video s have been encoded with a unique tracking identifier. Anyone found engaging in illegal copying will be prosecuted under the full extent of the law. PRINCE2TM is a trade Mark of the Office of Government Commerce. PRINCE is a Registered Trade Mark and a Registered Community Trade Mark of the Office of Government Commerce and is registered in the U.S. Patent and Trade Mark Office No part of this publication and the accompanying Video Set may be reproduced, stored in a retrieval system or transmitted in any form or by any means electronic, mechanical, photocopying, recording or otherwise without the prior written permission of the publisher Notice No responsibility is assumed by the publisher for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions or ideas contained in the material herein.

3 PROCESS The Project Processes The 8 Processes may be considered as a set of "Toolkits" to be used WHEN needed. Some processes are normally only used only once during a project: Starting Up a Project Initiating a Project Closing a Project Other processes are used on a regular basis WHEN needed: Controlling a Stage Managing Product Delivery Managing Stages Boundaries One process is used continuously from the beginning of the project until the close of the project: Directing a Project Finally, Planning Within PRINCE2, all plans are documents. And so one process is designed to be used whenever a Project, Stage, Team, or Exception Plan is to be created (or possibly updated).

4 PROCESS Starting up a project (SU) This is the pre-project preparation process, consisting of a high level analysis of the project. It is also where the project management team are designed and appointed. The information gathered and created in this process is put before the project board, which is where they meet for the first time, so that they can make a decision whether or not to start the project. They should agree that the project makes sense to do, and if so, agreed to invest in the creation of the Project Initiation Document. The project mandate triggers starting up a project, and ensures that a business requirement exists. SU must answer do we have and viable and worthwhile project" SU is designed to ensure that the pre-requisites for the initiation stage are in place. SU provides management products that provide basic information such that the project board can make an informed choice whether or not to invest in the initiation stage and the creation of the Project Initiation Document. SU creates the plan for the initiation stage which covers the time and resources for the creation of the project initiation document, and the time and resources to prepare and plan for the second stage.

5 PROCESS Initiating a Project (IP) This process is used during the first stage - the Initiation Stage, and assembles the project initiation document (PID). The PID defines in as much detail as is possible at this time, the definition of the project including creation of the project plan and business case and how the project will be controlled. Other key documents include the project quality plan, the configuration management plan, the communication plan, and implementing the controls. In addition the remaining logs are created: the quality log, the Lessons Learned Log, and the Issue Log (which is also used to log changes). This information will be presented to the project board, who meet for the second time to authorise the project. It is not until the second stage that any specialist products are created. The PID set out WHAT the project is intended to achieve, WHY it is needed, HOW the outcome is to be achieved WHEN activities are to happen, and what (WHO) people's responsibilities are. Responsibility for the creation of the PID is the project manager s assisted many others. The project is split into a number of management stages; the first stage is called the Initiation Stage. The minimum number of stages is two. A stage is defined as partitions of the project with management decision points", and at the end of each stage, the project board must approve the next stage plan including the resources required before authorising the project manager to control and manage that stage. Once the PID is signed off by the project board it is they that now own the project The PID will be used as a "baseline" against which to monitor and manage control and report throughout the project. Parts of the PID will be updated at the end of each stage to reflect the latest progress and understanding. It is important that the PID contains a viable Business Case demonstrating that the benefits to be realised worth the time, effort, cost and risks

6 PROCESS Directing a Project (DP) This process is used by the project Board who represents the business, users and suppliers. They make all the key decisions and must have the authority to exercise overall control and commit resources during the project life cycle. The project board manages by exception, monitors and via reports and controls through a number of decision points. Manage By Exception. This is done by releasing the project to the project manager one stage at a time, and setting a tolerance band that the stage must complete within. The project board are kept informed of stage status by regular highlight reports from the project manager. If the stage is forecast to exceed tolerance, then the project manager brings this to the project board's attention by issuing an Exception Report. The project board will then decide I to prematurely close the project, or to request an Exception Plan, which if authorised by them, will replace the existing stage plan that would no longer finish within tolerance The project board meets to authorise the initiation stage, then again to authorise the project by signing off the PID. After this they will meet at the end of each stage (End Stage Assessment), to agree or not that the project should continue. At the end of the project, the project board meets for a final time to confirm that the project should be closed. The project board is also responsible for communicating with external interested parties. The sub-process "Giving Ad-Hoc Direction" is used as a communication path both within, and external to the project. All other sub-processes are "event-driven" in that the project board brought together to provide direction and authorisation as and when needed.

7 PROCESS Managing Stage Boundaries (SB) This process is only used for two purposes: preparation for an End Stage Assessment leading to approval or otherwise of the next stage plan, or... preparation for an Exception Assessment - leading to approval or otherwise, of an Exception Plan. The project manager will do most of the work in preparing for the end stage assessment - or an exception assessment if needed. But the Project Manager will be assisted by others such as project support, Project Assurance, the Configuration Librarian, and even the specialist team who may have been involved in the creation of the Team Plan, as well as contributing to creation of the Stage Plan. This process includes updating of the Project Plan, the Business Case, the Risk, Issue, Quality and Lessons Learned Logs, and checks that all other information and documentation is correct. Among these other checks are: Checking that the Project Management Team members are still appropriate, or that new members are required, e.g. a new supplier is needed in the next stage. Is the Project Approach still working, and does the Project Quality Plan strategy need adjusting? Does the Communication Plan need updating for new interested parties? Update the Configuration Item Records to ensure that they are in agreement with the actual status of products. An End Stage Report is prepared to present to the project board summarising the results of the current stage along with the high level of view of the project and business case. This is accompanied by the Next Stage Plan. In summary, SB is used to create and update all relevant project information so that the project board can make an informed choice about whether or not to proceed with the project.

8 PROCESS Controlling a Stage (CS) Part One The project manager is given responsibility for day-to-day management of the project, one stage at a time. As part of an End Stage Assessment (or an Exception Assessment), the Project Board will hopefully approve the Next Stage Plan (or Exception Plan). They will also advise the Project Manager how often they want to receive Highlight Reports, and they will set Stage Tolerance so that Management By Exception can operate. The CS process is used by the project manager to manage each stage, once the project board has approved the stage or exception plan. Once a decision has been taken to proceed with work and resources have been committed, the project management team must be focused on delivery within the tolerance laid down. During the stage, the project manager must ensure that the stage's products are passing their quality criteria and being approved, that the resources used and forecast are sufficient for the remainder of the Stage, that the risks are kept under control, and the business case kept under review. The Project Manager has the authority, providing the stage is forecast to fall within Tolerance, to take any corrective action that they believe necessary. Note that the Project Board Executive is responsible for the Business Case but regular management and updating of that document may be delegated to the Project Manager. During the Stage, the Project Manager, will authorise new Work Packages, receive regular checkpoint Reports from the team, and create regular Highlight Reports to the Project Board.

9 PROCESS Controlling a Stage (CS) Part Two Controlling a Stage consists of the following key activities: 1. Authorising work packages and ensuring that they are accepted by the specialist team 2. Receiving regular feedback on the Work Package status, and assessing the bigger picture of actual stage progress 3. Receiving advice of completed Work Packages and ensuring that they are complete and all arrangements have been carried out in a satisfactory manner 4. Create regular Highlight Reports to keep the Project Board informed of stage progress both in terms of actual progress and future forecast. The Highlight Report will also contain information such as budget, schedule, issue, risk, and tolerance situations. 5. Reviewing the remainder of the stage and ensuring that it can be completed within tolerance, and taking corrective action if needed, when the stage is forecast to complete within tolerance 6. Capture and examine project issues including an impact analysis on each 7. Escalate project issues to the project board if tolerance is forecast to be exceeded, via an Exception Report

10 PROCESS Managing Product Delivery (MP) The objective of this process is to ensure that planned products are created and delivered by the specialist team under the control of a Team Manager or the team themselves. PRINCE2 takes the view that the job of the project manager is to manage the team, not to do the work of product creation. MP allows a controlled break between the project manager and product creation/provision by third party or internal suppliers. The Stage Plan is split into Work Packages (each containing at least one Product description), and these are authorised by the project manager, and then given to the specialist team who needs to agree that they will carry out the Work Package. Optionally, a Team Plan can be created as part of agreeing the Work Package. Once the Work Package has been agreed then work will start in creating the products within the work package, and carrying out quality checks such that the products meet the quality criteria contained within each Product Description. As each product is approved, arrangements must be made so that the product is protected from change or damage. If the product type allows, the product will often be returned to the Configuration Librarian. The team or Team Manager must key the project manager informed of the Work Package progress, by sending regular Checkpoint Reports (or meetings) to the project manager, and keeping the Quality Log updated. The Quality Log contains planned, and eventually, actual dates of all specialist product quality checks. Once all products have been approved and authorised, then the work package is complete, and the project manager must be informed so that this can be agreed. As each Work Package is finished, the Project Manager must agree that the work and product creation is satisfactory. This may trigger a new Work Package, or preparation for an End Stage Assessment.

11 PROCESS Closing a Project (CP) The purpose of this process is to execute a controlled shutdown to the project. One of the defining features of a project is that it is finite -- in that it has a start and an end. If the project loses this distinctiveness, it loses some of its effectiveness of a purely operational management approaches. This process may be used for either a "natural" close or a premature close should it ever be necessary. Closing a Project is triggered during the last stage after all specialist products have been created. It should not be used in a final stage solely for the purpose of closing the project. The main activities and management products created during this process are: 1. Customer acceptance against the acceptance criteria 2. Confirm that the maintenance and operation arrangements are in place including any relevant training, and configuration management arrangements. 3. Make any arrangements for future work (Follow-On Action Recommendations), such as pending status issues, operational risks, and any other unfinished business 4. Create a Lessons Learned report from the Lessons Learned Log (what we did well, what could be improved, and any recommendations for the future). 5. Produce a Post Project Review Plan (how the benefits will be tracked measured and realised, including key milestone dates). The project only has to create the plan, not manage it. 6. Prepare an end project report which is based against the original signed off PID. 7. Advise all those who loaned resources to the project, that the project is about to close, and prepare a recommendation to the project board of the intention to close the project.

12 PROCESS Planning (PL) This process is used whenever a plan is needed, that is, to create a: Project Plan Stage Plan Team Plan (optional) Exception Plan (if needed) Each plan will include products, activities and resources, along with appropriate controls. Having designed the plan, the first step is to define and analyse the products using the Product-Based Planning Technique. This technique consists of four steps: 1. Create a product description for the end product 2. Create a product breakdown structure (a hierarchical diagram) 3. Create product descriptions for the main lower level products 4. Create a product flow diagram (shows the sequence of creation of the products) Next, the activities and their dependencies are determined and estimated. These activities are now scheduled, which includes normal project management planning activities such as PERT, Gantt, CPA, Resource levelling, etc. The risks are analysed and any countermeasures included within the plan. Finally the supporting narrative is added, and the plan document is complete.

13 COMPONENT The Components (HOW) The 8 components may be considered as "approaches", and are referenced and applied as if needed when carrying out each process. Business Case The business Case set out why the project is needed. It evolves from the reasons given in the mandate, and the fully formed business Case is contained within the PID. The business case is used as the driving force behind the project. If a satisfactory business case does not exist, then the project should not be started. From then on, it should be checked to see that a viable business case exists on a continual basis throughout the project. As a minimum, the business case should be updated and reviewed at the end of each stage. The business case contains: - the reasons why the project outcome is needed - options that have been considered to deliver that outcome - the benefits expected - clearly defined in measurable terms - a summary of the key risks - key cost and timescale data extracted from the project plan - an investment appraisal and its evaluation. The benefits in the Business Case are used as a reference when Closing a Project, to create the Post Project Review Plan.

14 COMPONENT Organisation Part One The PRINCE2 project management structure is based on a customer/supplier environment. The organisation structure includes the project management team and any optional roles. PRINCE2 does not define how many people should be involved in the project, rather, it sets out a number of roles that maybe filled by one or more people, or a single person may hold more than one role. Each role should define the levels of authority required, and may also include the relevant knowledge, skills, experience, and commitment/availability to fill the role. For larger projects it may be helpful to agree a formal job description. The main roles are Corporate (who issue the Mandate and set project-level Tolerance), and the project management team. The Project Management Team consists of: The Project Board they are responsible for ensuring that the project remains on track to deliver products of the required quality, and that the business case remains viable. The Project Board Executive role owns the business case and is ultimately responsible for the success or otherwise of the project. The Executive represents the business viewpoint of the project, and is responsible for business assurance. The two other project board roles are the Senior User and Senior Supplier. The project board executive will take notice of the other two roles advice, but always has the authority to take the final decision.

15 COMPONENT Organisation Part Two The Senior User role represents those who will either use the final product, achieve an objective for them, used the end result to deliver benefits, or they will be impacted (hopefully in a positive way!), by the project outcome. This role is also responsible for User Assurance. The Senior Supplier role needs to achieve the results required by the Senior User, and represents the interests of those designing, developing, facilitating, procuring and implementing. To do this the senior supplier is accountable for the quality of products delivered by the suppliers and that supplier resources of all types (this includes provision of the specialist team), are appropriate. This role is also responsible for Supplier Assurance. The project board as a whole is responsible for Project Assurance in the form of Business, User, and Supplier Assurances as stated above. Each role may decide to carry out their own assurance responsibilities, or optionally may decide to delegate it. The project board members are usually part time and drawn from the existing management structure within the organisation. It is recommended that project board members should remain with the project until its close whenever possible.

16 COMPONENT Organisation Part Three The Project Manager The project manager is responsible for day-to-day management within each stage within the constraints laid down by the project board, such as tolerance. The project manager is responsible for the creation of the PID, which includes the project plan, giving regular highlight reports to the project board, authorising work packages to the specialist team, ensuring that product creation is on track and that the products are of sufficient quality, and that the work packages are completed satisfactorily. The project manager is also responsible for most of the work during the managing stage boundaries process. This includes creating the next stage or exception plans, and updating the relevant documentation at each stage end. There are several optional roles which may be filled - however, if no one is available then the project manager must perform these roles them self. They are: Project support, configuration management, and team managers. The project manager may decide to issue work packages and receive work package status reports (Checkpoint Reports), directly to the specialist team themselves. However, there are situations where the optional team manager role may be required. For example, if the team size is too large, the specialist nature of the products are unfamiliar to the project manager, where the team lives over a large geographical area, or where a third party organisation is involved in the creation of the products, and they wish to use their project manager to act as a team manager within the project.

17 COMPONENT Controls Part One The purpose of project controls is to ensure that the Business Case remains viable, that the specialist products are meeting their quality criteria, and that the project is on schedule and meeting its results and cost plans. Controls are built into the project to ensure that progress is monitored, compare achievement against plans, detect problems early and react, and that those plans are regularly reviewed and updated. There are 26 different controls within PRINCE2, most of these are event-driven apart from two, the highlight reports and checkpoint reports - these are time-driven (produced on a regular timed basis). The event driven controls are used when a particular event occurs - such as the end of a stage triggers an end stage assessment. The controls are split into two sections - the controls used by the project board, and those used by the project manager. Of particular interest is the use of Tolerance. Tolerance is the permissible deviation from a plan without bringing that deviation to the attention of the next higher authority. Tolerance is built into a plan to allow for small problems and estimating errors (plus and minus), and should not be confused with a contingency budget (there to cover contingency actions should the linked risk occur), and a change budget which is there to pay for any changes.

18 COMPONENT Controls Part Two Tolerance forms a vital part of management by exception, and can exist at three levels: Project level tolerance. Only corporate management (who created the Project Mandate), have the authority to set project-level tolerances. The Project Board has the authority to set stage-level tolerances, and optionally, the project manager may set tolerances at the work package level. It may be more helpful to consider grouping the controls in the general sequence that they would normally be used: At the start of a project. This will include the Starting Up a Project and Initiating a Project processes, project-level tolerance, the project initiation document, the selection of stages to be used, and the two project board review points: Authorising Initiation the Project Board check that it is sensible to invest in a PID and Authorising a Project the Project Board check that the project is viable and worth doing. The PID encourages the Project Board to take ownership of the project - the PID is also used as a baseline reference showing the project s original intentions.

19 COMPONENT Controls Part Three During The Stages This is where most of the controls occur, and I will just list them here: 1. Creation of Stage or Exception plans, the end Stage Report, definition and authorisation of Work Packages, and their Product descriptions and quality criteria, approval at each End Stage Assessment or Exception Assessment 2. Setting of stage tolerance, quality control during the stage, project issues and change control, risk analysis and risk management, checkpoint and highlight reports, and the daily log. Closing a Project These controls include: 1. Customer Acceptance 2. The End Project Report (a review of the project against the initial PID) 3. Follow-on Action Recommendations (any unfinished business) 4. The Lessons Learned Report (drawn from the Lessons Learned Log) 5. Operational and Maintenance Acceptance (confirming the end product can be operated/supported) 6. The Post-Project Review Plan (how and when the benefits are measured and tracked, the resources needed to do this, and key dates leading to the Post Project Review itself where the previous project board executive determines that the benefits in the business case have been realised).

20 COMPONENT Management of Risk Part One Risk can be defined as uncertainty of outcome, but perhaps a more helpful definition would be a risk is something which has yet to happen, it may or may not happen, but if it does it will have an impact in some way on the project or business case The project board has four risk responsibilities: 1. Keeping the project manager informed of any external risk exposure to the project 2. Agreeing or otherwise to the project managers planned risk actions 3. Ensuring that there is a balance between the level of risk and the business case benefits 4. Keeping corporate and other senior stakeholders of any risks that may affect their objectives. 5. The project manager is responsible for ensuring that risks are identified, recorded and regularly reviewed. Each risk should be allocated an "owner" - defined as the person best situated to keep an eye on it. The project board and project manager may themselves own particular risks. All risks and their details are entered on to the Risk Log. This is kept updated throughout the project. New risks may arise, and existing risks may change - for example become more or less likely, their impacts may increase, the increase, or change. As a result of those, new actions or countermeasures may need to be planned.

21 COMPONENT Management of Risk Part Two The management of risk is split into two main steps: 1. Risk Analysis 2. Risk Management. Risk Analysis has four steps: Risk identification Usually captured at planning or risk workshops - although they may be identified at any time during the project Each risk should be categorised under one or more of seven categories: 1. strategic/commercial 2. economic/financial/market 3. legal and regulatory 4. organisational/management/human factors, 5. political, environmental 6. technical/operational/infrastructure. Risk Evaluation This consists of determining the probability of each risk, and its impact. In fact should be considered under the following headings: Time, cost, quality, scope, benefit, and people/resources.

22 COMPONENT Management of Risk Part Three Identify suitable Responses to Risk All responses should be built into the appropriate plan. There are five main action types that may be used singularly or in combination: Prevention. Countermeasures are put in place to reduce the probability to zero and/or reduce the impact to zero. Reduction. Actions are taken to reduce the probability and/or reduce the impact Transference. The risk in total in his passed to a third party usually in the form of a contract penalty clause, or an insurance policy. Be clear that the risk, if it occurred must have no impact on the project. For this reason, not all risks can be transferred. Acceptance. It is agreed that if the risk occurs, the impact to the project can be tolerated. This action may be chosen because any such actions would have an impact, such as cost, that is out of proportion to the risk impact itself. Contingency. This is different to all of the above. Actions are determined for the risk only if and when it occurs. Such actions must also be built into the plan, and in some cases a contingency fund is set up, separate and distinct from the main project budget. The final step of Risk Analysis is: Select. The above actions should be considered and those chosen should be done so by balancing the cost of such action against the probability and impact of the risk occurring.

23 COMPONENT Management of Risk Part Four Risk management. This consists of plan and resource, and, monitor and report. Plan and resource is taking the selected responses above, and including the activities and resources needed to carry them out. Once the plan is signed off, then monitoring and reporting can take place. This will normally consists of checking that the actions are having the desired effect watching for warning signs and trends, and ensuring that the overall management of risk is effective. The Management of Risk is an ongoing and iterative activity throughout the project and its stages. The total risk situation should be checked at key points - particularly at those times when the project board needs to authorise a Next Stage Plan or Exception Plan. The risk situation should be included in the regular highlight report. Also the risk situation should be checked when: 1. Planning, authorising and accepting Work Packages 2. Examining project issues, as part of management by exception 3. When closing the project.

24 COMPONENT Quality in a Project Environment Part One Within projects, quality is a question of identifying what it is about the project's products or a service that makes them fit for their purpose of satisfying stated needs. Projects must not rely on implied needs. It is important to ensure that both sides of the customer and supplier environment are actively involved in ensuring project quality. In particular, the use of project assurance, who must be independent of the project manager, and "reassure" the key business, user, and supplier interests that the project is being run in an appropriate manner. Also, project assurance should have heavy involvement in the planning and the use of appropriate resources during quality checking off the specialist products. PRINCE2 has created an easy-to-follow "Path to Quality", that lays out in sequence the key points within the project when quality should be checked. Here is the sequence: 1. The customers quality expectations are gathered 2. These are prioritised into measurable acceptance criteria 3. The Project Approach (how the work of the project is to be approached), is created, based upon the Acceptance Criteria. The project approach is a pre-requisite to planning.

25 COMPONENT Quality in a Project Environment Part Two The Project Quality Plan is created How quality is to be achieved, and this should include responsibilities for quality and any special standards that will need to be met. The blank Quality Log is set up. The Quality Log will be used to capture the planned, and eventually actual, dates, of all specialist products quality checking. As such it may be seen as a progress tool. During the creation of all plans, and using the Product-Based Planning Technique, product descriptions are written in close consultation with the users, and quality criteria agreed for each product. Each stage plan should include its own Stage Quality Plan. The Stage Quality Plan ensures that the timing, method, and resources needed for all quality checking identified and included. At this point, the Quality Log will have the planned date for all quality checking within the stage added. Once the specialist team has agreed to execute the Work Package, then work commences on the creation of the specialist products. When each product has been created, it is submitted to the agreed Quality Check laid out in the Product Description. Once passed, the product is approved and usually given to the Configuration Librarian. The Quality Log should be updated with actual dates of the Quality Check.

26 COMPONENT Configuration Management Part One Within the context of a project, Configuration Management can be considered as version control. Configuration Management is used to manage assets of a project - which are the products created by the project. All specialist products must come under the control of Configuration Management, but so too should the management products - with the exception of the various Logs. The name for the combined set of these assets is a configuration, and the configuration of the end product is the sum total of all its products. Configuration Management should be a permanent part of an organisation, since once the project has finished, the end product needs to be managed throughout its life. The job of Configuration Management is to identify, track and protect the project products. The project manager is responsible for Configuration Management, and as above, will normally liaise with the Configuration Librarian to ensure that Configuration Management is carried out. Configuration Management and Change Control must work very closely together, and it is usually the Configuration Librarian that maintains the Issue Log on behalf of the project manager. The Configuration Management Plan is included as part of the Project Quality Plan and it is a strategy of how Configuration Management should be used for the project and its products. This Plan should include how and where the products are stored, what filing and retrieval security there will be, how products and their versions will be identified, and where responsibilities for Configuration Management lie. Configuration management consists of five basic functions: Planning and identifying what level of configuration management will be needed by the project, and specifying/identifying all components of the final product. Control. This is the ability to agree and baseline products, and then only to make changes after agreement by the appropriate authority (normally the project board).

27 COMPONENT Configuration Management Part Two In order to exercise sufficient control, there must be close liaison between the Configuration Librarian and those creating the products, so that as the status of a product changes, its state is kept under control. When a management product is authorised by the Project Board, it is "baselined", and therefore moves from draft status to approved status. This changes its status and "freezes" the content - so that it can now be used as a firm basis for the development of any later product, only to be changed under formal change control. Most importantly, this process also applies to specialist products. When a specialist product passes its quality check, it moves from the draft to approved status. Where appropriate, the Configuration Librarian holds master copies of products. The Configuration Librarian also controls the issue of copies of a product, for example a document, so that it can be referenced and used. Where a copy of a product is needed for modification, for example an issue such as a request for change, the Librarian will issue the copy and ensure it is still under control. Status accounting. The configuration librarian maintains full records of the status of all products and a full history concerning each. Verification. The configuration librarian provides a service of reviews and audits to ensure that the actual status of products match is their status held within configurations management records. Such audits are particularly useful when preparing for an end stage assessment and when closing a project - but they may be requested at any time.

28 COMPONENT Change Control Part One PRINCE2 covers change control within three areas: 1. The Change Control Component (this one) 2. The Change Control Technique 3. The management of Project Issues during the Controlling a Stage process. The last two are dealt with in other sections of these Summaries. Within PRINCE2, all changes are treated as a type of project issue. Two important guidelines are stated: 1. If a product is to be changed, its product description should also be checked to see if it too, needs to be changed 2. Once a plan has been approved by the Project Board, any products referenced within the plan must not be changed without the approval of the project board. A project issue can be a general issue - which could be for example, at advice of a new risk, a general query, an observation or concern, or even a good idea. Such issues only use the Issue Log when a formal decision is needed.

29 COMPONENT Change Control Part Two Apart from general issues, there are two remaining categories: A Request For Change (RFC). This type will cause a change to the existing acceptance criteria, functional specification, or scope in some way. An RFC is raised from the customer side, and if any additional costs are incurred by the request, then the customer would normally pay for these costs. An Off-Specification. This type covers errors or omissions than in work already carried out, or planned for the future - and will result in the project not being able to meet the existing acceptance criteria, functional specification, or scope. Additional costs to fix this problem will normally be borne by the supplier. If the project board agrees to accept an Off-Specification without the need for corrective action, then this is called a Concession. The project board may decide to delegate their authority on decisions for project issues, to a person or group that carried this out for them they are called a "Change Authority". In addition the project board may agree to a separate Change Budget been set up to pay for any agreed changes. This has the added advantage of stopping tolerance being used to pay for changes. Project Issues should not be considered in isolation, but should be balanced against Business Case benefits, the risk situation, and any possible extra cost all-time being incurred.

30 COMPONENT Plans Component The Plan Component makes the point that a plan is a document - not, for example, just a scheduled diagram (Gantt Chart, etc,). The benefits of creating a plan are many, and include the products, activities and resources needed to achieve the targets within an agreed timeframe, agreeing assumptions, constraints, risk countermeasures, dependencies between products and activities, and the points at which progress will be monitored and controlled. There are three levels of plans that may be used: 1. The Project Plan 2. Stage Plans 3. Team Plans (optional). Should it be necessary, an Exception Plan may be created, which if approved, would replace the existing plan that will no longer finish within tolerance. The Exception Plan is not a different level. Apart from Team Plans, the Project Board approve all plans and in doing so, authorise the time and resources contained within them. The project board uses the Project Plan as their base reference, while the project manager uses the Stage Plan to monitor, manage, and control each stage. Plans also have an important function of proving that targets can be met, identifying the resources needed, and assisting in many communication aspects of the project.

31 TECHNIQUES PRINCE2 includes just three techniques, and makes no attempt to describe any other business or project management techniques - such as critical Path analysis, earned Value analysis, the creation of control techniques such as Gantt and PERT and financial techniques such as investment appraisal. Project Based Planning Technique PART One This is the most important technique, and must be used first to identify the products of a plan, before activities and resources are considered. A product is anything that the project must produce in some way and is described by the use of a simple noun or outcome. For example, Help Desk, New Help Desk, or possible Refurbished Help Desk. Compare and contrast this to a task, which is described by the use of a noun and verb. For example, create report, write the report, test the software, etc. As described earlier, the technique consists of four steps: 1. Create a product description for the end product 2. Create a product breakdown structure (a hierarchical diagram) 3. Create product descriptions for the main lower level products 4. Create a product flow diagram (shows the sequence of creation of the products)

32 TECHNIQUES Product-Based Planning Technique Part Two The Product Breakdown Structure. This is a hierarchical diagram showing all the products that must be created within the scope of a plan. Remember, this diagram does not show sequence - only a "family tree" type of diagram. When creating the project plan, the product breakdown structure would only include top-level products. When producing a product breakdown structure at stage plan level, these products would be broken down into lower levels.

33 TECHNIQUES Product-Based Planning Technique Part Two At the top of the product breakdown structure diagram is the end product, and this is broken down into lower levels. Products at the lowest level are called simple products because they cannot, or do not need, to be broken down into more detail. The standard shape is a rectangle. Products in the "middle" of the diagram are called intermediate products. There are two main types: Intermediate Collective. This type is just a convenient way of grouping products that have a common theme such as hardware, software, food, drink, documentation, etc. To help identify and intermediate collective product, it is suggested that a different shape is used - that of a rhomboid. These are not real products, but merely a device to help remind the planner of what the real products are, and these are drawn as sub products under the collective rhomboid.

34 TECHNIQUES Product-Based Planning Technique Part Three Intermediate Integration. This product shape is drawn as a standard rectangle. However, the sub products below it must be assembled, tested, integrated, and prepared in some way to create the intermediate integration product itself. Examples are, a hardware product assembled from its sub products, a document that uses various sources of information that are included within the document, or a named food dish that uses the ingredient subproducts below it. Another type of product is an external product, and an ellipse should be used as its shape. An external product is one that already exists, but the project needs it in order to achieve the project objectives. Another example is where the product is to be supplied from sources outside of the scope of the project. This does not include when the work package is given to third parties - as these products are still under the control of the project and progress information is obtained from such teams.

35 TECHNIQUES Product-Based Planning Technique Part Four Product Descriptions Product descriptions should be written as soon as the need for the product has been identified. It is a good idea to involve the users or customer involved in the creation of product descriptions, particularly defining the quality criteria, and how the product may be checked against these criteria. The suppliers must also be involved to ensure that the product description is realistic and achievable. The product description contains key information including: 1. The purpose 2. Composition of the product 3. How the product is to appear and be presented 4. The quality criteria that the product must meet 5. The people or skills needed both to create the product and carry out the quality checking. Some product descriptions can be created when producing the project plan in the initiation stage, while others may not be completed, or even identified until planning of a future stage.

36 TECHNIQUES Product-Based Planning Technique Part Five Product Flow Diagram. This shows the sequence of creation of all of the products identified in the product breakdown structure diagram, where the final product in the sequence will be the end product. However, the integration collective rhomboids have no value at in this diagram at as they were not real products and only used in the product breakdown structure to help identify the real sub-products beneath. Because the product flow diagram shows the sequence, then each product shape will have at least one arrow going into it - and at least one coming out of it. This diagram has the added advantage of helping the planner to identify dependencies between one product and another and any opportunities to develop some products in parallel.

37 TECHNIQUES Change Control Technique Part One This technique demonstrates how each project issue should be processed. The Project Board is responsible for the Change Control procedure. However, it is the Project Manager, with possible help from project support and Configuration Management, is responsible for applying this technique within the Controlling a Stage process. Anybody with an interest in the project may raise an issue at any time, and this is when the change control technique is used. When an issue is raised, it should be entered into the issue log, categorised according to the type of issue, and a copy sent to the author to advise its receipt and entry into the issue log. An Impact Analysis of the issue is now carried out, and should include: 1. What would have had to change 2. What effort the change would need 3. What is the impact on plans would be (including if the issue would cause Tolerance to be exceeded), 4. What the impact would be on the business case and risks. If the issue is an off-specification, then the project manager may try to resolve the issue within tolerance if this is possible. But for requests for change, the project manager must always bring this to the attention of the project board since it is they who have the authority to agree or otherwise.

38 TECHNIQUES Change Control Technique Part Two The Issue Log should be constantly updated to show the reader the current status and progress of the particular issue. Issues can cause existing risks to change or create new risks. For this reason, the Risk Log should always be inspected when examining an issue. The author of an issue should include their opinion of the Priority of the issue, for example must-have or cosmetic only. After Impact Analysis has been carried out, the Project Manager or the Project Board, should re-evaluate the Priority rating. Should any issue cause a forecast of tolerance to be exceeded, then the project manager must follow the management by exception process, and raise an Exception Report for consideration by the project board. If the issue were to cause project tolerance to be exceeded, then the exception report must be passed upwards to Corporate Management. When considering changes, the project board has the authority to implement the change, reject the change, and place it in "pending" for possible implementation later or if possible, to remove the cause.

39 TECHNIQUES Quality Review Technique Part One When product descriptions are created and the quality criteria determined for the product, a suitable method must be chosen to carry out the quality check. Where the product quality criteria can be checked by a test or instrument that clearly demonstrates that the product has either passed or failed, then the method used to carry out that check can be by any sensible and appropriate method. But where the quality check outcome may be more subjective - such as ease of use, a document's readability, etc, then the formal quality review technique should be applied. The objective here is to check the product itself against the quality criteria, and identify any errors, defects, observations or questions. There are four roles involved in the (formal) Quality Review: 1. The review chairperson 2. The producer or creator of the product 3. The reviewer or reviewers 4. The scribe who is there to take the minutes.

40 TECHNIQUES Quality Review Technique Part Two The Quality Review Technique consists of three basic steps: 1. Preparation. The product is reviewed against its quality criteria, and a question or error list created by the reviewers. 2. Review meeting. The review meeting is conducted under control of the review chairperson, and continues until an agreed outcome is arrived at: 1. The product has passed its quality review, and can be signed off 2. The products as errors and needs some form of rework 3. The reviewers cannot agree on the outcome of the meeting. This would likely result in the action to raise this as an issue once the meeting has finished. 3. Follow-up. If the product has passed its review then the quality log should be updated to reflect this, and arrangements made to store or protect the product. It is often given to the Configuration Librarian for this purpose, and also to allow for consideration records to be updated. If the product did not pass, then the follow-up actions will need to be carried out. The project manager will normally be immediately informed, and extra activities and resources added to relevant work packages and plans. If such rework were to cause tolerance to be exceeded, then an exception report must be created and sent to the project board for their action.

41 APPENDICES Appendices Part One The PRINCE2 Manual has 5 appendices: Appendix A. This contains 36 Product Description Outlines. These are templates for all of the management products, and are presented in alphabetical sequence. For example the project plan, project initiation document, and risk logs can then be found here. However, it also includes a single product description template for creation of the specialist products. Appendix B. Project Management Team Roles. These contain the responsibilities and tasks for each member of the project management team. They may be used to generate job descriptions for the individuals that hold these roles. Appendix C. These are the seven Risk Categories including many examples that were mentioned previously in the management of risk component. Appendix D. PRINCE2 Healthcheck. These have been designed so that an organisation can check on its correct and appropriate use of PRINCE2. It is in the form of sets of questions under several general headings such as organisation, business case, and risk. Appendix E. Project Document Management. Should an organisation need it, PRINCE2 has a suggested document management structure hierarchy that can be used by project to hold the various management documents.