South Norfolk Council Project Management Handbook

South Norfolk Council Project Management Handbook Version 1.0 With special thanks and acknowledgement to the Manchester City Council in particular Kevin Fletcher, Bob Rutt, Julie Sprigg, Alan Holding & Victoria Bottomley and the e-capacity building programme Date 17/04/2007 Page 1 of 82

Title: South Norfolk Council Project Management Handbook Copyright South Norfolk Council Executive Summary This document describes the overall process for South Norfolk s Project Management standards. It describes the basic processes and procedures to be followed throughout a project lifecycle using standard document templates and working practices. Reference: Version: 1.0 Date: Status: Sponsors: Authors: 1 st March 2007 First full issue Project Management Work Group George Colvin Beverley Herring Colin Wilson Tim Mobbs Janet Norman-Philips Date 17/04/2007 Page 2 of 82

DOCUMENT HISTORY Document Date/Title Version Reference/ Date Comments SNC Project management Draft Draft version standards 1.0 Revised version Draft 2.0 June 06 Tim Mobbs version Version 3 Draft 3.0 August 2006 Version 2 plus missing bits from old standards plus nationally approved PM guidelines based on Manchester City Council s PM standards. PM (New) Standards v3.1 Draft 4/9/06 Includes revisions after circulation of 3.1 version 3.0 PM (New) Standards v3.2 Draft 3.2 9/2/07 Revisions to templates, revisions to communication issue, removal of any IT style wording, guidance on when these standards need to be used and which parts relates to small and big projects SNC Project Management 1.0 1/3/07 First proper issue of standards Standards Date 17/04/2007 Page 3 of 82

Table of Contents Project Management Manual 1. Project Management... 7 INTRODUCTION... 7 WHY SHOULD SOUTH NORFOLK COUNCIL ADOPT THIS APPROACH?... 8 PRINCIPLES OF GOOD PROJECT MANAGEMENT... 8 WHEN SHOULD I USE THESE STANDARDS?... 9 HOW ARE PROJECTS CATEGORISED IN SOUTH NORFOLK COUNCIL?... 9 WHAT IS THE DIFFERENCE BETWEEN A, B AND C PROJECTS?... 9 WHAT ARE THE MINIMUM DOCUMENTATION AND GATWEAY REQUIREMENTS FOR PROJECTS?... 10 SOUTH NORFOLK COUNCIL (SNC) GATEWAY PROCESS... 11 WHAT IS A PROGRAMME?... 11 WHAT IS A PROJECT?... 12 WHAT IS PROJECT MANAGEMENT AND WHY DO WE DO IT?... 12 WHAT ARE THE BENEFITS FROM PROJECT MANAGEMENT?... 13 PROJECT LIFE CYCLE... 14 FURTHER CHANGES TO THIS DOCUMENT... 14 2. Project Organisation... 15 ORGANISATIONAL STRUCTURE... 15 PROJECT SPONSOR... 16 SPECIALIST ADVISOR... 17 PROJECT MANAGER... 17 PROJECT BOARD... 18 PROJECT OFFICER (SENIOR USER)... 19 PROJECT TEAM... 19 PROGRAMME MANAGER... 19 PROGRAMME BOARD... 20 3. Project Start-up... 21 THE PROJECT MANDATE... 21 START-UP OF A PROJECT... 21 THE PROJECT INITIATION DOCUMENT (PID)... 22 PROJECT APPROACH... 23 QUALITY PLANNING... 24 THE RISK LOG... 24 THE ISSUE LOG... 25 PLANNING... 25 PROJECT PLAN... 26 STAGE PLAN... 26 ADMINISTRATION... 27 GENERAL ADMINISTRATION... 29 5. Project Justification... 31 THE JUSTIFICATION STAGE... 31 Date 17/04/2007 Page 4 of 82

THE PROJECT DEFINITION WORKSHOP... 31 PROJECT INITIATION AND PLANNING... 32 THE LESSONS LEARNED LOG... 32 STAKEHOLDER ANALYSIS AND STRATEGY... 33 BUSINESS ANALYSIS, PROCESS MAPPING AND BUSINESS PROCESS RE ENGINEERING... 34 THE COMMUNICATION PLAN... 34 PREPARATION OF THE BUSINESS CASE... 35 PROCUREMENT... 35 INVOLVEMENT OF E-GOVERNMENT... 36 EVALUATION AND SELCTION... 37 INVESTMENT DECISION... 39 6. Delivery of a Project... 40 PROJECT DELIVERY... 40 FINANCIAL TRACKING... 40 CONTRACTS... 40 CONTROLLING A STAGE... 41 THE WORK PACKAGE... 41 MANAGING STAGE BOUNDARIES... 42 CHANGE CONTROL... 43 FITNESS FOR PURPOSE... 43 7. Project Review... 44 PROJECT REVIEWS... 44 ATTENDANCE AT REVIEWS... 45 DISTRIBUTION OF MINUTES/ACTIONS... 45 FREQUENCY OF REVIEWS... 46 DOCUMENTATION REQUIRED FOR REVIEWS... 46 FORMAT OF PROJECT REVIEWS... 47 ESCALATION AND SUPPORT... 47 8. Project Reporting... 48 PROJECT MANAGEMENT REPORTING... 48 PROGRESS REPORT... 48 FINACIAL REPORTING... 48 EXCEPTION REPORT... 49 END STAGE REPORT... 49 LESSONS LEARNED REPORT... 49 END PROJECT REPORT... 49 FOLLOW-ON ACTION RECOMMENDATIONS... 50 9. Closing a Project... 51 10. Jargon Buster... 52 11. Templates... 56 Date 17/04/2007 Page 5 of 82

