1. Background and business case

Transcription

1 1. Background and business case This section explains the context and why the project is being undertaken. It provides the justification for investing the time and resources in the project. 1.1 Reasons Outline the reasons why the project is being undertaken. The focus should be on the need, problem or opportunity that the project is addressing from the perspective of the key project customers or audience and the British Council. If the project is being delivered under a contract then you should find this information in the project bid or design document. 1.2 Objectives and outcomes List each of the outcomes the project is intended to achieve. An outcome is essentially a statement of what will change as a result of the project. The critical thing about writing outcome statements is to avoid the temptation to hide behind abstract nouns. Outcome statements which focus on what people will be doing or thinking at the end of an intervention are easier to understand and therefore easier to measure and evaluate. For example, mangers and volunteers in partner organisations are able to manage human and financial resources effectively is easier to understand than institutional strengthening and increased capacity within partner organisations. Use the outcome statements presented in the project bid/design document. If these have been amended during the inception phase, then insert the final statements. 2. Project products This section explains what the project will deliver and what will not be covered by the project 2.1 Product descriptions Briefly outline each product that will be delivered during the course of the project. Set out the standards (acceptance criteria or quality requirements) that the products must reach for them to be approved by the project stakeholders. These stakeholders are likely to include the users of the product (also known as the audience, customers or beneficiaries) and the client who is funding the project. For each product, attach a detailed product description template. This provides details of the products composition any technical specifications and quality requirements which will guide the project team to design and deliver the product according to requirements.

2 2.2 Exclusions Use this section to make clear anything that will be outside the scope of the project and will not be included as part of the project. 3. Activity plan This section explains how and when the products will be delivered. A work breakdown structure (not related to SAP in this instance) can be a useful tool for setting out the work to be done to deliver each of the products. It can help you to decide what activities need to be done and the order in which they must be completed. By calculating how many working days are needed to complete each activity in the work breakdown structure you can see how much resource you will need. You can then schedule the activities throughout the project according to available resources. A work breakdown structure can also map directly onto the project task analysis which informs the project resource plan. Use a combination of your work breakdown structure and resource plan to prepare a detailed project schedule or Gantt chart. You may want to summarise the critical milestones under this section as a high level Gantt chart. You should also produce a more detailed task by task schedule to cover the immediate planning period, which is likely to cover the next three to six months and attach this as an annexe. This more detailed document will be your principle activity planning document and will change throughout the project as more information about the project and the operating context becomes available and circumstances change. 4. Costs This section explains how much the project will cost to deliver. If you are delivering your project under a contract you will find this information in the bid/design document. 5. Assumptions and dependencies This section explains any assumptions that have been made during the planning process and any dependencies on other projects which may affect the successful delivery of the project. 5.1 Assumptions and constraints Explain any assumptions you have made that might affect the project and any known constraints. You might find it helpful to refer to costs, timescales, quality or the appetite for

3 risk. Alternatively, it might be helpful to think about the political, economic, social, technical, environmental or legal context. 5.2 Dependencies Explain any dependencies that exist between this project and any other project or team and what you will do to manage those dependencies. 6. Project team and project governance This section explains who does what within the project, how they interact with each other and how decisions are made. 6.1 Roles and responsibilities Set out the roles and responsibilities of the key individuals who are involved in delivering, managing and controlling the project. Identify any specific skills, knowledge or experience that individuals must have. You should include the name of the internal project sponsor, who is the ultimate internal decision-maker for the project and all other board members. You should also include the name of the project manager and any other key personnel in the project team. Remember that the project team may include partners, suppliers and external consultants as well as British Council staff. A RACI matrix can be a useful tool for setting out the different responsibilities that these individuals or groups have at different stages of the project cycle. Name Role Organisation Key responsibilities Skills, knowledge and experience required 6.2 Governance and controls Use this section to explain the reporting relationship between the individuals and groups involved in managing and controlling the project. An organogram is a useful way of setting this out.

4 Use this section to outline the following: the project governance structure (e.g. Project Board or Steering Group) when these groups will be convened and how decisions will be made (i.e. the key elements of the terms of reference) the thresholds and process for escalating any risks, issues or changes to the project from the project manager to the Project Board) the process for approving products the process for handing over products to users or other stakeholders reporting requirements for the project any internal or external compliance audits, corporate or programme management reviews 7. Risk management This section explains the approach you will take to managing risks and the appetite for risk. 7.1 Risk strategy A risk is an uncertain event that if it were to occur would have an impact on the achievement of the project objectives. A risk might be negative, in which case it is described as a threat or positive, in which case it is described as an opportunity. Under this heading outline the following: roles and responsibilities for managing and reporting risks and opportunities the risk management procedure that you will follow including the frequency or timing of formal risk management review activities scales for estimating the probability and impact of risks risk tolerance how serious does a risk have to be before it is escalated? governance structure to whom risks will be escalated. Typically this will be the project board. In cases where a project board does not exist, then risks should be escalated to the project sponsor. If the project is complex you may find it helpful to attach your risk management strategy as a separate document, rather than trying to summarise it here.

5 7.2 Major threats and opportunities Under this heading outline any significant risks that may arise during the project. You may find it easier to attach a copy of your risk register. 8. Stakeholder management This section describes who your stakeholders are and how you intend to communicate with them. If you are managing a complex project you may prefer to set this out in a separate stakeholder management strategy. 8.1 Stakeholder analysis Identify each of the key stakeholders with whom the project should be communicating throughout the project. A power:interest grid is a useful tool for analysing your stakeholders and helping to prioritise them. Think about and explore what aspects of the project are of most interest to them and how they would like you to communicate with them. 8.2 Key messages Set out the key messages that you want to convey to your stakeholders. 8.2 Communications plan Set out how you intend to communicate with your stakeholders, the communications channels you will use, how often you will communicate with them and what they want from you and what you want from them. 9. Information management This section describes how you will ensure any information collected or generated by the project is handled in line with UK legislation, how you will share information appropriately and how you will retain and ultimately destroy information in line with client or British Council requirements. 9.1 Records, file management and archives Outline any naming conventions for documents and products generated throughout the project including the need for any protective markings and any system of version control. Agree a file structure for any shared folders so it is easy for others to access the information even after the project has closed. The contract will usually say how long documents produced during the project should be kept and may also have requirements for how information, particularly personal

6 information may be stored and used. In the absence of specific guidance, refer to the department or region s retention schedule. 9.2 Knowledge sharing Use this section to explain how you will capture, transfer and share the knowledge accumulated during the project. Describe how you will mitigate the risk of key personnel leaving the team, taking their knowledge with them. Attach your lessons log as an annexe. 9.3 Compliance with intellectual property law Use this section to describe how you will mitigate the risk of infringing the intellectual property rights of others and how you will protect intellectual property generated by the British Council. 10. Monitoring and evaluation This section describes how, when and who will collect, analyse and report data that helps stakeholders determine whether or not the project outcomes have been achieved Project logic or logical framework Attach your project logic map or logical framework (if you have one) as an annexe to this document Monitoring and evaluation plan Complete the table below. Remember to include any monitoring and evaluation activities on your overall project Gantt chart. Indicator Means of data collection Data source Timing Responsibility