project management framework - borough of …€¦ · 1. introduction 1.1 purpose the purpose of...

Project Management Framework Edition: January 2010 – Version DRAFT 3 Created by: H. Baines Owner: G. Stoppani

CONTENTS

1. INTRODUCTION 4

Purpose 4 Target Audience 4 Glossary of Terms 4

2. THE BASICS 5

What is a Project? 5 Projects or Not? 5 Why Manage Projects Differently? 6 What is Project Management? 6 What is Programme Management? 6 Why Projects Fail 6

3. TYPES OF PROJECT 7

Scale of Project 7 Procurement 7 Financial Management 7

4. PROJECT ORGANISATION 8

Small Projects 8 Medium Projects 9 Large Projects 10

5. PROJECT LIFECYCLE 11

(1a) Starting Up 11 (1b) Initiating 13

(2) Running the Project 15 (3) Closing the Project 17

6. PROJECT DOCUMENTATION 19

APPENDICES 21

Scale of Project 22 Risk Responses 23 Glossary of Terms 24 Project Type Approvals 27 Key Project Documents 29

- Project Brief 30 - Project Approach 32 - Business Case 33 - Product Initiation Documentation (PID) 35 - Product Description 37

Acknowledgements 38

of 39

1. INTRODUCTION

1.1 Purpose The purpose of this document is to provide information and guidance on the Project Management Framework for the Borough Council of Wellingborough. 1.2 Target Audience Everyone who has a key role in projects should read and become familiar with the information and process guidance within the Framework. It has been written to assist anyone who is asked to control and manage projects within the Council, irrespective of their level of experience of project management and their departmental function. Project requirements will vary, but the project management approach and techniques should ideally remain the same. It will also be of value to those who have project responsibility in a management capacity. 1.3 Glossary of Terms There is a glossary of project management terms in Appendix 4, starting on page 25

of 39

2. THE BASICS

2.1 What is a Project? A project is a management environment that is created for the purpose of delivering one or more business products or services, according to a specified Business Case. There are a variety of other valid definitions; however, this definition highlights some important points:

in order for a project to be created, a Business Case must exist. The Business Case may be developed in advance of the project, or it may be developed as part of project start-up

a project is created to deliver something – one or more business products or services. Planning the project will involve defining exactly what should be done in order to deliver the products or services

a project is a management environment that is created specifically for the project – it is not normal operational business

projects are temporary things, each with a defined start, middle and end. Projects

do not happen, nor do they go on forever Taking examples of projects below, products can be tangible objects such as a new school building or wedding reception, or could be a new capability such as the development of a new service or way of working. 2.2 Projects or Not? Examples of projects:

organising a wedding re-organising a department an office move developing a strategic plan, such as

the 2020 Vision building a new swimming pool These are not projects:

× washing the car × paying employees × providing services to the elderly × managing a contract with a local

supplier × emptying the bins

of 39

2.3 Why Manage Projects Differently? Specific techniques and skills are required to manage a project and these are not all the same as those needed to manage a service. A Project Manager needs to be able to create and manage a temporary team, and be focussed on the delivery of specific outcomes within time, cost and quality constraints. If a project is not managed effectively and does not have sufficient resources then its chances of success are limited. At a strategic level, project management is about managing change and an organisation’s ability to manage change effectively is critical to its survival and future success. 2.4 What is Project Management? Project management is not just something which the Project Manager does. It is a combination of: the roles of individuals assigned to the project, the organisational structure and the processes that will deliver the required outcome. It ensures that everyone involved knows what is expected of them and helps to keep cost, time and risk under control. 2.5 What is Programme Management? Projects may be part of an overall programme of business change. A programme is a portfolio of projects and activities that are co-ordinated and managed as a unit in order to achieve outcomes and realise benefits. For example, an ICT Programme will contain a number of planned projects and/or activities to achieve a certain outcome or level of service. Where a project does not form part of a programme, it must still be designed to meet some stated business objectives. 2.6 Why Projects Fail The most common reason for a project to fail is the lack of internal resources dedicated to it at the outset. A well run project needs sufficient staff time to ensure it is properly managed and so the work can be completed on time. It is more cost effective to provide the right resources at the beginning rather than try to remedy a deficiency part way through a project. The start-up phase of a project (described later) is where its success or failure is often decided.

of 39

3. TYPES OF PROJECT

3.1 Scale of Project Every project will go through the same basic project management lifecycle, but the degree of control, documentation and organisation required depends on the size and complexity of the project. Also, different scales of project require different levels of project management competence. The Project Management Framework classifies projects into three types: small, medium and large. Included in the Appendixes at the end of this document is a table that enables the scale of a project to be determined. Reference to the scale of projects – small, medium and large – is made throughout this handbook and the other resources from the Project Management Framework. The approach is summarised in the following table:

Scale Approach Related training course Ref. to relevant training material (Learning Pool basic training course) – TBC

Focus on essential elements of project management Small project

Consider all elements of project management and use those that are relevant to the project

Reference to more advanced training available (next stage Learning Pool version) - TBC

Medium project

Comprehensive application of the PRINCE2 project management method

Large project PRINCE2 Practitioner

3.2 Procurement All projects that include the procurement of goods or services must comply with Standing Orders on Procurement and Contracts and the EU Procurement Directive. Advice can be obtained from the Procurement Officer who will support the project team through the procurement process if required. They will determine whether Legal Services should be included in the process. 3.3 Financial Management For all large projects a finance representative should be included within the project structure. The Project Board and Project Manager must have the skills and experience to be competent to manage and monitor the project budget. They must be aware of the financial reporting requirements for projects. Detailed requirements will vary from project to project. Some projects with relatively small budgets can have very complex financial arrangements, particularly if several services are involved, while projects with larger budgets may be more straightforward. For further advice about the financial management of projects, contact the Capital Accountant or your Service Accountant when starting up a new project.

of 39

4. PROJECT ORGANISATION

All projects require an organisational structure that clearly defines the roles and responsibilities of everyone involved. 1.4 Small Projects The minimum roles required for any project are:

Project Owner (also known as Executive): a single person responsible and accountable for ensuring the project remains focussed on achieving its objectives in order to meet the needs of the users, and that the anticipated benefits can be achieved.

Project Manager: responsible for delivering the project on behalf of the Owner. The Project Manager leads and manages the project team and has the authority and responsibility to run the project on a day-to-day basis. They may be a specialist Project Manager or may come from the business area.

Project Team: those people who are working on the delivery of the project’s products. On small projects, this would probably include the Project Manager.

Stakeholders: individuals or groups who have an interest in the project. As the project progresses and the focus of work changes then the stakeholders may also change.

Project Owner

Project Manager

Project Team

Stakeholders

of 39

1.5 Medium Projects A Project Board should be established for all medium projects. The Project Board is the decision-making authority for the project. The Project Board should represent three areas of interest:

Executive: taking ultimate responsibility and accountability for the successful completion of the project.

Senior User: representing the end users of the products from the project.

Senior Supplier: representing those designing, facilitating, building, procuring and implementing the project’s products.

The Project Manager should consider the need for project support resources to administer the project. Tasks would include: managing the project documentation, as well as production and maintenance of project plans.

PROJECT BOARD

Senior User Senior Supplier Executive

Project Team

Project Manager Project Support

Stakeholders

of 39

1.6 Large Projects On large projects, further roles may need to be identified and the project team may be broken down into separate teams, each being responsible for delivery of specific products or work packages. Quality Assurance needs to be an integral part of the project; the more complex the project, the greater the importance that a specific person or group is given the role of checking that the project is being carried out effectively.

Senior User Senior Supplier Executive

Project Team

Project Manager Project Support

Stakeholders

PROJECT BOARD

Quality Assurance

Project Team Project Team

of 39

5. PROJECT LIFECYCLE

All projects have three distinct phases, with the first phase consisting of two steps. (1a) Starting Up

(1) Preliminary (2) Running (3) Closing

(1a) Starting Up (1b) Initiating Project Planning and

controlling stages

Project Getting started definition closure and planning Project

evaluation Managing product delivery

Benefits delivery

Note: In small projects, starting up and initiating the project can be combined

The tasks described below need to be completed to establish whether the project is viable and worthwhile.

Project organisation: The Project Owner (or Executive) should establish an initial project organisation suited to the scale of the project – see section 3 above. Project Brief:

The Project Owner (or Executive) has overall responsibility for defining the project, but the Project Manager usually compiles the Project Brief on their behalf. The Project Brief provides the terms of reference for the project. See Appendix 5 for more detail regarding composition and derivation. Risk Log: The Project Owner (or Executive) is responsible for ensuring that risks are being tracked and mitigated, as identified by the Head of Partnerships and Policy within the Corporate Risk Strategy Document. The Project Manager is responsible for creating and maintaining the list of what could go wrong to the project (Risk Log) and ensuring that all the risks are owned and managed for the duration of the project. See Appendix 2 for more details on how to manage risk Project Approach: The Project Manager is responsible for defining the type of solution required and the preferred method of delivery. The input of specialists at this point will help ensure a robust approach is designed. In particular, procurement expertise should be involved as early as possible for projects that will use external suppliers of products or services. See Appendix 5 for more detail regarding composition and derivation.