ANNEX 1: CHANGE REQUEST... 56 ANNEX 2: LESSONS LEARNED LOG... 57 ANNEX 3: FINANCE PROFORMA... 58 12. Appendices... 59 APPENDIX 1: IS/ITPROCUREMENT GUIDELINES... 59 APPENDIX 2: E-GOVERNMENT INTEROPERABILITY FRAMEWORK... 63 APPENDIX 3: THE SOUTH NORFOLK PROJECT GATEWAY PROCESS... 65 APPENDIX 4: RISK MANAGEMENT... 68 APPENDIX 5: PRODUICNG A GANTT CHART... 70 APPENDIX 6: ROLE OF COMMUNICATION... 76 Date 17/04/2007 Page 6 of 82

1. Project Management Introduction This manual has been developed to explain South Norfolk Council s approach to project management in order to assist with the planning and management of projects. Project management is about ensuring that an objective is achieved on time, within budget and with no surprises. It is about managing risk, expectations and activities. The South Norfolk approach is based on the Prince2 1 methodology. The approach outlined in this document aims to complement present working practices and procedures. It is applicable to all projects, both capital and revenue. It sets out the way the Council evaluates projects at key stages throughout the project life cycle. Annexed to the handbook are template documents to be used in the project management process. The accurate recording of any project will provide useful and vital information during the project lifecycle and Post-project Review. This document aims to standardise the basic process for project management and achieve a consistency of approach and best practice across the Council. It also aims to provide new project managers with an understanding of the main components required to successfully manage a project throughout the project lifecycle. An ongoing initiative of awareness and training is in place in order to support this method. It is expected that project managers will read this document first, and then refer to other documentation and templates as required. The aim is to provide a standard framework that incorporates previous experience, some current practices and common sense. There is some new terminology and these terms are explained in the Jargon Buster section. In order to maintain consistency it is important that the content of this original document is not altered. All documents associated with this handbook will be held on the intranet and on the O drive. This document will be revised from time to time to incorporate other elements of best practice. Located in the header of this document is the version number as a reference. Please contact the Programme Office for confirmation of the latest version of this handbook. 1 PRINCE2 is the 2 nd iteration of the project management methodology PRojects IN a Controlled Environment Date 17/04/2007 Page 7 of 82

Why should South Norfolk Council adopt this approach? Project Management standards were developed for IS/IT in 2000, these have now been absorbed within this document to produce a common standard for the whole council. It has been developed in response to: The need to manage a wide range of projects more effectively and efficiently through all stages. The use of generic project management methods and skills to provide a strategic and systematic approach to implementing major change is one of the Management Standards that were introduced following the Local Government Performance Improvement Review 2000 A paper from the Office of the Deputy Prime Minister entitled Towards a National Strategy for Local Government Procurement, which states appropriate project management procedures (based on the PRINCE 2 method) should be set out in a corporate project management handbook or in the council s procurement code of practice The requirements from central government, which ensure all projects are correctly managed and risk-robust Principles of Good Project Management Project management provides a structured approach to project delivery to achieve the best results. Too often a project fails because of an approach that moves from perceiving a problem to choosing a solution, even implementing a solution. While the solution resolves the problem, it does not identify the cause of the problem. The implementation of a standard basic approach to project management will enable the following to be achieved on all projects: Delegation of responsibility A controlled and organised start, middle and end Regular reviews of progress against plan and against the Business Case Flexible decision points Automatic management control of any deviations from the scope and plan The involvement of management and stakeholders at the right time and place during the lifecycle of the project Good communication channels between the project, project management, and the rest of the Council Early warning and the ability to manage down any project risks and issues The ability to end a project prematurely if it becomes no longer worthwhile or viable Date 17/04/2007 Page 8 of 82

