Project Management Handbook

Transcription

1 Project Management Handbook Version 0.1 September

2 CONTENTS Introduction 3 The Project Lifecycle 3 Aspyre 4 Project or Programme 5 Project Management 6 Phase 1 Prepare 7 Project Brief 7 Business Case 7 Project Initiation Document 8 Phase 2 Plan 8 Project Plan 8 Risk Mnagement 9 Phase 3 Deliver 11 Tracking 11 Reporting 12 Risks and Issues 12 Lessons Learned 13 Phase 4 Close 14 End Project Report 14 Appendices 15 Appendix 1 Project Lifecycle Overview Appendix 2 Project Brief Appendix 3 Business Case Appendix 4 Project Initiation Document Appendix 5 End Project Report 2

3 Introduction Thank you for picking up this handbook it contains a systematic approach which forms the standard project management methodology to be adopted throughout the organisation. Our project management approach plays a key role in improving health outcomes for the residents of Lincolnshire by ensuring that our resources are appropriately used and that our activities are aligned to our strategy. How to use this handbook This handbook is split into the 4 main phases of the project lifecycle, with a requirement to provide assurance throughout. Within each of these sections templates are referenced that can be found in the appendixes and on Aspyre for use with your project teams. The four phases When considering the lifecycle of a programme or project there are four principle phases of activity to PREPARE, PLAN, DELIVER AND CLOSE, providing assurance throughout. CLOSE PREPARE ASSURE DELIVER PLAN Appendix 1 provides an overview of the requirements within each of the phases and throughout the lifetime of the project. 3

4 Programme and project management software To support the implementation of the project management activity phases outlined above, and to provide assurance around delivery to the Board, Lincolnshire Community Health Services has introduced a Programme and Project Management software application Aspyre. Aspyre is a web-based tool that supports the application of project management. If you do not currently have access to the system, please contact the Project Support Office for login details and training: pso@lpct.nhs.uk Look out for the half day ILM accredited project management workshops, where you will have the opportunity to learn how to put this handbook into practice and hone your project management skills they are for everyone, regardless of whether you are new to project management or just want to refresh your skills. Further information can be found on the Training section of the intranet. 4

5 PROJECT OR PROGRAMME? Programme and project management While this handbook concentrates on the successful planning and delivery of projects, it is important to note the difference between a programme and a project. What is a programme? A programme is defined as a group of projects related to each other through the sharing of a common goal. Programme management provides a framework that integrates and reconciles the competing demands for resources and provides a control framework for the projects that make up the programme. The emphasis is on managing the dependencies between projects and ensuring that they align to programme objectives and are set to deliver the overall programme benefits. A number of key programmes have been established within LCHS NHS Trust. Each of these areas has a committee/group to agree the projects that constitute the programme, and be responsible for monitoring the progress, and making decisions relating to the commissioning and decommissioning of projects. These committees/groups also provide a mechanism for formally reviewing and signing off the quality of project outputs along the programme lifecycle; Quality Improvement Committee Performance Management Committee Efficiency Group When undertaking the preparatory stage of your project, please check whether it fits with one of these programmes to check alignment with the overall objectives. If your project is part of a countywide or partner programme such as Excellence for All you will also need to check if the templates in this handbook are appropriate or if you need to adopt those specifically related to the shared programme. Your first port of call is to find the appropriate Programme Manager to make these checks. What is a project? A Project is a finite endeavour (having specific start and completion dates) undertaken to create a unique product or service which brings about beneficial change or added value. 5

6 How can project management help? Project management is the discipline of planning, organising and managing resources to bring about the successful completion of specific project goals and objectives. The challenge of project management is to achieve all of the project goals and objectives while honouring the project constraints. The main constraints are scope, time and budget. Following the systematic approach outlined in this handbook will ensure that your projects are well planned in the first place, tracked through the delivery phase and that outputs are reviewed prior to closure. 6

7 PHASE 1 - PREPARE Preparation is the first phase in the Project Life Cycle and essentially involves starting up the project. You prepare by defining the projects purpose and scope, the justification for initiating it and the solution to be implemented. There are three documents which can underpin a project; Project Brief Business Case Project Initiation Document All projects must have a completed Brief OR Business Case. More complex projects will additionally require completion of a Project Initiation Document. The level of documentation to be completed must be agreed by the Project Manager and Project Sponsor/Programme Board. 1. The Project Brief (Appendix 2) This is the least detailed of the documentation in the Planning phase. The Project Brief provides a description of what the project is to do and forms a contract between the Project Manager and corporate or programme management. The Project Brief needs to include high level information on what needs to be done, why, the benefits to be achieved, who will need to be involved in the process and how and when it will be done. 2. The Business Case (Appendix 3) The Business Case is more detailed than the Brief and additionally requires explicit information regarding aims/objectives, benefits, scope, assumptions, constraints, outcomes and dependencies. The two primary uses of the business case are: To ensure that the project has a sound basis for seeking approval. To provide a baseline document against which the Project Board and Project Manager can assess progress and on-going viability. It is the justification for the project, setting out the expected benefits, costs and resources required. This is the entrance to the project management process and subject to approval by the relevant Programme Board. 7