of 39

Initial Business Case:

The Business Case explains the business rationale for undertaking the project, the expected benefits as a result, and analysis of the balance between costs, risks and benefits. At this early stage, the Business Case information may only be outline but it should clearly explain how the project fits to overall organisational objectives. Although the Project Owner (or Executive) has overall responsibility for the Business Case, the Project Manager usually obtains the information, with input from specialists – finance, legal, property etc. The Business Case must be reviewed by the Project Owner or Project Board and updated as required at specific points during the project lifecycle, usually at the end of each stage. These reviews are critical to confirming the continuing viability of the project. See Appendix 5 for more detail regarding composition and derivation.

Checklist for Starting Up All projects:

Organisation structure established, key roles appointed Project team members identified and available Key stakeholders consulted Project Approach completed, including procurement route if

appropriate Project Brief completed Milestones identified Risk Log created, risks analysed and evaluated Initial Business Case approved * Project Brief approved * Funding available and approved *

Also for Medium and Large projects:

Initiation stage plan completed Approval to proceed to Initiation stage *

* Please refer to Appendix 4 for more information regarding project type approval procedures

of 39

(1b) Initiating


(1a) Starting Up (1b) Initiating Project

definition and planning

Getting started Planning and

controlling stages

Project closure

Managing product delivery

Project evaluation

Benefits delivery Note: In small projects, starting up and initiating the project can be combined

The initiation stage is where the detailed planning of a project is carried out. On small projects, the Starting Up and Initiation stages can be merged into one short stage. The tasks are described below.

Project scale:

Now that more is known, the Project Manager should re-visit the project assessment to confirm the scale of the project (small, medium, large) – see Appendix 1 for the Project Scaling Tool.

Project organisation:

The Project Manager should agree with the Project Owner (or Executive) the establishment of the complete project organisation, including stakeholders and support, suited to the scale and nature of the project. Product Descriptions:

By clearly defining each of the project’s products, the Project Manager can build realistic plans to deliver each of the identified products to the agreed quality standards. A Product Description should be written for each significant product, at least in outline at this stage, by the Project Manager and agreed by all those affected by that particular product. A product description defines a product’s purpose, composition, where it comes from and quality criteria. See Appendix 5 for more detail regarding composition and derivation.

Quality Assurance:

In the project environment, quality is about ‘fitness for purpose’. For medium and large projects, the Project Manager should consult with the Head of Performance to ensure that Quality Assurance techniques are applied for the duration of the project.

of 39

Project Plan:

The timescale and estimates of cost and effort must be established. This information is recorded by the Project Manager in the Project Plan. Depending on the scale of the project, use should be made of available document templates for scheduling the project tasks and defining their interdependencies. Business Case:

The Business Case outlines when starting up the project should be reviewed by the Project Owner and additional information added as appropriate.

Project Initiation Document (PID):

The Project Manager constructs a PID that brings together the key pieces of information and provides the baseline for the project. The contents of the PID may be maintained as separate documents – for example, the Project Plan, Risk Log and Business Case – to enable the more dynamic information to be updated easily during the project. However, the PID needs to represent the entire project at any given point during the project, so if some parts are maintained separately, their impact on other parts of the PID also need to be checked and updated accordingly. The PID will reflect the type of project it is describing. The length and level of detail only needs to be sufficient to ensure the project is properly set up and has appropriate controls. See Appendix 5 for more detail regarding composition and derivation.

Checklist for Initiation All projects:

Project scale confirmed Complete project organisation in place, including stakeholders Relevant quality standards defined Risk Log updated and all risks assessed Project Plan completed Funding confirmed Business Case refined and approved PID completed and approved Approval to proceed obtained


Change control procedures in place

of 39

(2) Running the Project


(1a) Starting Up (1b) Initiating Running a project involves three fundamental activities:

Planning: determining what has to be done, by when and by whom, updating the plans to reflect changing circumstances

Managing: managing the plan, the budget, the issues, the risks and the team,

checking on progress, controlling changes, making decisions and approving progress

Delivering: getting things done, checking the products achieve the required

quality, involving stakeholders, reporting progress

Stages: On small projects there may only be one delivery stage, but medium and large projects should be broken into stages. The tasks that the Project Manager carries out and/or leads during a stage are:

delivering the right products to their specification in the correct sequence

providing direction to the team and making best use of resources

monitoring progress and costs against plans

updating plans

managing any deviations from plans

managing the cost and impact of any changes

ensuring all stakeholders are engaged appropriately

following the agreed procedure for reporting progress

Project definition

and planning Getting started