The ability to manage external suppliers against a standard methodology The ability to monitor a project through reports on progress, cost and risk. When using this method to manage a project, the project manager will find that a large element of the work is completed during the Start-up and Justification stages. The Council s approach to project management is based on gaining a thorough appreciation of a project before committing substantial resources. When should I use these standards? These standards can be applied to all projects within the council as each project needs to consider all the main issues raised. Smaller projects (see next para) will not, however, need to complete all the Gateway stages not produce all the documentation, this is described more fully in the next two paragraphs How are projects categorised in South Norfolk Council? Projects in South Norfolk Council are categorised into three groups called A projects, B projects and C projects, the difference between them are described below. Another categorisation used in other places is to split projects into small and big projects, dependent on the amount of money, time or resources they may require. Unfortunately it is not that simple in real life, many small projects which could be deliver quickly and cheaply can have a massive impact on the Council and rightly these should be given due consideration due to their impact, Conversely many large projects could be relatively straightforward and it would be an unnecessary overhead to complete every stage in the project standards. Therefore when a Project is initiated via a PID it will be up to the programme board(s) / CMT to determine the categorisation of the project A, B or C and whether it needs to follow the standards fully or follow the minimum requirements see below. What is the difference between A, B and C projects? A Projects are the high impact, high visibility projects. They normally relate to our core vision and objectives and are therefore reported on a regular basis to cabinet and members. They may not necessarily have the highest impact and all must follow the minimum requirements. B Projects are not quite as important as A they may more routine or of limited impact or relate to a purely technical change. They may need to meet the full standards because of their complexity but normally these would be expected only to meet the minimum requirements. Date 17/04/2007 Page 9 of 82

C Projects are usually low impact low visibility, normally they are pretty straightforward and although reported to the programme boards they are not normally reported elsewhere. Some may have to undertake the full standards but normally only the minimum requirements will be all that is required. Note projects can be reclassified through their project life cycle normally from A to B or B to C as they progress through their various project stages. What are the minimum documentation and Gatweay requirements for projects? As a minimum requirement all projects must o Have a Project Initiation Document o Go through Gateway 1 (PID approval) o Have a project plan o Have a communication plan/strategy o Maintain a Risk log o Maintain an Issue Log o Report regularly to their Project Boards o Maintain a financial plan o Go through Gateway 5 (Readiness for implementation) o Go through gateway 6 (Post Implementation Project review) Date 17/04/2007 Page 10 of 82

South Norfolk Council (SNC) Gateway process Before a project can even start it must enter go through the council s gateway process. This has been designed to check progress on all projects and to make sure projects are fit for purpose before they proceed too far. There are six steps throughout the life of a project, which will be explained in greater detail later in this document. In Summary the six steps are:- o Step 1 Strategic Assessment - this stage will allow a project to commence after review of a Project Initiation Document by a programme board or CMT o Step 2 Business justification review - review of the business case and approval for project to proceed by the programme board o Step 3 Procurement review review of proposed solution to deliver the benefits identified (and now updated) in the business case also conducted by the programme board. Does the solution proposed meet our procurement strategy? o Step 4 Investment decision Final no/no-go decision by the Project Board after the selection process has been completed and before any product is purchased and implemented o Step 5 Readiness for implementation sign off by the Head of Service (or appropriate person) that the solution is fit to go live o Step 6 Post Implementation project Review conducted within six months of the project closure, should normally produce a lessons learned report for circulation to the programme boards The steps are shown in the main body of the document and the whole gateway process is described in full at Appendix 3 What is a Programme? A portfolio of projects selected, planned and managed in a co-ordinated way that together achieves a set of defined Council objectives. Programme management methods and techniques that are applied to a set of otherwise unrelated projects bounded by a council or government initiative (e.g. Implementing E-Government). Date 17/04/2007 Page 11 of 82

What is a Project? A management environment that is created for the purpose of delivering one or more products according to a specific business case. There are many other similar definitions of what constitutes a project. Other aspects that help define a project are that it will: deliver change have specified and measurable objectives have a finite timescale, with defined start and end points be distinctly different form the maintenance of the status quo Thus, for example, it can be seen that the introduction of a new computer system into South Norfolk would be defined as a project, as would the creation of a new leisure centre, but that day to day line management of either, in use, would not be a project. However, a scheme to change the way the leisure centre worked could be a project, provided it had specified and measurable objectives to be achieved in a specific time period, so that there would be a point at which the project was finished and day to day management could be resumed. At any one time there will be dozens of projects taking place within the Council. Many will be managed at service level because they involve only resources already available in the service. Projects with implications for other services, or which require extra resources, appear on one of the three lists (A, B & C) and are monitored by Cabinet, SMT or one of three programme boards What is project management and why do we do it? Project management is the means by which the desired outcome of a project is achieved. It embraces a series of activities throughout the lifetime of a project, all of which contribute to the achievement of success. The success of a project is measured in terms of three criteria: cost quality Timescale. In order to establish why projects need management, it is helpful to note that in all fields where projects are run, there are always many examples of project failures. Projects can fail in a number of ways, directly related to the criteria for success, such as: cost escalation non-delivery of the expected benefits Late delivery. The underlying causes of these problems are many, including: Date 17/04/2007 Page 12 of 82