8 3. The Project Initiation Document (PID) (Appendix 4) The means by which the expectations of the business case are translated into a workable plan that has involvement from the stakeholders and can be tracked and reported against. The two primary purposes of a PID are to ensure the project is launched on a sound basis agreed by the project sponsors and stakeholders and to enable progress to be tracked against a plan. The sections need to be succinct and written in language understandable to non experts and stakeholders. If any of your stakeholders or team wishes to have an understanding of the project these are the documents to give them, as they contain the reason for the project, how it is to be delivered and what outcomes you are expecting. The project brief, business case and project initiation document form the framework around which a project plan can be built. At all stages beyond the initial planning stage the Brief, Business Case or PID need to be referred to when checking progress. PHASE 2 - PLAN After defining the project, you're ready to enter the detailed Project Planning phase. The Planning Phase involves completing the following documents to help guide the team throughout the project delivery: Project Plan Risk Register Project Plan One of the easiest ways of planning the project is to look at what final aim and outcome is required and break this into key events (milestones) and elements that have to be produced (deliverables). Drawing these up into a list then aids the reporting process. After considering the key events that need to happen and the deliverables or outputs it is possible to plan the timeline to achieve these and the more detailed activities that need to happen. The project plan is the tool for allocating owners to tasks, deciding on start and end dates and examining what dependencies there are between tasks. For example, 8

9 where a task cannot start before the completion of another. Project plans should be produced within Aspyre. Risk Register Considering the things that could negatively affect the success of the project is a key part of the planning stage, so that a proper assessment can be made of the likelihood of it happening and the impact on both the project and the wider organisation if it does. At its simplest level, risk management is about asking what can go wrong with this project? A risk is the chance of something happening that could affect the project Considering the things that could negatively affect the success of the project is a key part of the plannng stage, so that a proper assessment can be made of the likelihood of it happening and the impact on both the project and the wider organisation if it does. The assessment and management of risks is something that will go through the entire project lifecycle, particularly through the delivery stage. The object of risk management is to avoid or mitigate the effect of events that pose a threat to the project delivering its outcomes. There is a three stage approach to risk management; identification of risk assessment of the potential severity plan to deal with it The most effective way of keeping on top of risk is to build it in as part of other project review meetings so that it becomes part of your team s way of working. All risks should be logged on the Risk Log within Aspyre. IDENTIFY Consider the categories of risk that are applicable to your project, for example, reputational, financial, or patient safety. Risks can be identified by the project manager or any of the stakeholders involved in the project and a common source is 9

10 at project review or board meetings. Risk workshops at the start and during the lifecycle of a project are also a useful way of identifying and making an assessment of action required. Risks at a project level can become risks at a corporate level and before completing your own project risk register please familiarise yourself with the Risk Management Strategy and Policy on the Lincolnshire Community Health Services website to ensure you understand when a risk needs to be logged on the Corporate Risk Register. uments/policies/risk%20management/rm002a%20lchs%20risk%20management %20Strategy.pdf For further guidance on this please consult your local Risk Lead. ASSESS Consequence (Severity) When undertaking a risk assessment, the consequences of how bad the risk being assessed must be measured. In this context, consequence is defined as: the outcome of the potential outcome of an event. Clearly, there may be more than one consequence of a single event. For example catastrophic means death or debilitating permanent injury and minor means requiring first aid. Likelihood (Probability) Once a specific risk has been assessed and its consequence score agreed, the likelihood of that consequence occurring can be identified. When assessing the likelihood it is important to take into consideration the controls already in place. The likelihood score is a reflection of how likely it is that the adverse consequence described will occur. This must be estimated over a stated period (proximity). 10