Planning and controlling

stages

Project closure


Project evaluation

Benefits delivery

managing and updating the Risk Log

of 39

The tasks at the end of each stage are:

assurance by the Project Owner or Project Board that all products delivered during the stage have been completed satisfactorily

the Project Manager prepares information about the status of the project for the Project Owner or Project Board to make a decision on the continued viability of the project

the Project Manager prepares detailed plans for the next stage

the Project Owner or Project Board authorises the Project Manager to proceed with the next stage of the project

Progress Monitoring and Reporting - RAG: It is extremely important that all key elements identified within a project plan are maintained, regularly reviewed and reported to the relevant stakeholders as and when required (for example, the Project Board, Project Team, Performance Team). Using a RAG (Red, Amber, Green) reporting system provides a simple and effective means of quickly assessing project status. A RAG based project report instantly highlights which areas of a project are on track, which are not on track but are under control and areas which are delayed or experiencing significant problems. Each project should have some form of RAG progress reporting in place, with definition as follows: Red - off budget or off plan, and no mitigation in place

Amber - off budget or not on schedule, but mitigation in place to get back on budget and schedule Green - on budget and on plan Change Control: Changes are inevitable on projects but it is important to control which changes are acceptable to the project and which are not. Changes may be requested that affect the project plan or any of the project’s products. Changes should only be accepted once their impact on the project has been fully assessed and agreed by the Project Manager or, in more significant cases, the Project Owner or Project Board.

of 39

Checklist for end of each stage

All projects: uality standards and project controls adhered to

lid and funding confirmed (or checked for

ed with no major issues outstanding

oject if at

e Head of Performance -

Relevant q Risk Log updated and all risks assessed Project Plan updated Business Case still va

achievement if at closure) End Stage Review complet

Next stage plans prepared (unless this is the final stage) Approval to proceed to next stage, or approval to close pr

final stage, or project stopped if not viable R.A.G. progress and update reporting to thsee example template in Appendix 4

of 39

(3) Closing the Project


(1a) Starting Up (1b) Initiating Project

definition and planning

Getting started Planning and

controlling stages

Project closure


Project evaluation

Benefits delivery Project closure is when the project’s products are formally handed over to the support organisation or become “business as usual”. The skills and knowledge that are required to make best use of the products should also be handed over from the project team to the business, as required. The project’s products enable the organisation to achieve the benefits that prompted the project in the first place. The responsibility for realising benefits should be allocated to those who can actually make the change happen in the business. Checklist for Project Closure All projects:

Documentation finalised by the Project Manager Any outstanding issues that cannot be resolved by the project are

handed over to appropriate person(s) for resolution All products have been delivered according to their Product

Descriptions The products have been formally accepted by the recipients The recipients are able to use the products and realise the benefits

from using them Suitable arrangements are in place for continuing support Lessons Learned Report completed by the Project Manager and

passed to the Head of Performance to contribute to organisational learning

Project closure approved by the Project Owner or Project Board so that the project organisation can be disbanded


End of project review carried out by the Project Manager

of 39

6. PROJECT DOCUMENTATION

The purpose of developing and maintaining project documents is to initially help define the project and form a basis for ongoing management and assessment of its overall success. The documents developed during the Starting Up and Initiating stages (for example, the Project Initiation Document/PID) have three primary uses:

Ensure that the project has a sound basis before asking the Project Board to make any major commitment to the project

Act as a base against which the Project Board and Project Manager can assess progress, issues and ongoing viability questions

Provide a single source of reference about the project so that people joining the ‘temporary organisation’ can quickly and easily find out what the project is about and how it is being managed

Project planning is extremely important, as it is a not only a means of identifying the tasks required throughout the life of a project, but also used as a measure of control. Plans should be treated as ‘working documents’ and be regularly updated and communicated to the relevant stakeholders. Sometimes larger projects are broken down into stages, with their own project stage plans developed and approved. Essentially, a project plan answers basic questions about the project: What? - What is the work that will be performed on the project? What are the major products/deliverables? Who? - Who will be involved and what will be their responsibilities within the project? When? - What is the project timeline and when will particular meaningful points, referred to as milestones, be complete? It is recommended that regular reviews are made both during the life of a project and particularly at the end to check delivery against original objectives. It is also useful to conduct and report some sort of lessons learnt review, which can be used for future similar projects. It is not necessary to have every piece of project documentation to be completed for every project, although there are some key documents which should ideally be applied to all – these are highlighted in the table on page 20 as well as within Appendix 5. The level of detail within project documents can and should be tailored to suit the project. For example, a Business Case for a small project may only contain one or two sentences for each heading, whereas a larger project may contain a much greater level of detail (or perhaps additional supporting documents).