a lack of clarity of the project aims insufficient time allowed for planning or inadequately detailed planning insufficient resources available A failure to monitor progress and to take appropriate action when required. The reason why projects need management is so that these causes can be minimised or removed and therefore a project s likelihood of achieving success rather than failure is significantly enhanced. A key role of the project manager is to carry out specific activities around the project which will allow this to happen. The project manager both provides a resource and brings an expertise and approach to be followed. What are the benefits from project management? The reason for adopting project management given above was to increase the likelihood of success rather than failure of the project. More specifically, the use of active project management can be expected to bring these benefits to a project: it increases the likelihood project completion on time, within budget and to specification, it increases the likelihood of project completion on time, within budget and to specification, it can assist the efficient utilisation of available resources, it provides control in an environment where the assumptions are clearly defined, it reduces and assists the management of risk, it enhances visibility and communication and It helps to avoid disaster. Date 17/04/2007 Page 13 of 82

Project Life Cycle This handbook is divided into sections that identify the various elements which contribute to the lifecycle of any project: Project Organisation the role of the key players and teams in a project Project Start-up the Project Mandate, Project Initiation Document, Gateway Step 1, initial risk analysis, the feasibility of the project and the initial preparation of the Business Case, early planning, Gateway Stage 2 Project Justification the importance of the Project Definition Workshop further documentation and preparation of the business case, recommendations for delivery and Gateway approvals for the business case, procurement and the final go-ahead for the project to be delivered. Delivery and Stage Controls monitoring progress against plans, communicating with all appropriate stakeholders, authority to move on to the next stage, includes Gateways Step 5 at each deliverable Project Review establishing key dates to review progress, defining who should attend the Review Meetings this is Gateway Step 6 Project Reporting the frequency of reporting, types of reports Project Closure to Completion final reports required, lessons learned Further Changes to this Document If you have any comments regarding the content of this Handbook, or would like any additional subject matter to be covered in a future release(s), please contact Corporate Director Tim Mobbs. All proposed changes will be reviewed and approved by the Project Management working group on a regular basis. Telephone: 01508 533651 Email: tmobbs@s-noroflk.gov.uk Date 17/04/2007 Page 14 of 82

2. Project Organisation Organisational Structure This section addresses the organisational and management arrangements needed for successful project delivery. This structure allows for the appropriate reporting and control mechanisms to be put in place and for clearly defined roles and responsibilities to be established. Typical Project Management Structure Gateway approvals Programme Boards / SMT Programme Manager Project Sponsor Chairs project Board Project Board Project Manager Specialist Adviser Project Officer / Senior User Project Team At a basic level any project will have: A project sponsor (a senior officer in the organisation) A project manager A strategy to ensure Quality Assurance including Benefits Realisation Delivery of one or more Work Packages Involvement of appropriate staff from the service/s affected by the project. Date 17/04/2007 Page 15 of 82

Some of the roles shown in the above diagram will not be required for some projects at SNC. Project managers must consider line management and reporting as part of the delivery and communication strategy. The management team up to and including all board members must clearly understand their respective roles. All team members have an important part to play in the successful delivery of the project and it is vital that they are kept well informed at all stages. Work completed during the Start-up and Justification stages will clarify the Project Brief, Project Approach, Business Case and any risks recognised so far. This information will form the basis for the Project Initiation Document (PID). Each group and key player in the project structure has clear terms of reference which define roles and responsibilities. As a general rule project Boards and Teams should only contain the number of people needed to achieve the project. Project Sponsor The project sponsor must have an interest in and commitment to the success of the project and is likely to be a head of service or senior business manager. The project sponsor is responsible to ensure that a project meets its objectives and delivers the projected benefits the sponsor should act as the project s champion. The project sponsor should ensure that the project maintains its focus, has clear authority and that the context, including risks, is actively managed. In order to fulfil the terms of reference, the sponsor must be given appropriate authority and have adequate seniority. In particular, the project sponsor will: Take responsibility for a particular project and act as budget holder. Appoint the project manager. Appoint the project board. Assist the project manager in the preparation of a business case for the project, which will be submitted by the sponsor to the Programme Board and Members for consideration and approval. Guide the project through the other Gateways. Convene and chair meetings of the project board. Obtain commitment, including the allocation of appropriate resources, from Heads of Service and other senior managers to ensure the success of the project. Assist the project manager to resolve any problems and conflicts, including those which relate to resourcing, which may arise during the project. Represent the project and project team to Corporate Management Team or the Programme Board and provide a written progress report for the project to Corporate Management Team or the Programme Board meeting. This report will follow a standard format, as set out elsewhere in this document. Date 17/04/2007 Page 16 of 82