11 PLAN After assessing the risk score priority ask the question what do we need to do to prevent this risk from happening, and if it is inevitable then what we can do to minimise the impact? These are known as mitigation and contingency respectively. Outline the resources and activities required and complete all sections of the Risk Log. PHASE 3 - DELIVER Tracking Progress This is the implementation stage of the project where it is crucial to track progress, check the quality of deliverables and report back to the Project or Programme Board and Stakeholders. One of the key tasks is a regular progress check against the list of deliverables and milestones. The Project Plan is the principle day to day tool to check completion of activities. For small projects a simple milestone report will suffice as a tracking tool, however on more complex projects or where there is a need to consolidate a number of projects into an overall programme plan, a Project Plan is preferred. Both of these should be produced from within Aspyre. 11

12 On at least a monthly basis it is recommended that a check be carried out against the list of deliverables and milestones in order to be able to issue a highlight report. Reporting The highlight report is an effective way of showing progress of the project to a project or programme board without having to go through unnecessary detail. It can be generated within Aspyre by checking back on the project plan/milestones and highlighting the main achievements in the last month, and what is expected to be delivered in the coming month. The RAG Status gives a quick overview of whether milestones are being met, the project is adequately resourced, and if issues or risks are a real threat to the project. If any of these are red or amber it is imperative that a brief summary of the situation is given in the Comments on RAG status box. The RAG rating descriptors are as follows, and are applied to individual elements and as an overall project: RED Project or element seriously compromised and likely to fail AMBER Project outputs or benefits at risk, or cost/timescale/ resource issues GREEN Project or element is on target to deliver what is required Risks and Issues As the project progresses, new risks and issues will occur that require consideration, as well as those identified at the outset. Issues may well be dealt with at a Project Manager level, escalating only when there are decisions that need to be considered at a Project or Programme Board level. Issues Log The risk and issues log are linked, as in some cases issues that arise link back to a risk that had been identified earlier, in which case the controls in place for the risk may need to be re-visited to understand how or why the issue still arose. Other issues can arise from unexpected and unforeseeable events. However the issue has arisen it needs to be assessed on the impact it has on the project, in the same way as a risk. Once a resolution has been settled upon it is important to enter any learning from the issue into the Lessons Learned Log. If there is a possibility of the same issue arising again then this will require an entry onto the project risk register. 12

13 An issue is something that has happened that affects the project Issues are those things that happen during a project that could derail progress, or affect outcomes, costs or resources. When these arrive they need to be assessed in terms of: 1. Description of the situation 2. Impact of not resolving the issue 3. Options for resolution The Issues log should be maintained within Aspyre. Lessons learned There are many lessons to be learned in every project, both positive and things that could have gone better. It is important for these to be recorded as the project progresses rather than leaving them until the end. This will then form valuable learning in the project closure report for sharing across the organisation. Evaluation and feedback from stakeholders, particularly on your communications with them, also provides useful learning to the organisation about what project approaches and messages are effective with particular audiences. Whenever there is an event that can be learnt from either internally or from a stakeholder then make an entry on Aspyre and share your learning with others. PHASE 4 - CLOSE Projects are by definition finite endeavours and at some point need to be closed down, whether the project has successfully completed or been brought to a premature close. The purpose may have been to instigate new action by that becomes Business as Usual or just to deliver a stand alone benefit for the organisation or the public. For projects that deliver activities that become business as usual it will be necessary to think ahead of project closure to make any transitional arrangements that will be necessary during the handover period from project to operational teams. The objectives of the Closing a Project process are: 13

14 To verify that there is user acceptance of the project s products; To ensure that the operational team is able to support the products when the project and the project team is disbanded; To review the performance of the project against its baselines; To assess any benefits that have already been realised, update the forecast for the remaining benefits and plan a review of those benefits at some point in the future; and To ensure that provision has been made to address all the open issues and risks, with follow-on actions or recommendations. Whatever the purpose of your project, a review and sign off of all deliverables is essential to be able to measure the achievements of the project and an End Project Report ensures that the outputs and outcomes are measured against the original expectations and that lessons learned are recorded for sharing across the organisation. Prior to writing an End Project Report the Project or Programme Board, Senior Responsible Owner and Project Manager must be satisfied that all key deliverables and milestones have been achieved. See Appendix 5 for the End Project Report Template. It is particularly important that where the benefits or outcomes of the project are to follow project closure, a mechanism must be in place to track and record them. A mechanism will have to be set up and confirmed with the Information Directorate to ensure that measures are feasible. 14

15 Appendices Appendix 1 Project Lifecycle Overview X:\ \LCHS\ Project Management\ Appendix 2 Project Brief X:\ \LCHS\ Project Management\ Appendix 3 Business Case X:\ \LCHS\ Project Management\ Appendix 4 Project Initiation Document X:\ \LCHS\ Project Management\ Appendix 5 End Project Report X:\ \LCHS\ Project Management\ 15