of 39

The below table lists all the key project management documents and recommends those required for Small, Medium and Large projects:

Project Size Project Document Small Medium Large

Project Brief * Risk Log *

Project Approach *

Business Case *

Product Descriptions * Quality Plan/Strategy - Recommended

Project Plan *

Project Initiation Document (PID) * End Stage Review - Recommended

Stage Plans - Recommended Change Control Process - - Lessons Learnt Report Recommended

End of project review Recommended * Core project documents – should be compiled as a minimum. Details of composition and derivation contained within Appendix 5 Version Control: Version control is the management of multiple revisions to the same document and enables us to tell one version of a document from another. It is particularly important for project documents, particularly plans, as they are regularly updated and amended. All electronic project documents should be saved using a unique version number and contain date and author information to distinguish one version from another. This procedure should be used for all documents where more than one version exists, or is likely to exist in the future. Document Storage: TO BE DISCUSSED & AGREED

of 39

APPENDICES

APPENDIX 1 PROJECT SCALING TOOL 22

APPENDIX 2 RISK MANAGEMENT 23

For a detailed explanation of the council’s approach to managing risk please refer to the Risk Management Policy and Strategy v5 which can be found on the intranet. 23

Risk Responses 24

APPENDIX 3 GLOSSARY OF TERMS 25

APPENDIX 4 PROGRAMME MANAGEMENT 28

APPENDIX 5 KEY PROJECT DOCUMENTS 29

PROJECT BRIEF 30

32 PROJECT APPROACH

33 BUSINESS CASE

PROJECT INITIATION DOCUMENTATION (PID) 35

PRODUCT DESCRIPTION 37

of 39

Appendix 1 Project Scaling Tool The scale of a project can be assessed by adding up scores against the criteria in this table:

Score Enter Criteria Score (1-4)1 2 3 4

10,000 - 50,000

50,000 - 250,000 >250,000 <10,000 Cost (£)

Timescale <6 6-12 12-18 >18 (months)

Direct contribution to a strategic target

Direct contribution to more than one strategic target

Contributing to other work that is linked

No dependency

Strategic targets

Some new business processes and possibly some re-training

Significant re-structure of processes and work areas

Transfer of staff or outsourcing

None or very minimal

Impact on organisation

Some links to other work that is delivering policy or legislation

Fundamental to achievement of policy or legislation

Direct links to policy or legislation

External No link policy or

legislation

Internal and within single Service

Internal across more that one Service

Internal and external Mainly external Stakeholders

Multiple contracts with known suppliers

Contract(s) with new supplier(s)

Single contract with known supplier

No contracts required

Contract complexity

Have done similar before, but not the same

Have not done anything like this before

Have done this before many times

Have done this before once or twice

Track record

Scale of project: Total score 0

= Small 8 - 15 = Medium 16 - 24 = Large over 24

Clearly, assessing the scale of a project is not an entirely objective process; experience and common sense should be used to confirm the most appropriate level of project management.

of 39

Appendix 2 Risk Management For a detailed explanation of the council’s approach to managing risk please refer to the Risk Management Policy and Strategy v5 which can be found on the intranet.

of 39

Risk Responses A number of alternative strategies are available when planning suitable responses to identified risks, as described in the table below. Response Definition

Typically involves changing some aspect of the project, i.e. the scope, procurement route, supplier or sequence of activities, so that the threat either can no longer have an impact or can no longer happen

Avoid

Proactive actions taken to: Reduce

Reduce the probability of the event occurring, by performing some form of control

Reduce the impact of the event should it occur Putting in place a fallback plan for the actions that will be taken to reduce the impact of the threat should the risk occur. This is a reactive form of the ‘reduce’ response which has no impact on likelihood

Fallback

A third party takes on responsibility for some of the financial impact of the threat. (For example, through insurance or by means of appropriate clauses in a contract). This is a form of the ‘reduce’ response which only reduces the financial impact of the threat.

Transfer

A conscious and deliberate decision is taken to retain the threat, having discerned that it is more economical to do so than to attempt a threat response action. The threat should continue to be monitored to ensure that it remains tolerable.

Accept

Modern procurement methods commonly entail a form of risk sharing through the application of a pain/gain formula: both parties share the gain (within pre-agreed limits) if the cost is less than the cost plan; and share the pain (again within pre-agreed limits) if the cost plan is exceeded. Several industries include risk-sharing principles within their contracts with third parties.

Share

TM(Source: PRINCE2 – Managing Successful Projects with PRINCE2 , OCG published)

of 39

Appendix 3 Glossary of Terms Benefits