Specialist Advisor The specialist advisor role is as a critical friend (or friends) who offer advice and so:- Provide support for the consideration and approval of the business cases. Provide support and advice to the Sponsor on the overall management of the project. Provide support for sponsors to challenge assumptions and identify, address and solve problems. Assist project sponsors to appoint consultants, suppliers and staff in support of the project. Advise project sponsors and project managers in contract negotiations with suppliers. Advise on best practice in project management, quality assurance and other areas and assist South Norfolk to implement and adopt these procedures. Define relevant corporate Standards. Inform Corporate Management Team or the Programme Board of any problems affecting the rolling programme and recommend appropriate courses of action. Conduct ad-hoc reviews of any project. Project Manager The project manager is the individual responsible for delivering a project. The project manager leads and manages the project team with the authority and responsibility to manage a project on a day-to-day basis. It is essential that the project manager should be appropriately trained in project management techniques and processes. The skills and experience of the project manager must be matched to the requirements of the project. In particular, the project manager will: Manage the project team and the project activities, and recruit or appoint such staff as may be necessary in consultation with the project sponsor and the project board. Manage the project budget within the tolerance agreed with the project sponsor. Prepare business cases, project plans and all other project elements for approval by the project board. Project plans should include task definitions, allocation of resources and scheduling information. Further details of project plans will be found elsewhere in this document. Take effective quality assurance measures to ensure, as far as possible, that the project is successful and achieves its objectives. Maintain liaison with suppliers of hardware, software and services, and act as formal point of contact. Advise the project board on the acceptance or rejection of externally purchased items and services. Date 17/04/2007 Page 17 of 82

Monitor the progress of the project and report on its status to the project board on a monthly basis, adopting a standard format as shown elsewhere in this document. Identify and manage risks Produce a Communication Plan Inform the project board of any problems affecting the project and recommend appropriate courses of action. Schedule, convene and chair regular meetings of the project team. Establish and maintain the project office and project library. Identify and resolve all resourcing problems making reference to the project board if necessary. Escalate issues/problems where appropriate Maintain close contact with intended users of the project deliverables (if applicable). Project Board The project board exists to provide direction to, and monitoring of a project. In particular, the board will: Take overall responsibility, under the chairmanship of the project sponsor, for an individual project in South Norfolk. Assist the project sponsor to control the project budget and to delegate appropriate authority to the project manager. Approval of project objectives, scope, Business Case prior to any expenditure Provide guidance to the project manager and the project team. Hold monthly meetings (or as required) to review progress and expenditure against budget, to discuss issues arising and to institute appropriate action to counter any problems. An agenda for the meeting should be circulated prior to the meeting; minutes of the meeting should be taken and the minutes formally agreed at the next meeting. The emphasis will be on quality rather than frequency of meetings. It is important that board members are briefed and prepared and that all meetings are very focused. The role of board members is very much management by exception (i.e. when something is not going according to the criteria which have previously been agreed) and will be asked to make decisions at key points in the project. Receive regular progress reports from the project manager. Assist the project sponsor to review and approve project plans and other key documents prepared by the project manager. Ensure that adequate resources are made available to support the project. Assist the project sponsor to accept or reject deliverable items, acting on the advice of the project manager Monitoring quality control Managing any risks owned by the project board that are highlighted in the Risk Log Date 17/04/2007 Page 18 of 82

Project Officer (Senior User) The Project Officer (also known as the Senior User) is the person who is responsible for the specification of the needs of all those who will use the final product(s), for user liaison with the project team and monitoring that the solution will meet those needs within the constraints of the Business Case in terms of quality, functionality and ease of use. The responsibilities include Ensure the desired outcome of the project is specified Approve product descriptions for inputs and outputs Ensure that the specification of the user s needs is accurate, complete and unambiguous Quality checking of the product at all stages to ensure the product meets user requirements Project Team The project team is a group of people who assist the project manager in delivering the project. The team normally includes officers who will benefit from the project and/or be materially impacted by it. These may be from one team or several and will also include specialists and sometimes outside specialist advisers, and if necessary, technical support personnel from E-Government The main task of the Project team is to assist the project manager in delivering the project. They will be involved with various work packages and can include Developing the business case Identifying benefits Agreeing and revising business processes and outcomes Development of business specification and ITT Evaluating tender responses Attend product demonstrations and site visits User acceptance testing Programme Manager The programme manager, where applicable, is responsible for the delivery of the council s programme of work and works closely with the programme boards. At present there is one programme manager in place who co-ordinates the programme of work for the E-service Programme Board. Date 17/04/2007 Page 19 of 82

Programme Board The Programme boards, where applicable, are responsible for delivery of the council s objectives through the various projects within their responsibility. They act as the guardians of the Gateway process and it is them who monitor the progress of project throughout the lifecycle. It is therefore also the programme boards who normally approve the PID. They will receive regular progress reports and exception reports when projects are expected to go beyond their tolerance limits in respect of budget and/or time. There are three programme boards within South Norfolk Council and very project being undertaken should report to one of these boards. The three boards are: E-Services group chaired by the Head of E-Government this board is responsible for all projects which involve to a greater or lesser extent information technology Affordable Housing group Chaired by Corporate Director Ken Barnes is responsible for all projects which impact on the delivery of the Affordable Housing Strategy. (Need to check responsibility & chair details) Asset Management group chaired by Head of Finance & Property is responsible for all projects not covered by the two sections above. Programme Boards will Police the Gateway process Secure the investment required to run the programme of projects Approve projects to start Approve Project initiation Documents Approve business cases as part of the SNC gateway process Monitor regular progress reports Receive exception report and make appropriate recommendations Receive and action Lessons learned reports Ensure the linkages are maintained between the programme and the organisation s strategic direction Date 17/04/2007 Page 20 of 82

