Project Printable Template Title and Description
Template Title and Description
Please find attached, links to PDF samples of the SKM Business Case and Project Status Report document templates. Click here
| TEMPLATE TITLE | TEMPLATE DESCRIPTION |
| Benefits Profile | Each benefit and dis-benefit associated with the programme/project needs to be defined in detail so that they can be monitored and progress tracked. This full description of the benefits should include details of the measures, ownership responsibilities, links and dependencies, costs associated with realization and measurement, and the period of time over which the benefit will be realized. |
| Blueprint | The purpose of this document is to create a model of the future organisation. This model includes the future organisation’s working practices and processes, the information it will require and the technology that will be needed to deliver the capability as described in the Vision Statement. |
| Budget Plan | The purpose of this Cost Management Plan is to describe the cost management processes required to ensure that the financial status of the project is clearly reported and controlled. This covers establishing budget amounts, tracking expenditures, developing forecasts, and reporting results. |
| Business Case – Template |
To identify what the project entails. |
| Business Requirements | A text description of area of business under discussion; the problem to be Addressed; the proposed Idea, and proposal objectives. |
| Change Control | Change control is an important aspect of the quality management process and key to ensuring the successful outcome of any programme/project.The purpose of this document is two-fold: • To identify the processes and procedures used to manage changes to the project’s scope or to previously approved deliverables. • To define how the project intends to identify, track, control and protect all its documents and deliverables through development, delivery and change.The Change Control Register is an important audit and management tool for the Programme/Project Manager. It provides details of each change control request – including a unique identifier, the description of the change request, the originator, classification of the request and approval status. |
| Closure Report | This can be taken from project documentation (e.g. Project Initiation Document); it must paint a vivid picture of where the project came from, when and why it started, and how it relates to business areas.The aim is to give readers a pen-picture of the project remembering that some (for example, senior managers) may not know the specific business or operational context. |
| Communications Plan | This Communication Plan outlines the key stakeholders for the Project and their communications requirements. The plan outlines: • The communication roles of key stakeholders and team members in the project • Who needs project information • Why the information is needed • The means that will be used to generate, collect and distribute the information |
| Design Docs | Based on the requirements, potential solutions will be evaluated to deliver the project.The Design documents should take account not only of the construction / technology elements of the solution, but also process, tools, organisation and roles, so that a complete solution is proposed. |
| Exception Report | Full description of the Issue which is threatening the overall Project/Programme Including any relevant background; the available options and project manager recommendations. |
| Feasibility Report | The feasibility study will examine and document the potential approaches to the issues / challenges, as well as making a recommendation. The report may include a high level estimate on cost and complexity, as well as timescales. |
| Follow-on Actions | The purpose of this document is to pass details of unresolved issues, outstanding risks and potential product modifications to the group charged with future support of the final product in its operational life. |
| Handover Report | The purpose of the Handover Plan is to define: • Period of on-going project involvement post go-live • How the system / service will be defined as stable • How the project team will handover smoothly to the operational support team. |
| Highlight Report | Provides information about the: Progress to date; Key Issues and Changes; Risks; Plan for period and Tolerances |
| Lessons Learned | The purpose of this document is to pass on any lessons that can be usefully applied to other projects, with the hope that future projects may avoid the pitfalls that this project has experienced, learn from the successes and hence increase their chances of success. |
| Options & Approach | The purpose of this document is to identify the options for delivery to business objectives identified in the associated Business Requirement Definition (BRD), which defines the proposal. |
| PID | This PID defines the nature of project and fundamentally describes: • What the project intends to do • Why it’s going to do it • Who is responsible • How it will be achieved • When it will be delivered.This PID brings together a variety of information which justifies the project as: • being worthwhile (justifiable expenditure) • being well planned • being properly financed • having properly defined and measurable business benefits. |
| PIR Report | This document describes the resources required and steps to be taken to establish if the expected benefits of the project have been realised and whether the product(s) have caused any issues during operation.The PIR report should state whether the project outcomes meet the current needs of the business and whether systems or processes are ‘fit for purpose’. |
| Progress Report | Defines the rationale for the project and what outcomes are sought in terms of benefits and change; a description about the highlights from the previous week and justification for the overall status above; RAG status indicators. |
| Project Brief | The purpose of this document is to detail the Project’s formal terms of reference, ‘quality expectations’, ‘acceptance criteria’, initial risks and the outline business case.This information will be used to assess (at Start-Up) whether there is justification to invest time/effort/cost in more detailed planning and project initiation. |
| Project Mandate | The mandate identifies the person who initiated the request, the high level objectives and is intended to ensure there is visibility and approval to proceed with the ‘Start-Up’ stage investigation. |
| Project Plan | The baseline plan needs to articulate not only the tasks and deliverables (typically via a Gantt Chart), but also the resources, funding, commercial agreements required. |
| QA Plan | The purpose of this Quality Management Plan is to define the quality management procedures, systems and controls to be applied to the project. It also defines the particular roles and responsibilities of project staff relating to quality management. |
| RAIDs Log | The Risk and Issues Register provides a repository of information about risks and issues to aid risk management (i.e. risk identification, ownership, risk analysis, countermeasures in place and current status) and issue resolution. |
| Requirements Docs | To describe: the Business Objectives for a proposal; the Critical Success Factors (CSF’s), aligned to the parent Objectives; the Functional and Non-Functional requirements, aligned to CSF’s. |
| Resource Plan | The Project Manager needs to have assurance that the activities and deliverables within the plan can realistically be delivered in the stated timeframes.To that end, the required resources must be identified, assigned, and committed to the plan. |
| Risk Assessment | This risk assessment tool will determine and display whether each risk is high, medium or low automatically. |
| Risk Management | This Risk Management Strategy sets out risk management definitions, responsibilities and procedures (including a user guide for the Risks and Issues Register). The risk and issue management procedure should be followed for all risks and issues encountered during the project. |
| Stakeholder Map | The purpose of this document is to identify all the project stakeholders (both internal and external to the project team), the influence the project will have on them and their respective interest areas and influences. |
| Test Strategy | The purpose of this document is to ensure a common understanding between the Customer and the Project team on the plan to deliver a quality product. |
| Vision doc | The Vision Statement is produced to provide a clear statement of the ‘end goal’ of a Programme – supported by a description of the new or extended capability and the targeted performance measures or service levels that will result from the Programme. |
PDF SAMPLES