The measurable improvements resulting from an outcome which are perceived as an advantage by a stakeholder. Business Case

Information that describes the justification for setting up and continuing a project. It provides the reasons why the project was necessary and is updated at key points throughout the project. Change control

The procedure that ensures that all changes that may affect the project’s agreed objectives are identified, addressed and either approved, rejected or deferred. Executive (Project Owner)

The single individual with overall responsibility for ensuring that a project meets its objectives and delivers the projected benefits. This individual should ensure that the project maintains its business focus, that it has clear authority and that the work, including risks, is actively managed. The Executive chairs the Project Board. Milestone

A significant event in a project, such as the publication of a major report or a deadline imposed by central government. PRINCE2

A method that supports some selected aspects of project management. The acronym stands for Projects IN Controlled Environments. Product

Any output from a project. PRINCE2 distinguishes between management products (which are produced as part of the management or quality processes of the project) and specialist products (which are those products that make up the final deliverable). A product may itself be a collection of other products. Product Description

A description of a product’s purpose, composition, derivation and quality criteria. It is produced at planning time, as soon as the need for the product is identified. Programme

A portfolio of projects selected, planned and managed in a coordinated way. Project

A temporary organisation that is created for the purpose of delivering one or more business products according to a specified Business Case.

of 39

Project Assurance

The Project Board have a responsibility to ensure that the project is being conducted correctly. The Board members each have a specific area of focus for Project Assurance, namely business assurance for the Executive, user assurance for the Senior User(s) and supplier assurance for the Senior Supplier(s). They may however choose to delegate this assurance function on their behalf, although this cannot be give to the Project Manager to do. Project Board

This is the group that gives overall direction to a project. It is comprised of managerial decision-makers representing the business, users and suppliers. Project Brief

A statement that describes the purpose, cost, time, performance requirements and constraints for a project. It is created pre-project during the Starting Up process and is used during the Initiating process to create the Project Initiation Document (PID) and its components. It is superseded by the PID and not maintained. Project Initiation Document (PID)

A document, or set of documents, that brings together the key information needed to start the project on a sound basis and that conveys the information to all concerned with the project. Project Manager

The person given the authority and responsibility to manage the project on a day to day basis to deliver the required products within the constraints agreed with the Project Board. Project Owner

Equivalent to Executive on a small project. Project Support

An administrative role in the project management team. Project Support can be in the form of advice and help with project management tools, guidance, administrative services such as filing, maintaining project documents and collection of data. Quality

Within projects, quality is a question of identifying what it is about a project’s products of services that makes them fit for purpose – the features and characteristics of a product that bears on its ability to show it meets expectations or stated needs, requirements or specifications. Quality Assurance

An independent check that products will be fit for purpose of meet requirements. Risk

An uncertain event or set of events that, should it occur, will have an effect on the achievement of objectives. A risk is measured by a combination of the probability of a perceived threat occurring, and the magnitude of its impact on objectives.

of 39

Risk Log

A document that provides identification, estimation, impact evaluation and countermeasures for all risks to the project. It should be created during the start-up of the project and be reviewed and maintained throughout the life of the project. Senior Supplier

The Project Board role that provides knowledge and experience of the main discipline(s) involved in the production of the project’s deliverable(s). Represents the supplier(s) interests within the project and provides supplier resources. Senior User

A member of the Project Board, accountable for ensuring that user needs are specified correctly and that the solution meets those needs. Stage

A manageable subset of a project. Projects are partitioned into stages and each stage ends with a management decision point for the Project Board. Stakeholders

Parties with an interest in the delivery and outcome of a project. They would include business areas affected by or dependent on the outcome of a project.

of 39

Appendix 4 Programme Management All the projects associated with the Council will fall into one of the five programmes listed below. If you are not sure which of the five programmes your project should be aligned with please contact the Performance Analyst or Head of Performance for details.

I & D Plan I & D Actions I & D Management Framework

Capital Programme

Capital Projects

Capital Programme Management Framework

IT Board IT Projects IT Programme

Development Committee

Town Centre Development

Town Centre Projects

C.M.T. Revenue Programme

Revenue Projects

Approval Processes The approval process for including projects in each of these programmes varies so is not detailed here. However, they will all involve completing the start up phase documentation as described in this framework. For more information on the specific approval process for a programme please contact the Performance Analyst or Head of Performance for details.

of 39

Appendix 5 Key Project Documents Product Description Outlines (those highlighted in bold are key)

• Project Brief • Risk Log

• Project Approach

• Initial Business Case – Refined Business Case (IP)

• Product Descriptions

• Quality Plan/Strategy (M/L projects)

• Project Plan

• PID