3. Project Start-up The Project Mandate The Project Mandate is a brief written description of why the project is worthwhile and what it intends to achieve. The Project Mandate: Is the first element of the Project Lifecycle Should identify the project s sponsor Is usually the catalyst for preparing the project initiation Document Is the initial idea for the project. A common mistake when completing the Project Mandate is to underestimate the potential costs of delivery for the end product. The Project Sponsor and project manager must ensure allowances have been made for the funding of any additional project staff to resource the team on either a short or long-term basis. From a simple analysis of the cost, it may transpire that the project is not viable. Template for Project Mandate, see Project Mandate. Start-up of a Project The hardest question of all: Do we have a viable and worthwhile project? It is vital that this question is answered honestly, otherwise resources may be committed and time wasted. Date 17/04/2007 Page 21 of 82

The Project Initiation Document (PID) The Project Initiation Document (PID) is developed from information/documentation already produced. The completed PID is the basis for authorisation to continue the project. The PID is a more refined description than the Project Mandate, setting out what the project will achieve, and it must be completed as fully as possible and presented to the appropriate Programme Board at the earliest opportunity. If no meeting of the programme board is planned in the near future and further work must be carried out on the project then the PID must go to CMT for their consideration and approval to proceed (or not). This is also the first step in the SNC gateway process Step 1 Strategic Assessment At this stage an honest assessment must be made as to whether the project is viable or not, whether there is the possibility of the money and resources being made available to undertake the project and its overall impact on current approved, planned programme of work. Only after all these matters are taken into consideration should a decision be made as to whether the project should proceed onto the detailed production of the business case. If the project has no meaningful chance of progress it should be stopped immediately, another potential outcome at this stage is that the project is put on hold pending a situation where conditions are more favourable for the PID to be progressed into a proper Business Case The full layout of the PID document for SNC and a template for completion can be found at PID The PID should cover the following topics Project Description a brief description equivalent to the project mandate Project Aims what are we trying to achieve Benefits sought Preliminary costs estimate Scope of the project Constraints for the project Interfaces with other projects and links to corporate plans and strategies Who will benefit? Any other interested parties Major risks identified thus far Communication issues Who own the project i.e. who will be the project sponsor Date 17/04/2007 Page 22 of 82

The PID must have the approval of the Project Sponsor. When a project manager compiles the Project Brief, it may highlight some potential risks and the completion of the PID usually corresponds with the start of the Risk Log. It is unlikely that all associated risks will be recognised by this one process and a formal risk analysis should be completed. When a formal risk analysis, categorisation and costing exercise have been completed, the question should be asked again, Do we still have a viable and worthwhile project? It is possible that the inherent risks are too great, either through impact or probability to continue. If this is the case, the Project board will have to take the decision to either redefine the scope or to close the project. Whatever the outcome this decision must be confirmed with the appropriate programme Board before any further work is undertaken. Project Approach Before any planning can be undertaken, the project manager should define a Project Approach. For IS/IT-related projects this will require consultation with the Development Manager in E-Government. The Project Approach will define the preferred approach to delivery and any options. It should answer the following questions: Will the solution be bought off-the-shelf? In other words, does the solution already exist either as a complete item or in part? Will the solution or part of the solution be bespoke? In other words, will the Project Approach require a development stage to meet the requirements of the Council? Will the Council be able to provide a solution, with or without development, without using external suppliers? Is the Project Approach based on an existing or recently completed project? Another key part of the Project Approach is an outline of the sustainability of the proposed solution and any maintenance that will be required during or post-project. Sustainability of any project is a major concern to members & CMT and if not outlined in the approach, it is unlikely the project will be signed off. The project manager must be aware of any Council initiatives and any constraints (usually on time/cost) that will apply to the proposed solution. There may be a discussion on various options at this stage and the project manager should outline the risks and opportunities relevant to each option as part of the process. The information compiled for the Project Approach will be fed into other project documentation such as the Business Case. Template for Project Approach, see Project Approach. Date 17/04/2007 Page 23 of 82

Quality Planning Relying on implied needs with regard to quality is open to interpretation and leads to uncertainty. This approach to quality is of little use in project management. During the Start-up stage, quality expectations must be understood and documented. As the project progresses through later stages, the quality of products to be delivered will be specified in greater detail, through individual work packages. When a Work Package is completed, the product can then be measured against the quality criteria specified in the Work Package description. The Project Officer plays a key role here in ensuring that the work packages deliver a quality product that meets the customer s requirements and is fit for purpose. The use of the word quality usually implies only the highest standard of materials and workmanship. The reality of quality in a project environment is in meeting the requirements of the project within budget to agreed expectations. Although outlined in the Start-up stage of the project, the Quality Plan is refined in the Business case. Template for Quality Plan, see Project Quality Plan The Risk Log The management of project risks is a key element of project control. The Council has a well documented approach to the identification and management of risks. The risks to the project should have been identified in the PID and developed in more detail in the business case, together with proposed management action to minimise their impact. Risk management must be a continuous process during the life of a project; the likelihood of identified risks occurring will grow or reduce in potential, as will the effect of a risk situation. New risks may arise; some risks may occasionally be eliminated altogether. The review of project risk should be included in monthly reports by the project manager to the project board and the project sponsor. Risks identified which are specific to the project and can be managed within the project itself will be held and maintained on the risk log. Risks which cannot be managed within the project must be escalated and included as a risk in the corporate Risk Management Action Plans (see Appendix 4 for more details on this). The attached template outlines the column headings for structuring the Risk Log. It is the project manager s responsibility to maintain the Risk Log and to ensure that all risks are owned and managed. Template for Risk Log, see Risk Log. Risk log spreadsheet see Risk log spreadsheet Date 17/04/2007 Page 24 of 82

The Issue Log During the lifecycle of a project, issues will arise on a variety of project-related matters. The Issue Log is a means of recording these issues and tracking their progress through to conclusion. As with the Risk Log and Lessons Learned Log, a unique number must be allocated to each issue. It may also be necessary to allocate ownership to one or more individuals. There should also be a reference to who raised the issue so that they can be informed of progress towards a resolution. It is advisable to record the type of issue. It may not be possible to resolve all issues during the lifecycle of the project but the Issue Log provides a vehicle for managing them and assessing their impact. It is not unheard of to have an ongoing issue throughout the complete Project Lifecycle. There are various times in the Project Lifecycle when the Issue Log should be reviewed such as at Stage End and at Project Closure. Many project managers find the Issue Log a useful reference at formal project meetings where the status and progression of outstanding and new issues are discussed. Template for Issues Log, see Issue Log. Blank Spreadsheet for an Issues Log see Issues log spreadsheet Planning Planning takes place throughout the complete lifecycle of the project. The most common form of a Project Plan is a Gantt chart (for further advice on these see Appendix 5), showing tasks and associated timelines. You can produce this type of plan using software packages such as Microsoft Project. There are no hard and fast rules regarding the use of planning software; however, the Council has adopted Microsoft Project as its standard planning tool. It is important that any production media and associated versions are agreed in the project s Style Guide and that this is communicated to all involved (including outside contractors). If the production media (including version numbers) are not agreed at an early stage, it will be impossible to ensure that the stakeholders are able to view the correct version of project documentation electronically. TIP: A common fault with schedules is the lack of lead-in and lag-time on tasks. In practice it is very unusual for one task to be completed exactly on time and another to start the day after. Allow time for setting up the task (lead-in) and time for rework/acceptance when the task has been completed (lag-time). This approach when applied to individual tasks will build contingency into the planning process. Projects that include IS/IT elements will require periods for acceptance testing, both from an application and end user perspective. Training requirements and other tasks impact on roll-out and will also need to be included in the plan. Date 17/04/2007 Page 25 of 82

When planning, set an end date for the project and then plan tasks into the timeline. Remember to clearly annotate dependencies, milestones and stage boundaries. Project Plan The Project Plan is a mandatory plan that provides a statement of how and when a project s objectives are to be achieved, by showing all major products, activities and resources required on project. It provides the business case with planned project costs and identifies the management stages and other major control points. It is used by the project Board as a baseline against which to monitor project progress and costs stage by stage. Template for a Project Plan, see Project Plan Stage Plan What is a stage? A stage is a distinct unit of project implementation. Each stage has a defined set of products, outcomes or activities. Each stage will have a finite lifespan, dedicated resources and an appropriate organisational structure. The number of stages within a project will be governed by its complexity. The completion of each stage is determined by the satisfactory completion of the agreed products. Stage Boundaries will reflect the nature of the project and may be chosen according to one or more of the following criteria: The sequence of delivery of products The grouping of products into self-consistent sets The natural decision points for feedback and review. Common to all projects are the Start-up and Justification stages, which cover the planning and definition of the project. The Justification stage concludes in an operational review before committing resources to further work. The first two stages of the South Norfolk method for project management provide surety; these stages may seem somewhat tedious, as there is a fair amount of investigation and paperwork to be completed to support the project. It is worth bearing in mind that if an individual went to a commercial bank to borrow money for a project, the Business Manager of the bank would, almost without exception, ask for all the background documentation (and possibly more) completed in the Start-up and Justification stages. It is reasonable therefore that we adopt a similar and robust approach with public funds. Some specialist tasks may span one or more stages of a project. Project managers need to manage Stage Boundaries and obtain sign-off before they continue to the Date 17/04/2007 Page 26 of 82