• End Stage Review (M/L projects)

• Stage Plans (M/L projects)

• Change control process

• Lessons Learned Report

• End of project review (M/L projects)

of 39

PROJECT BRIEF 1. Purpose A Project Brief is used to provide a full and firm foundation for the initiation of the project and is created in the Starting Up and project process. In the Initiating a project process the contents of the Project Brief are extended and refined in the Project Initiation Document (PID), after which the Project Brief is no longer maintained. 2. Composition

Project definition – explaining what the project needs to achieve. It should include:

- Background - Project objectives (covering time, cost, quality, scope, risk and

benefit performance goals) - Desired outcomes - Project scope and exclusions - Constraints and assumptions - Project tolerances - The user(s) and any other known interested parties - Interfaces

Outline Business Case (see later Appendix)

Project Approach (see later Appendix)

Project organisation – team structure and role descriptions

References – to any associated documents or products 3. Derivation

A project mandate supplied at the start of the project

Programme management – if the project is part of a programme, the Project Brief is likely to be supplied by the programme, and therefore it will not have to be derived from a project mandate

Corporate Strategy and any policies and standards that apply

Lessons learnt from previous projects 4. Format and presentation

A Project Brief can take a number of formats, including:

Document or presentation slides

Entry in a project management tool 5. Quality Criteria

of 39

It is brief because its purpose at this point is to provide a firm basis on which to

initiate a project. It will later be refined and expanded as part of the PID The Project Brief accurately reflects the project mandate and the requirements of

the business and the users

The Project Approach considers a range of solutions

The Project Approach has been selected which maximises the chance of achieving overall success for the project

The project objectives, Approach and strategies are consistent and in line with the Councils corporate objectives

The project objectives are Specific, Measurable, Achievable, Realistic and Time-bound (SMART)

of 39

PROJECT APPROACH 1. Purpose To define the type of solution to be developed by the project and/or the method of delivering that solution. It should also identify any environment into which the solution must fit. 2. Composition

Options considered, for example: - bespoke - contracted out - current product modified - ‘design from scratch’ - use company staff - hire in contract staff - use of consultant - buy a ready made solution

Chosen option

Reasons for selection/rejection, for example, part of a programme approach

Operational environment (identification of any environment into which the solution must fit)

3. Derivation

Project Brief

Design authority or equivalent

Marketplace – that is, what is available 4. Quality Criteria

It must confirm to the strategy that relates to the product’s operational environment

It must be achievable within all known time and cost constraints for the project

It must be achievable with known technology

of 39

BUSINESS CASE 1. Purpose A Business Case is used to document the justification for the undertaking of a project, based on the estimated costs (of development, implementation and incremental ongoing operations and maintenance costs) against the anticipated benefits to be gained and offset by any associated risks. The Outline Business Case is developed in the Starting Up and project process and refined by the Initiating a project process. It should be reviewed at the end of each management stage and again at the end of the project. 2. Composition

Executive summary – Highlights the key points, which should include important benefits and the return on investment (ROI)

Reasons – Defines the reasons for undertaking the project and explains how the project will enable the achievement of corporate strategies and objectives

Business options – Analysis and reasoned recommendation for the base business options of: do nothing, do the minimal or do something

Expected benefits – The benefits that the project will deliver expressed as measurable terms against the situation as it exists prior to the project. Benefits should be both qualitative and quantitative

Timescale – Over which the project will run (summary of the project plan) and the period over which the benefits will be realised

Costs – A summary of the project costs (taken from the project plan), the ongoing operations and maintenance costs and their funding arrangements

Investment appraisal – Compares the aggregated benefits to the project costs

Major risks – Gives a summary of the key risks associated with the project together with the likely impact and plans should they occur

3. Derivation

Project mandate and Project Brief - reasons

Project Plan – costs and timescales

The Senior User(s) – expected benefits

The Executive – value for money

Risk Register 4. Format and presentation A Business Case can take a number of formats, including:

Document or presentation slides

l Entry in a project management too

of 39

5. Quality Criteria

The reasons for the project must be consistent and with the corporate or programme strategy

Business Case must be aligned The project plan and

The benefits should be clearly identified and justified

It should be clear how the benefits will be realised

ome It should be clear what will define a successful outc

of 39

PROJECT INITIATION DOCUMENTATION (PID) 1. Purpose The purpose of the PID is to define the project, in order to form the basis for its management and an assessment of its overall success. The PID gives the direction and scope of the project and (along with Stage Plans) forms the ‘contract’ between the Project Manager and the Project Board. The three primary uses of the PID are to:

Ensure that the project has a sound basis before asking the Project Board to make any major commitment to the project