next stage. The number and length of subsequent stages will vary from project to project. Template for Stage Plan, see Stage Plan. Administration Efficient administration is the backbone of any project. It is essential that administration processes are documented and agreed with line managers and administration support staff before the project starts. Project documentation must always be part of a back-up regime. A key element of project tracking and audit is to establish a strict regime of project administration in the earliest stages of the Project Lifecycle. This will ensure that the development of the project and all subsequent changes are tracked and recorded for audit purposes. The accurate recording of any project will provide useful and vital information during the Project Lifecycle and Post-project Review The administration service controls the following areas: The Project Library This should include: 1) All standard document templates (Risk Log, Issue Log, Lessons Learned Log). 2) Specialist documents (change control, configuration management, version control). 3) Correspondence (letters, emails, and any externally produced documents. Include a cross-reference process where applicable). 4) Quality (product descriptions and any quality checks carried out). Below is a suggested file structure for projects: Project File: Overview (project name, project (and programme) manager(s), project sponsor, client(s), wards affected Organisation (Org Chart and signed Terms of Reference and job definitions) Contact List (telephone numbers email etc) Communication Plan Project Approach Change Control Process Plans (includes all versions) Product breakdown structure Product flow diagrams (clearly identified, date, version number, option appraisal, scope and resources) Business Case (all versions signed off and working copies) Risk Log (all correctly versioned include scheduled updates) Issue Log (all correctly versioned include scheduled updates) Lessons Learned Log (all correctly versioned include scheduled updates) Date 17/04/2007 Page 27 of 82

Copies of Project Initiation and Closure (mandatory and signed!) Details of post-project review Any follow on actions or recommendations after project closure Correspondence for the project. Stage File for each stage: Organisation for stage (may be different from project organisation, contractors etc) Details of all team members All work assignments (Work Packages) Change Control Process (may be same as in project file) Performance assessments (Critical Success Factors) Plans (stage, team, exception, if any) Any mid-stage assessments End stage assessment report Any progress updates Daily diary/log Meeting notes Discussion groups Consultations/Process Any stage actions Correspondence for the stage Any other documents stage-related. Specialist Files: Configuration management Off-specification Any specialist correspondence. Quality Note: Should be cross-referenced to a specific task or event. This filing system should allow an audit check of quality of work. There is one quality file which runs throughout the project. All product descriptions (detailed) Details quality teams (stage and overall) Quality checks (invitations and meetings) Quality Log Results Action List. Date 17/04/2007 Page 28 of 82

General Administration It is essential that administration systems are tailored and the processes documented for each project. In some cases it may be appropriate for project team staff to carry out some of the administration tasks. Version Control All projects produce paperwork either as a hard copy or electronically. To keep track of documentation, strict version control must be established at the beginning of the Project Lifecycle. From 1 January 2005, South Norfolk Council has been subject to the Freedom of Information Act. The maintenance of project documentation in a logical format will assist in the provision of responses under the Act. TIP: Include the file path in the project documentation footer. A suggested method is as follows: First Draft 0.01 Use a zero then a decimal point to inform the reader that this version has not yet been signed off. Latest Approved Version 1.00 Use a whole number to inform the reader that this is a signed-off version. The highest whole number is the latest signed-off version. Working Copy 1.06 Use a whole number and a decimal to inform the reader that version 1 is the latest signed-off version and that there have been 6 subsequent drafts. If version 1.06 were to be signed off, it would become version 2.0. The document history would then read as follows: 0.01.1.00.1.01.1.02.1.03 2.00.2.01. This process for version numbering and continuity is considered best practice. Project Documentation: History Revision History Date of this revision: Date of next revision: Date 17/04/2007 Page 29 of 82

Revision Previous revision date Summary of Changes Changes date marked First issue Approvals This document requires the following approvals. Signed approval forms are filed in the Management section of the project files. Name Signature Title Date of Issue Version Distribution This document has been distributed to Name Title Date of Issue Version Date 17/04/2007 Page 30 of 82

5. Project Justification The Justification Stage The next stage in the Project Lifecycle is the Justification Stage. There are some basic principles that should be applied to all projects: A project is a finite process with a start and an end All parties involved in the project must be clear about the Project Objectives and what their individual responsibilities are to achieving those objectives The project must be well managed in order to achieve a successful outcome. Once initial approval has been given to proceed with the project the next stage is to move the project forward towards the stage where the project can be delivered. Before that there are various issues which must be addressed and three more gateway steps to pass through. The first one is to develop the PID into a full-blown business case, the second is ensuring the Council s procurement strategy is being adhered to and thirdly that the solution meets all the council s criteria and a commitment is made to deliver the specified project The Project Definition Workshop Justification is a critical stage in the Project Lifecycle and mistakes and omissions at this point can cause serious problems further down the line. Indeed, design and definition shortcomings are a prime source of project failure, especially for IS/IT projects. Experience has shown the value of holding a Project Definition Workshop (PDW) to underpin the Justification Stage. The PDW is a peer group meeting of stakeholders and relevant managers to help the Project Sponsor and Project Manager define the project, set objectives, define benefits, and consider resources, costs and risks. The PDW will clarify these aspects, albeit at a high level, and provide a sound basis for the more detailed definition for assembling the Business Case. The PDW meeting will address the following areas: Benefits Scope Goals and objectives Assumptions and risk Costs and resources Project organisation Immediate next actions. Date 17/04/2007 Page 31 of 82