Act as a base document against which the Project Board and Project Manager can assess progress issues and ongoing viability questions

Provide a single source of reference about the project The PID is a living product and should therefore always reflect the current status, plans and controls of the project. 2. Composition The following is a contents list for the PID. Note that the first two (Project Definition and Project Approach) are extracted from the Project Brief.

Project Definition – Explaining what the project needs to achieve. It should include:

- Background - Project objectives and desired outcomes - Project scope and exclusions - Constraints and assumptions - The user(s) and any other known interested parties - Interfaces

Project Approach

Business Case – Describing the justification for the project, based on estimated costs, risks and benefits

Project management team structure – A chart showing who will be involved with the project

Role descriptions – For the project management team and any other key resources

Quality – Details of any quality management strategy adopted or techniques/standards to be applied with designated responsibilities

Communication – Details of the means and frequency of communication between interested parties and the project

Project Plan – Describing how and when the project’s objectives are to be achieved

Project Controls – Laying down how control is to be exercised within the project and the reporting and monitoring mechanisms that will support this (will include exception/out of agreed tolerance processes)

of 39

3. Derivation

Project Brief

Discussions with user, business and supplier stakeholders for input on methods, standards and controls

4. Format and presentation The PID could be:

A single document

An index for a collection of documents

A document with cross-references to a number of other documents 5. Quality Criteria

The document correctly represents the project

It shows a viable, achievable project that is in line with corporate strategy or overall programme needs

The project organisation structure is complete, with names and titles. All the roles have been considered and are backed up by agreed role descriptions

It clearly shows a control, reporting and direction regime that can be implemented, appropriate to the scale, risk and importance of the project to corporate or programme management

The controls cover the needs of the Project Board, Project Manager and Team Managers and satisfy any delegated assurance requirements

It is clear who will administer each control

of 39

PRODUCT DESCRIPTION 1. Purpose A Product Description is used to:

Understand the detailed nature, purpose, function and appearance of the product Define who will use the product Identify the sources of information or supply for the product Identify the level of quality required of the product Enable identification of activities to produce, review and approve the product Define the people or skills required to produce, review and approve the product

2. Composition

Identifier – Unique key or reference number

Title – Name by which the product is known

Purpose – This defines the purpose that the product will fulfil and who will use it

Composition – This is a list of all the parts of the product. For example, if the product were a report, this would be a list of the expected chapters or sections

Derivation – What are the source products from which this product is derived? Examples are:

- a design is derived from a specification - a product is bought in from a supplier - a statement of the expected benefits are obtained from the user - a product is obtained from another department or team

Format and presentation – The characteristics of the product. Any standard appearance to which the product must conform

ired to develop the

Development skills requiredproduct or a pointer to which area(s) should supply the development resources

– An indication of the skills requ

Quality criteria – To what specification must the product be produced and whatquality measurements will be applied by those inspecting the finished product? Quality tolerance – Details of any range in the quality criteria within which the

product would be acceptable

f quality method that are to be used to check the

Quality method – The kinds oquality or functionality of the product

n of the skills required to undertake the ces

Quality skills required – An indicatioquality method or a pointer to which area(s) should supply the checking resour

. Derivation

Quality responsibilities – Defining the producer, reviewer(s) and approver(s) for the product

3

The end users of the product

(if applicable)

Quality Management Strategy

of 39

4. Format and Presentation

r number of formats, including: A P oduct Description can take a

Document, presentation slides or mindmap

Entry in a project management tool 5. Quality Criteria

The purpose of the product is clear and is consistent with other products

The product is described to a level of detail sufficient to plan and manage its development

ewed and approved

The Product Description is concise yet sufficient to enable the product to be produced, revi

Responsibility for the development of the product is clearly identified of the product is consistent with the roles and

n Responsibility for the development responsibilities described in the project management team organisatio

The quality criteria are consistent with the project quality standards, standard checklists and acceptable criteria

e The quality criteria can be used to determine when the product is fit for purpos

uired are able to verify whether the product The types of quality inspection reqmeets its stated quality criteria

in The Senior User(s) confirms that their requirements of the product, as defined the Product Description, are accurately defined

n The Senior Supplier(s) confirms that the requirements of the product, as defined ithe Product Description, can be achieved

of 39

Acknowledgements This Framework document has been derived from a number of sources:

• ODPM (Office of the Deputy Prime Minister) • Project Management Handbook for Local Government • OGC (Office of Government Commerce):

- Successful Delivery Toolkit - Managing Successful Projects with PRINCE2

• Project Management Handbook, produced by West Sussex County Council • Boston Borough Council – Method for Successful Projects

of 39