South Norfolk Council Project Management Handbook

Transcription

1 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

2 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

3 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

4 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? SOUTH NORFOLK COUNCIL (SNC) GATEWAY PROCESS WHAT IS A PROGRAMME? WHAT IS A PROJECT? WHAT IS PROJECT MANAGEMENT AND WHY DO WE DO IT? WHAT ARE THE BENEFITS FROM PROJECT MANAGEMENT? PROJECT LIFE CYCLE FURTHER CHANGES TO THIS DOCUMENT Project Organisation ORGANISATIONAL STRUCTURE PROJECT SPONSOR SPECIALIST ADVISOR PROJECT MANAGER PROJECT BOARD PROJECT OFFICER (SENIOR USER) PROJECT TEAM PROGRAMME MANAGER PROGRAMME BOARD Project Start-up THE PROJECT MANDATE START-UP OF A PROJECT THE PROJECT INITIATION DOCUMENT (PID) PROJECT APPROACH QUALITY PLANNING THE RISK LOG THE ISSUE LOG PLANNING PROJECT PLAN STAGE PLAN ADMINISTRATION GENERAL ADMINISTRATION Project Justification THE JUSTIFICATION STAGE Date 17/04/2007 Page 4 of 82

5 THE PROJECT DEFINITION WORKSHOP PROJECT INITIATION AND PLANNING THE LESSONS LEARNED LOG STAKEHOLDER ANALYSIS AND STRATEGY BUSINESS ANALYSIS, PROCESS MAPPING AND BUSINESS PROCESS RE ENGINEERING THE COMMUNICATION PLAN PREPARATION OF THE BUSINESS CASE PROCUREMENT INVOLVEMENT OF E-GOVERNMENT EVALUATION AND SELCTION INVESTMENT DECISION Delivery of a Project PROJECT DELIVERY FINANCIAL TRACKING CONTRACTS CONTROLLING A STAGE THE WORK PACKAGE MANAGING STAGE BOUNDARIES CHANGE CONTROL FITNESS FOR PURPOSE Project Review PROJECT REVIEWS ATTENDANCE AT REVIEWS DISTRIBUTION OF MINUTES/ACTIONS FREQUENCY OF REVIEWS DOCUMENTATION REQUIRED FOR REVIEWS FORMAT OF PROJECT REVIEWS ESCALATION AND SUPPORT Project Reporting PROJECT MANAGEMENT REPORTING PROGRESS REPORT FINACIAL REPORTING EXCEPTION REPORT END STAGE REPORT LESSONS LEARNED REPORT END PROJECT REPORT FOLLOW-ON ACTION RECOMMENDATIONS Closing a Project Jargon Buster Templates Date 17/04/2007 Page 5 of 82

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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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: [email protected] Date 17/04/2007 Page 14 of 82

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23 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

24 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

25 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

26 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

27 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, s, 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 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

28 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

29 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: 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

30 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

31 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

32 Project Initiation and Planning In addition to a Project Definition Workshop, the project manager must hold an internal meeting to ensure that the appropriate level of administrative support is available. Relevant service units and external partners must be briefed on the project and the likely requirements that the project manager will place on their organisation. The project manager should not wait until all the requirement schedules and other information are known before holding this meeting, as the experience and advice that the various service units can offer will be invaluable in the initial planning stages. It is also useful for these service units to get early sight of projects to allow them to schedule their resources efficiently and provide effective support to the project manager. The Lessons Learned Log Project managers should maintain the Lessons Learned Log throughout the Project Lifecycle. All lessons learned must be logged and reviewed as an element of the Stage Boundary process. All staff involved in the project should be encouraged to tell the project manager about any lessons learned so that they can be added to the Lessons Learned Log. Complete the Lessons Learned Report at the conclusion of the project using the Lessons Learned Log as reference. Lessons learned fall into a number of categories and are realised throughout the Project Lifecycle. They can be good or bad and provide valuable reference information for similar projects in the future. Project managers and management teams sometimes have difficulty with the idea of noting down mistakes and how they were rectified because they feel there is a stigma attached to the process. It is very unlikely that there will not be any mistakes on a project and the lessons learned from one project may prevent the same mistakes being made on subsequent projects. Do not underestimate the value of completing this document. Remember that it is used to compile the Lessons Learned Report, which is required at Project Closure. Learn: What went well? What went badly? Create a Legacy: Of knowledge, reference material and techniques to assist subsequent projects To influence the scope and approach of other, current projects, where necessary. Template for Lessons Learned Log, see Annex 2. Date 17/04/2007 Page 32 of 82

33 Stakeholder Analysis and Strategy It is vital to the success of any project that the stakeholders are recognised and managed correctly. Stakeholders may be an individual, a group, or a subgroup that has an interest in the project. As the project progresses and the focus of the work changes then the stakeholders may also change. It is important to review current stakeholders at regular intervals throughout the Project Lifecycle. A common criticism of many projects is that stakeholders were not kept informed of changes and developments, and that this more often than not has a negative impact on the project. It may be that not all stakeholders will support the changes brought about by the project. A key part of this analysis is to recognise the stakeholders level of commitment to the project and any objections that they may have to the changes brought about by the project. Examples of some typical stakeholders: Users Customers Employees Residents and Community Groups Suppliers and subcontractors Trade unions Pressure groups General public Regulators (health and safety, central government) Project team member Any key individuals Human resources Finance and Property Legal Communications Team Members E-Government IS/IT Trainer The above is a very general list and it is suggested that the project manager involves the entire project team in the recognition of stakeholders at a dedicated meeting on the subject. Once all the stakeholders have been recognised, the next part of the process is to assess each stakeholder s level of support and commitment, and in some cases, their resistance to the project. When this has been done, the project team can form a strategy for changing the status of certain stakeholders to maximise stakeholder support. The analysis of stakeholders is a useful exercise as it will form the basis of the Communication Plan for the project. Date 17/04/2007 Page 33 of 82

34 Business Analysis, Process Mapping and Business Process Reengineering Another vital success to any project as well as understanding what is to be achieved is an understanding of how things are being done currently. As focusing on analysing key tasks and processes will help inform the requirements specification stage. E- Government team can help with facilitating this stage but it is essential that a critical look is made at what we do? Why we do it? And do we still need to do it in the future? Just because we have always done something that way does not necessarily mean it is the best way of doing this nor that we really need to do it at all since over time processes and outputs are produced which aren t real requirements anymore. This process cannot be skipped within any project where an existing process or product is being replaced or changed. Even for something we have never done before business analysis must be undertaken to address how we will perform the tasks associated with the project. The Communication Plan It is of the utmost importance to establish a Communication Plan in the early stages of any project. This plan will be included within the Business Case. Planning communications Good communications can help to make your project a success. Successful communication is about sharing the right information, at the right time, with the right audience. A Communications Plan will structure how to do this in the most efficient and effective way. You will need to prepare a Communication Plan as soon as possible when you are planning any project. This will mean that an appropriate budget can be allocated, and you will have time to use the broadest possible range of options to achieve your objectives. You will need to review your Communication Plan regularly, at least at each End Stage of the project. During the lifecycle of the project, the stakeholders recognised at project start will change as the project progresses. The Communications Team will advise the project manager on how he/she should write the Communication Plan. It is always a good idea to review communications at the end of a project: what worked well, what didn t work, and what would you do differently next time? This should be recorded, and will provide useful learning for future projects and to share with other projects and services to encourage best practice. Date 17/04/2007 Page 34 of 82

35 Template for the Communication Plan, see Communication Plan For a more detailed view on the role of communication see Appendix 6 Preparation of the Business Case The Business Case explains the reason for undertaking the project and the benefits that the project will bring. It should identify measurable Critical Success Factors which can be measured to show that the project achieved (and keeps achieving) its planned benefits. The project manager should outline in the Business Case all benefits justifying the project including financial savings, improvements to current working practices and provision of new services. When preparing the Business Case, include any benefits to other parts of the Council. The Business Case is the main input to SNC Gateway process Step 2 Business Justification review. The business case must be presented to the appropriate Programme Board so that they can probe the business justification in some depth. This critical appraisal is intended to really test whether the benefits can justify the costs. It tests the internal logic of the project as well as its external place and probes whether it can actually be delivered with the resources bid for, and looks at the time allowed for the project and tries to check that against available resources, not just money but critical skills and management effort. It is critical that no project proceeds to implementation without having this thorough appraisal. The project manager should review and if necessary update the Business Case at specific points within the Project Lifecycle. These review points are usually at Stage End and form part of the process of Managing Stage Boundaries. The Business Case reviews and amendments are critical to understanding the viability of the project throughout the Project Lifecycle. Template for Business Case, see Business Case Procurement Not all projects will require the procurement of a new business or service but when they do they must follow the council s procurement guidelines. See Procurement Strategy Advice on contract issues can be found in the rules for financial governance and part 4 of the contract standing orders Date 17/04/2007 Page 35 of 82

36 See Financial Governance and Contract Standing orders Where products or services are not to be provided internally, you will need to procure them from an external supplier. The objectives of the procurement process are to identify the supplier who will best satisfy the business requirements and to establish a contract that will control this delivery. Further advice on and a guide to procurement issues is available from the Procurement Officer (Nigel Beesley) in Financial Services. Advice on contract issues is available from the Legal team in Democratic Services. The decision(s) on procurement forms the basis of Gateway Step 3 Procurement Review Whatever is tendered for, whole life costing should be used in the evaluation of proposals and tenders. There clearly must be a set of questions on procedures and processes around procurement and it is important that this is challenged and tested and not merely drifted into, particularly as we are increasingly looking at partnership approaches. A separate procurement Gateway is a standard requirement of our process. Normally the Procurement Review should be handled by the Programme Board (AMG, ESG or AHG) A fuller description for IS/IT procurement issues is included in Appendix 1 Involvement of E-Government Many projects will require the provision or replacement of Information systems/information Technology (IS/IT) systems. Do not underestimate the impact that employing new IS/IT systems will have on staff in terms of training and implementation. The Head of E-Government has overall responsibility to approve any expenditure on IS/IT projects and these will fall within the remit of the E-Services programme board. Therefore any project that includes an IS/IT element must ensure that the E- Government section is consulted at an early stage and must be included in the Communication Plan. Involvement of E-Government at this early stage will ensure that any IS/IT elements are in line with the Council s technical strategy and overall infrastructure. The e-government Interoperability Framework (e-gif) sets out the technical policies and standards that ensure the interoperability of information and communication technology (ICT) systems used to deliver electronic services. Interoperability is a term for how two or more systems or components can exchange and use information (see Appendix 2). As long as the systems can understand the data being passed between them, by using common data formats, it does not matter Date 17/04/2007 Page 36 of 82

37 what hardware or software makes up those systems. Sharing of information must meet the ISO 27001/BS 7999 standard. Further advice on these matters can be obtained from E-Government. Evaluation and selction There are some things which are necessary for an effective procurement, that are undertaken during an evaluation and selection process. This may be for a new product, a new service or a new process; however, unless you know what you REALLY want to achieve you cannot evaluate it properly against potential solutions and potential suppliers. Not all these steps will be required for all projects but most will if there is anew product or service being implemented. Functional Requirements Specification Some projects will require the purchase of new products or services. You must put in place processes to handle this procurement efficiently. A definition of what you need should be contained in a Functional Requirements Specification (FRS). This will communicate your needs to potential suppliers. The author of the FRS may be the project manager or someone else appointed to undertake this task, and must include one of the Council s E-Government specialists when new IS/IT equipment or software is being procured. The author of the FRS must liaise with appropriate representatives of the users affected, technical agencies, corporate agencies and other stakeholders. The FRS must be agreed and signed off by relevant personnel. These will include: Representative(s) from affected user department(s) Representative(s) from E-Government (who may already be sitting on the project board or project team). The specification will address the following areas: Functional requirements what the product must provide to users Technical requirements how the product must complement or interface with existing technical infrastructure and/or other software systems Support and maintenance how suppliers must handle faults and support users Documentation and training needed to support implementation and subsequent operation of the system Upgrades and developments specifying potential future requirements. For example, to comply with legal requirements Implementation detailing specific needs for the introduction of the system. For example, realigning users to new processes, migrating data from old systems. Date 17/04/2007 Page 37 of 82

38 E-Government can advise you on the format and contents of an FRS. They also maintain a definition of the Council s agreed technology infrastructure. Invitation to Tender Once the function requirements specification has been signed off by the project board we then proceed to invite suppliers to tender for the supply of a solution. There are detailed guidelines around tendering in the Rules for Financial Governance. See Financial Governance Tender Evaluation Report The purpose of this report is to document the results of the evaluation of tenders provided by suppliers. The detailed evaluation will focus on the precise requirements defined in the FRS and the response made by suppliers. To achieve this, the FRS document must first be converted into a series of questions defining business needs. Since the points in these questions will have a varying degree of importance, the evaluation team will agree a suitable weighting to be applied to each question. A possible weighting model is included in Appendix 1. This tender evaluation report should be approved by the Project team and Board. It may help to eliminate some supplier who either didn t meet the requirements to produce a short list for further investigation. Site visits and demonstrations Another means of evaluating the suitability of a product or service is to consult and/or visit other sites where the product/service is already in use. These should preferably be with another local authority. For certain products it will be possible to arrange for the suppliers to come and demo their products to key users, if this process is part of the evaluation and selection process then each supplier must be treated similarly. They must all be given the same information; what they will be expected to demonstrate, (this should cover all the key benefits) and how much time they will have to do their demonstration. It is also a good idea to allow suppliers some free time to demo additional features of their product(s) which may not have been covered in the original tender Recommendation At the end of the evaluation and selection process the Project Manager with the agreement of the Project Team will be able to make a recommendation to the project Board on the most suitable solution and or supplier. In order for the project Board to support the project s team recommendation they must have access to all relevant information including any draft contracts (approved in principle by the procurement officer and legal Services), up to date expenditure so far, the cost to deliver the solution being and maintained into the future. Date 17/04/2007 Page 38 of 82

39 Once the project Board has approved the recommendation the decision most be approved by the appropriate programme board as part of Gateway Step 4. Investment decision By now enough information should be available to deliver the project. The Business Case must be frozen, as this will provide a baseline for comparison against the actual work undertaken and show how much the project has deviated from the initial plan. It will also show whether these deviations were controlled through the Change Management Procedure. Other project documentation should now be updated prior to commencing the delivery stage of the project. Before anymore work is done though or commitments made to resources the project must undertake Gateway Step 4 Investment Decision This is the go/no go decision taken after the results of tender evaluation are to hand. Financial regulations and section of the contract standing orders set out the process. It is vital that the Board considers whole life costing of the proposal. Once the investment decision has been made we are into the execution phase of the project. Date 17/04/2007 Page 39 of 82

40 Project Delivery 6. Delivery of a Project Once Gateway Step 4 has been passed the project can now start to be implemented, this may be done in one or several stages. The project manager will manage all aspects and report regularly to the project sponsor and project board on progress. Any changes to the plan (outside tolerance limits) will need to be approved as the project progresses. Before any change, stage or deliverable goes live it must be signed off as fit for purpose by the appropriate head of Service. Delivering a project involves many skills and include Financial Tracking It is the responsibility of the project manager to track expenditure on the project. Financial tracking on a project is a forecast of expenditure against the plan. Forecasting expenditure to a realistic timescale in line with the Project Plan is necessary to support bids for funding. Inaccurate forecasting will invariably lead to an under spend or an overspend on the programme as a whole. This will in turn impact on the council s ability to plan its expenditure and cash flow. Financial reporting should occur at every project board and the monthly progress reports include some high level financial reporting. All projects must: 1) Forecast expenditure for the financial year. 2) Forecast the expenditure for the complete Project Lifecycle. 3) Track the project expenditure to date. 4) Produce a detailed up-to-date commentary on a monthly basis. If requested, this should include information on the forecast of expenditure. Contracts Any draft contract needs to e finalised and this make take some time as discussions take place. The rules of financial governance still apply and before any contract is formally signed off for and on behalf of the Council, it must be approved by the Procurement Officer and Legal Services. After any contract is signed, the project manager should obtain a copy and store it in the project library. The master copy will be held centrally in the Council. It is important that the project manager reads and understands this document so that the correct level of service is maintained. If the client wishes to make any significant changes to the service as described in the contract, this should be agreed via the Change Control Process. Date 17/04/2007 Page 40 of 82

41 Controlling a Stage Once the Justification Stage has been completed and approved, the project manager can focus on the delivery of the next stage of the plan. Within the first delivery stage there will be a number of defined tasks that the project manager should group into Work Packages. Some Work Packages may span one or more stages of a project. There may be a requirement to update the detailed Stage Plan and in some cases, the High Level Plan, as the stage progresses. The project manager should also concentrate effort on resource utilisation. Maximising the usage of available resources is key to the success of the stage. The project manager s responsibilities for controlling a stage can be summarised under the following headings: Delivering the right products to specification in the correct sequence Providing direction to and utilisation of resources Monitoring progress against plans Updating plans where necessary Tracking expenditure Managing any deviations from plan Managing/escalating the cost and impact of any change requests Ensuring all stakeholders are kept informed of progress in line with the Communication Plan Following agreed reporting procedure for Highlight Reports Raising an Exception Report if the stage looks likely to exceed tolerances on cost or time Managing and updating the Risk Log Managing and updating the Issue Log Managing and updating the Lessons Learned Log. The Work Package A Work Package can be a single task or a group of tasks that are usually assigned to a team manager or team leader. The issuing of a Work Package is a simple way of assigning and managing work on a project. The project manager is responsible for ensuring that all Work Packages are delivered to the agreed quality criteria and within the time and cost specified. The process of assigning Work Packages to contractors, individuals and team leaders will vary according to the size and complexity of the deliverable/s. In part it will reflect the relationship between the project manager and the person/s concerned. In its simplest form, the Work Package may be a verbal instruction. In most instances it will involve a written agreement or formal contract of work. Date 17/04/2007 Page 41 of 82

42 TIP: Time spent in clearly defining Work Packages is never wasted. A verbal instruction is, of course, always open to interpretation, and what the project manager thinks will be delivered and what the person/s thinks they will receive may not be the same. As a general rule, it is always preferable to complete a written Work Package. When the work is subject to either a Service Level Agreement (SLA) or a contract, the completion of a formal Work Package, which has been agreed by the project manager and the supplier, is mandatory. The project manager should pay particular attention to any quality measures required in the Work Package completion. There may also be a requirement to involve others in quality checks on completion. Template for Work Package, see Work Package. Managing Stage Boundaries Stages will vary in duration throughout the lifecycle of a project. Splitting a project into stages provides a means of management and control. Stage Boundaries must be annotated on the High Level Plan and will provide decision points for the project board to: 1) Approve completion of the stage. 2) Update project documentation (including Risk Log). 3) Review the budget against revised forecast. 4) Set tolerances on the next stage. 5) Authorise commencement of the next stage. 6) Obtain board level sign-off for the detailed Stage Plan of the next stage. By involving the project board at these key decision points, their involvement is planned and the best use is made of their valuable time. In order to maintain the continuity of the Project Stage Boundary, meetings are usually planned two weeks before stage completion. Managing the Stage Boundary will involve the development of the Next Stage plan and budget in preparation for the approval of the project board. The subsequent stage may also involve a change of personnel to complete the tasks identified within that stage. The following documentation will also require revisiting and updating as required. 1) Quality Plan 2) Communication Plan 3) Business Case 4) Project Approach 5) Issue Log 6) Risk Log 7) Lessons Learned Log. In essence, the main objectives of the Stage Boundary are as follows: Date 17/04/2007 Page 42 of 82

43 To assure the project board that all products/outputs specific to that stage have been completed as defined To provide the project board with enough information to allow a decision to be made on the continued viability of the project To ensure that the project manager receives authority to begin the next stage within agreed tolerances (usually time and cost). Managing the Stage Boundary is a simple process that can be completed quickly if the preparation is thorough. Change Control During the lifecycle of the project, changes will occur to the original plan and specification of products. It is important to establish an approval process and to track these changes whether they receive approval or not. A project without a clear and well-defined change control process will inevitably experience difficulties both during the lifecycle of the project and with any subsequent audit process. It will be impossible to prove whether a change has been authorised at the correct level. The main cause of failure on a number of projects is lack of or a poorly defined and communicated Change Control Process. All changes should be requested, costed and recorded outside any parameters set by the project manager. By instigating this process, the project manager can assess the impact that changes will have on the project as a whole from a cost and time perspective. The change/s will provide valuable information at the Post-project Review Meeting when final outcomes are compared against the original Project Initiation Document. The project manager should brief anyone who is involved in completing a Work Package as part of the project on the Change Process. Levels of change authorisation should be known from the outset of each stage. Any Change Request must include a detailed description of the proposed change and its impact on the project as a whole, or in respect to time, cost and quality. Some changes could have significant impact and may require programme board approval. It is for the project manager to determine the level of authorisation required based on the tolerances agreed at the previous Stage Boundary. Once approved, the Work Package should be updated and reissued. Template for Change Request, see Annex 1. Fitness for purpose Before any stage is completed which will mean releasing change into the live environment the appropriate head of service must sign off that they accept the change being implemented, this is Gateway Step 5 Readiness for Service. Date 17/04/2007 Page 43 of 82

44 7. Project Review Project Reviews Keeping updated project documentation will assist in dealing with any enquiries made under the Freedom of Information Act. 1. Stage Reviews (Managing Stage Boundaries) Stage Review dates are agreed with the project board and the project manager and form the basis for Managing Stage Boundaries (see Section 6). Each stage of the project is identified from the Project Plan. Approximately two weeks prior to the end of each stage, a review is annotated on the plan (usually designated as a milestone). This enables the project manager to set all Stage Review dates at the start of the project. If there is project slippage or the two-week-rule for Stage Review is not appropriate, the project manager will inform the project board and set new dates for the review following the same guidelines. 2. Exception Reviews Few projects go exactly to plan and remain within tolerances throughout the Project Lifecycle. At Stage Boundary Reviews, tolerances will have been set against time and cost for the next stage. If the project manager recognises that unavoidable changes will exceed the agreed tolerance on either time or cost, they should raise an Exception Report and forward this to the project and programme boards. Project Managers and Project Boards do not need to seek Programme Board approval for small scale changes where the project may be delayed by a few days or overspend its budget by a few pounds. The Project boards will be allowed to vary their approved costs and delivery date as long as: - a) The overall increase on the latest approved budget does not exceed 5% for projects with a budget over 250,000 or 10% for a budget less than 250,000 b) The delivery date is within 1 month of the latest approved project end date It is vital that such changes allow sufficient time to manage them efficiently. Problem areas will be annotated on the project manager s monthly report. The action of raising an Exception Report will result in an Exception Review at the earliest opportunity. A new plan and strategy for that stage will be required and tabled by the project manager. This will then be discussed at the review. Some early warning of problem areas may have been annotated on the monthly reports as an issue or risk. The project manager must not wait until the monthly report is due if a problem occurs that will exceed tolerances prior to the report due date. Template for Exception Report, see Exception Report. Date 17/04/2007 Page 44 of 82

45 3. Post-project Review Main question: When do I start the Post-project Review? Answer: The day you initiate the project Post-project Reviews will generally be convened two to three weeks after a project has been officially signed off as closed. It is important to plan well in advance for this review as many of the key players will start to move onto other things before official closure. The Post-project Review date must feature on the plan and as many of the key players and stakeholders as possible must be invited to attend. The review will analyse the Project Initiation Document (frozen when agreed in the Start-up Stage) against actual progression and final outcomes. The value of a Post-project Review must not be underestimated. It will assist in completing a comprehensive and integrated Lessons Learned Log that will be used as a reference for future projects. The format of Post-project Reviews is not described in detail in this document as approaches will vary according to the project manager and the type of project. The CPG can advise on an appropriate approach. 4. Review Responsibilities The project manager is responsible for convening all Stage and Post-project Reviews and sending relevant invites and documentation to those attending. It is the responsibility of the project manager to accommodate all reviews and to book a suitable room. Attendance at Reviews The following personnel are considered the minimum attendance at all reviews: Project board Project Sponsor Project manager Senior user and senior supplier Client. Note: Other personnel may be invited to attend as agreed by the project board and the project manager. Distribution of Minutes/Actions The project manager is responsible for ensuring minutes are taken and actions noted. Minutes should be distributed to: Date 17/04/2007 Page 45 of 82

46 All attendees Project library Any other persons/organisations recognised in the Communication Plan. The distribution of minutes should take place no later than two working days after the completion of any review. Frequency of Reviews The frequency of reviews will depend on the type and complexity of the project. Reviews will generally be more frequent at the start of a project where stages are shorter and most problem areas are encountered. As a project progresses and becomes more stable (as in a roll-out stage) reviews are more likely to be targeted to check that all actions are progressing and to review Risk, Issue and Lessons Learned Logs. An Exception Report from the project manager to the programme board will trigger an Exception Review as soon as possible. The project manager must table a revised plan and updated budget forecast at the Exception Review. The programme board will decide against this plan whether to approve additional funding, allow slippage or instigate premature closure of the project. Documentation Required for Reviews It is the responsibility of the project manager to ensure the following documentation is prepared and available for any review. The project board will identify documentation to be reviewed from the list below after consultation with the project manager: Project Initiation Document Contract and/or Service Level Agreements (SLAs) Latest monthly Report Financial Tracking Current Project Plan (High Level and Stage) Risk Log (all risks to be allocated ownership and properly costed) Issue Log Lessons Learned Log Change Control Log (or documentation) Organisation charts Product Flow diagram Product description Communication Plan. Standard templates are annexed to this document. Date 17/04/2007 Page 46 of 82

47 Format of Project Reviews The project manager should give a short brief on how the project is progressing with a focus on any risks/issues. The relevant documentation should then be reviewed in this context. The review process should be very thorough. Preparation is vital to ensure a short but effective review. Escalation and Support There will be times on any project when a risk or issue needs to be escalated. All project logs (Issue, Risk and Lessons Learned) should be reviewed and updated at regular intervals throughout the Project Lifecycle and, as a minimum, just prior to a Stage Review. If a risk/issue requires escalation, the project manager should notify the project board as soon as possible. Valuable time would be lost if the project manager waits until a formal progress report is required. If a risk/issue is escalated, it is usually because it cannot be managed at the level of authority initially allocated. The escalation of a risk/issue will normally result in ownership being transferred either to someone in higher authority or with specialist skills. It is important that the new owner of the risk/issue fully understands its history and the potential impact and financial implications. Resolution of the risk/issue may also be time-critical and this should also be conveyed to the new owner. Date 17/04/2007 Page 47 of 82

48 8. Project Reporting Project Management Reporting Completing reports on any project is an essential requirement to ensure that all stakeholders are kept informed about the progression of the project throughout its Project Lifecycle. The provision of accurate reports by the project manager will assist the decision process of the project board. The standard format of these reports is described in this document. As a part of the Communication Plan, the project manager should identify the various types of report and their due date. Progress Report The (normally monthly) Progress Report is submitted to the project board and programme boards and for certain projects (classified as A or B projects) there is also a summary report to cabinet on a quarterly basis. The report is particularly useful where stages are long in duration and a considerable amount of time has elapsed between Stage Boundaries. Template for Progress Report, see Project Report form. Finacial Reporting A summary of the current state of the finance is included within the progress report whoever a more comprehensive financial record should be kept to account for all expenditure during the project. Quarterly expenditure reports on A and B projects are reported monthly to cabinet and project Managers will be expected to update the accountants with up to date information on expenditure and planned expenditure over the remaining lifetime of the project. Template for Project Financial Report, see Annex 3. Date 17/04/2007 Page 48 of 82

49 Exception Report The Exception Report is submitted to the project board as soon as the project manager recognises that the stage cannot be completed within a reasonable tolerance of the plan submitted. Template for Exception Report, see Exception Report. End Stage Report The purpose of the End Stage Report is to give a summary of progress to date and the overall project situation. It also gives sufficient information to ask for a project board decision to accept the work and costs to stage end and to approve the forecast for the next stage. If stages are planned correctly this will involve the board at the correct time to make key decisions. The report therefore should be sufficiently detailed to allow them to do this. Template for End Stage Report, see End Stage Report. Lessons Learned Report The Lessons Learned Report is generated for the project board at the closing down phase of the project. The purpose of the Lessons Learned Report is to pass on any lessons that can be usefully applied to other projects. Information in this report will include what went well, what went badly, and any recommendations for the enhancement or modification of the Project Management standards. Template for the Lessons Learned Report, see Lesson Learned Report. End Project Report The project manager is required to submit an End Project Report to the project board (who may pass it on to the programme board). The report will detail how well the project has performed against its Project Initiation Document, including the original planned cost, schedule and tolerances, revised Business Case, and final version of the Project Plan. Be truthful Be factual Ensure there is evidence to support the report Avoid naming individuals Remember commercial confidentiality. Date 17/04/2007 Page 49 of 82

50 Template for End Project Report, see End of Project Report. Follow-on Action Recommendations The purpose of the Follow-on Action Recommendations is to pass details of unfinished work or potential product modifications to the group charged with future support of the final product. Template for Follow-on Action Recommendations, see Follow on report. Date 17/04/2007 Page 50 of 82

51 9. Closing a Project At the end of a project it is important to hold a Post Implementation Review Meeting to determine how successful the project has been against initial expectations. This is the final stage in the SNC Gateway process Gateway Step 6 - PIR The project manager will schedule an internal Project Closure Meeting (End of Project Review) a few weeks after the project has been completed. It is also a good idea to hold a Client Closure Meeting prior to the full Project Closure Meeting to consolidate feedback from the client on how they viewed the project in its progression and conclusion. The project manager may also give valuable feedback to the client on how their side of the project went (tactfully of course). A Client Closure Meeting allows the project manager to formally close the project and set the scene for future co-operation. The Lessons Learned Log should be made available to project staff and as a source of reference for anyone within the Council. After a review of the content, the client may also be given a copy of the Lessons Learned Log. For capital projects there is a requirement for reporting project outcomes to the Capital Programme Group at Gateway Step 6 (practical completion). This report should include the handover plan, any update to the Asset Register, recommendation for follow-on action, performance review and lessons learned. Some of the main questions, which the Post-project Review should answer: Did we get what we said we wanted? Did we get what we actually needed? Can we see the difference between the two? Can we explain the difference between the two? Do we understand how this will influence our project management behaviour in the future? A major consideration of closing the project should be the communication of successes and recognition for those involved in the delivery. Date 17/04/2007 Page 51 of 82

52 10. Jargon Buster Like most jargon, it seems pointless until you start working with it, at which point it becomes a very useful way of describing the many people, situations and processes which almost every project will involve. Bespoke A product or an element of a product that is developed for a specific task and is not available off the shelf. Be aware that bespoke products, or elements of a product, are more expensive due to the development time/cost involved. Change Request Process Once the project has a tightly defined scope, and the project manager has signed up to deliver that scope within a specific time and/or budget, the last thing they want is for the scope to change, either by adding new things or by redefining the requirements. A Change Request Process is a sensible, ordered approach to making sure that the project team are not culpable for overruns (time and cost) caused by this kind of change. The basic process goes like this: 1) A change is requested, defining a variation to the original functional specification and setting out perceived benefits arising from that change. 2) The team analyses the detailed changes and conducts an impact analysis, highlighting the expected changes in costs and risks. 3) The project manager weighs the changes in costs/risks against the potential benefits and decides whether or not to accept the change. The project manager may escalate the change to the project board for their decision. 4) If the change is accepted, the project has a new scope, costs, timescales and risks, and the project team may no longer be expected to meet the old ones. Communication Plan The project is changing the world fantastic! The project team must inform key stakeholders about it. Like all good things, this will take planning and effort. Constraints Senior managers can (and often do) ask for the moon on a stick. But it s important that the project manager makes them aware of the limitations of time, budget, technical strategy and other aspects that will impinge on project delivery. Critical Success Factor (CSF ) How will we know if we have succeeded? These are measurable statements which can be checked as matter of fact after the project is completed to show we have achieved the goals of the project (e.g. average time per claim reduced by 10%) Date 17/04/2007 Page 52 of 82

53 . Deliverable/product (output) The outcome from a specific task or piece of work is the output of what you're doing. It should be something obvious and tangible on site this might be foundations or a site structure. For the project manager it might be the Project Plan. Dependency Something one task needs from another task before it can be started or completed. Freedom of Information (FOI) A Government Act that came fully into force on 1 January There are two rights under the Act: a) To be told if information is held. b) To have that information supplied. The FOI Act applies to project documentation. Compliance with the South Norfolk Methodology for project management will keep the relevant documentation for the project in a logical order to assist requests for information under the Act. Justification Stage This is the stage of the project where you do the initial planning, get the go-ahead and (most importantly) get the budget to allow you to deliver the rest of the project. Managing down risk Once a risk has been recognised, categorised and costed, it is the responsibility of the owner of the risk to manage down its impact. The Risk Log will provide a means of recording efforts to manage down any risks. Milestone Milestone planning is an extremely useful planning method when you don t have all the timescales required for the plan. It s solely based on dependencies and allows you to set out a plan's skeleton. Product Flow Diagram A diagram that shows products for delivery produced in a logical sequence. Establishing this sequence will give a view of what products may be produced concurrently and what products have a dependency on other products. It is about getting everything in the right order. Project Closure Notice Date 17/04/2007 Page 53 of 82

54 The Project Closure Notice is mandatory and is the official notification that the project is closed to completion. The notice will be completed either when a project closes on completion or on early closure subsequent to a project board decision. Project Initiation Document (PID) The Project Initiation Document is the terms of reference for the project and is frozen once signed. It contains the key parts of what, how, when and why the project will run. For capital projects, you won t get the go-ahead or a budget without it. It is required to enable effective scrutiny on project organisation and delivery. Project Lifecycle All projects must have a beginning and end date. The Project Lifecycle encompasses all the time, tasks and activities between these two points including the Post-project Review. It does not include any follow-on actions which may be recommended at the Post-project Review. Project Sponsor Question: What s in a name? Answer: In this case everything! The person is a senior, responsible officer who owns the project. The term used to describe the senior person or the head of the project board. This title is specific to the public sector and is recognised by the Government and the National Audit Commission. It equates to the project executive in the private sector. This is a new term compliant with central government and public sector guidelines and replaces project sponsor Re-profiling project expenditure When there is forecast slippage on a project in any current year, the project manager must consider the impact on any subsequent years. This consideration must be before the next year s budget is set (usually March/April). The project manager may submit a budget re-profile request through the departmental finance officer (usually no later than mid-january); this may involve re-profiling the slippage over a number of subsequent years in the Project Lifecycle. If this re-profiling exercise is not undertaken, the slippage rolls over into the following and subsequent years and is not managed in the best interest of the project. Resources Everything needed to complete the project, but particularly people and funds. Scope What the project has agreed to deliver. Once signed off, defend it with your life. Scope-creep What happens when people have bright ideas for minor improvements? Great ideas they may be, but if they re not in the agreed scope, project managers should not undertake the changes without a change request being accepted. Otherwise the Date 17/04/2007 Page 54 of 82

55 work ends up being substantially more than agreed, yet budget and timescales haven t changed. Service Level Agreement (SLA) A contractually enforceable agreement on the quality of service provided. The point of this is that you can make firm plans around whatever service level you've agreed, knowing that even if you don t get that level of service, you re going to get compensated (and perhaps more importantly, not blamed) for slippages. Service offerings The services offered by a department or an external supplier usually outlined as a bullet- pointed list with a very brief description. Sign-off Sign-off is a Council requirement at the completion of a stage, project or deliverable. The users/funding bodies haven t made any complaints so far, so you think you've delivered what you re being funded to deliver. But how do you know? When you ask the funding bodies to pay, how do they know? When, in a year s time, the users start complaining about your work and that you didn t deliver against their requirements, how do you prove otherwise if they sue? Get things signed off! Slippage What you get when you start running over time or budget. Too many late lunches and the project slips. As one great project manager put it: How does a project get six months late? One hour at a time. The Capital Programme Group and Central Finance have undertaken an exercise to categorise slippage on a project-by-project basis. Some slippage is unavoidable as in delay in the decision to spend by central government. See Re-profiling project expenditure. Stakeholder Management Projects are made more difficult when stakeholders have different agendas, goals and priorities. As well as managing the project, a big part of a project manager s role is keeping the stakeholders aligned with each other and with the project team. Include all stakeholders in your Communication Plan. Stakeholders Anyone who has a valid interest in your project. If your project affects someone else, they re a stakeholder. Some stakeholders will have direct input into your project some will even have sign-off while others will simply have a representation of their interests. Start-up Stage (SU) Triggered from the Project Mandate, this is the stage at which information is assimilated to make a rational decision regarding the viability of the project before additional resources are committed. Date 17/04/2007 Page 55 of 82

56 11. Templates This section includes templates you should use in the Project Management Process. The Council requires project managers to use these templates to provide an accurate record of information. The completion of project templates will also assist with the retrieval of project information if required by a request under the Freedom of Information Act that came into force on 1 January Annex 1: Change Request REQUEST FOR CHANGE Project: RFC number: RFCnnn Raised by: Date: Description of changes needed: Assessments: Details Completed By: Products requiring change (Please list) Effort required(days) Risks Timescales Additional cost Project Manager s Decision: Exception - refer to Accept - Accept - Reject Board Deferred Approved Action Approved by: Date: Project Board s Decision (if required): Accept - Deferred Accept - Approved Reject Action Approved by: Date: Date 17/04/2007 Page 56 of 82

57 Annex 2: Lessons Learned Log Purpose The Lessons Learned Log provides an opportunity to record any lessons learned, either positive or negative, that can be usefully applied to other projects. This information is normally best represented in a table for ease of reference. Use your word processor to build a table using the text below as column headings. Date Description Recommendation Descriptions may include: What went well, what went badly What was lacking Notes on the performance of specialist methods and tools used Abnormal events causing deviation from objectives Effort required to deliver outcomes. Date 17/04/2007 Page 57 of 82

58 Annex 3: Finance proforma Purpose of Document To include a full breakdown of costs over a period of years, the headings are IT related but could be for any revenue or capital costs Example spreadsheet layout at O:\E-Services\EServices Budget proforma.xls Date 17/04/2007 Page 58 of 82

59 12. Appendices Appendix 1: IS/ITProcurement Guidelines The contents of this appendix are related to the procurement and implementation of an IS/IT product, e.g. new software. They compliment the general guidelines contained in the main document. All procurement, tendering and contract must follow the council published rules see Procurement Strategy Rules of Financial Governance Contract Standing Orders IS/IT: Procurement The project manager must identify the appropriate procurement route to be followed. This will depend on the value of the products being purchased, and will range from a single competitive bid through quotations and tenders, possibly involving compliance with EC directives. Detailed information can be found in the guide produced by the Corporate Procurement Service. Corporate Technology should be consulted at the procurement stage to determine whether preferred suppliers or economies of purchasing scale are available. The project board must agree the chosen option before approval is sought from the appropriate authorities. Tender process This will typically include the following actions: Draw up an Invitation to Tender (ITT), which provides procedural guidance, instructions to tenderers and general conditions and information. This will complement the Functional Requirements Specification (FRS) produced from the Project Definition Phase Place the advertisement in the appropriate media, depending on the value of the tender Register expressions of interest from potential suppliers Issue a supplier short-listing questionnaire to reduce potential suppliers to a manageable number Establish this shortlist by assessing the responses against an objective evaluation model. Aim to short-list between three and six potential suppliers. Notify those suppliers who were unsuccessful Date 17/04/2007 Page 59 of 82

60 Dispatch the ITT and FRS documents to the selected suppliers, providing the fixed time to respond as defined in the ITT. Respond to queries as received but make sure that any clarification or further information is made to all suppliers equally Register receipt of tender responses as they arrive Evaluate the tenders by inspecting and scoring the tenders submitted by suppliers. This process will use a predefined objective method that lists product requirements and assigns weighted scores depending on how well a supplier complies with those requirements Where appropriate, Corporate Technology should be consulted on the technical aspects of the tender responses Evaluation can include visits to sites where the products are in use, and it may be possible to gain extra information from other agencies or specialist bodies Produce an evaluation report for the project board. This summarises the tender evaluation and provides a recommendation. It will also detail any other issues that need to be brought to the attention of the board The board will then confirm the successful supplier and award the contract. Note that drawing up and agreeing the contract can be a lengthy process Notify the unsuccessful candidates. IS/IT: Tender evaluation report The purpose of this report is to document the results of the evaluation of tenders provided by suppliers. The detailed evaluation will focus on the precise requirements defined in the FRS and the response made by suppliers. To achieve this, the FRS document must first be converted to a series of questions defining business needs. Since the points in these questions will have a varying degree of importance, the evaluation team will agree a suitable weighting to be applied to each question. A possible weighting model could be: Weighting 1 Nice to have 2 Desirable 3 Very desirable 4 Important 5 Critical Description of requirement The response to each question will then be scored. A possible scoring model could be: Score Meaning 0 Not met/no response 1 Possibly met, i.e. response unclear or claims to meet but no detail provided 2 Mostly met (even if by enhancement or option) 3 Fully met (even if by enhancement or option) The total score for each question will be the raw score multiplied by the weighting factor. Date 17/04/2007 Page 60 of 82

61 The detailed evaluation the scoring of the FRS responses will be one criterion to be considered by the project board or by a subgroup set up to select a supplier. A fuller criteria list, some of which may involve an element of subjective analysis, might include: Quality of response to the ITT and FRS Functionality compared to FRS (scoring process) Hardware and related software requirements and network issues. Conformance with the Council s IS/IT infrastructure Costs and potential for subsequent cost savings Financial stability and viability of company Reference site visits Suppliers experiences in a similar environment Independent consultant s report Confidence in supplier/proposal Implementation timescales Ability of suppliers to provide technical assistance, training and support. IS/IT: Implementation Introduction This section relates to the implementation of IS/IT system software and hardware. The required effort will obviously depend upon the scale and scope of the system being introduced, but the following information will provide an overview of the issues to be considered. Acceptance testing Before a system can be used in a live environment, it must be fully tested by users to ensure that it meets all needs detailed in the business requirements/functional Requirements Specification (FRS). A strategy must be devised that will address the scope, objectives, method and resources to be used during acceptance testing. It will also include the criteria for acceptance of the system. Areas to be covered are: System testing: testing the initial installation after delivery, which may include hardware, peripherals, network connectivity, system operating software and databases User acceptance testing: testing the application software against predefined business requirements. This will involve users in setting up test scripts that provide a means to objectively assess whether or not the system delivers what is required. Training A training strategy is needed to address the delivery of the training requirements identified in the FRS. The project manager will assess the best way to provide the required training given the available options. The project manager must consider the number of staff to Date 17/04/2007 Page 61 of 82

62 be trained, the variety of training needs, whether training can be phased or needs to be handled en masse, how training must fit around normal working practices, and available funds. System roll-out The project manager must assess the best way to roll out the live system to all affected users and how to migrate any current data onto the new system. This will include negotiation with users and suppliers, Corporate Technology, and any other agencies affected by the roll-out. An important consideration is whether implementation can be phased in piecemeal (so that old and new systems are operating at the same time) or whether it needs to be accomplished as a big bang process. Each has advantages and disadvantages that should be carefully considered before coming to a conclusion. The project manager will also need to consider risks and the impact of problems occurring, together with possible contingency plans to overcome any difficulties. People issues Implementation should not be seen as a purely mechanical process. Successful implementation is best achieved by also considering staff issues. For example: Management should display visible commitment to the project, and promote the benefits that the project will bring Consider impact on staff and keep them involved at each step. Deal with any Human Resources issues Establish sufficient resources to cover the extra demands made by implementation. Allow contingency for interruptions to work. Date 17/04/2007 Page 62 of 82

63 Appendix 2: e-government Interoperability Framework What is the e-government Interoperability Framework? The e-government Interoperability Framework (e-gif) sets out the technical policies and standards that ensure the interoperability of information and communication technology systems used to deliver electronic services. Interoperability is a term for how two or more systems or components can exchange and use information. As long as the systems can understand the data being passed between them, by using common data formats, it does not matter what hardware or software makes up those systems. The e-gif consists of two parts. Part one is a document detailing the scope, management, implementation support and compliance policies for the framework 2. Part Two is the Technical Standards Catalogue that details the actual standards used by the e-gif 3. Part one is updated annually, and at the time of writing is at version 6.0. As Part Two (the Technical Standards Catalogue) is an online resource, it is updated more frequently and is currently at version 6.1, with a move to version 6.2 expected April/May The e-gif is managed by the e-government Unit of the Cabinet Office 4. How does the e-gif affect IS/IT procurement? Complying with the e-gif is mandated widely across the UK public sector because it helps build more sustainable and flexible IS/IT systems, making for efficiency and effectiveness gains in the immediate and longer terms as systems are upgraded or replaced. Developing systems that comply with the e-gif increasingly allows information to flow seamlessly across the public sector and provide citizens and businesses with better access to government services. In addition, by adopting Internet and World Wide Web standards, the Framework aligns government with the rest of IS/IT industry and serves as a basis for reducing the costs and risks associated with carrying out major IS/IT projects. The e-gif is a living document (see section 1 above). As the latest version of the e- GIF could change during the lifetime of an IS/IT project, the project manager should clearly state which version of the e-gif they expect a system to comply with when writing tenders and associated project documentation. 2 e-government Interoperability Framework version 6.0: 3 e-gif Technical Standards Catalogue: 4 e-government Unit of the Cabinet Office: Date 17/04/2007 Page 63 of 82

64 The project manager should make use of the Register of e-gif Accredited Organisations 5 to identify vendors who can develop, deliver and/or support e-gif compliant solutions. The project manager should also ensure that they make use of the e-gif Compliance Assessment Service 6 as a means of gathering and providing evidence that a system complies with the e-gif. The evaluation reports from the e-gif Compliance Assessment Service, either produced internally by the project staff or supplied by the IS/IT vendor delivering the system, can be used as evidence of e-gif compliance to the Senior Responsible Owner. Note that the e-gif is not a rubber stamp. It is a framework of technical policies and standards. As such, both the Head of E-Government and the IS/IT vendor delivering the solution must reach an agreement as to the level of e-gif compliance that the solution must meet. 5 The Register of e-gif Accredited Organisations: 6 e-gif Compliance Assessment Service: Date 17/04/2007 Page 64 of 82

65 Appendix 3: The South Norfolk project gateway process The Gateway Process consists of a number of sequential reviews carried out at key decision points in the life of a project. There are six Gateways, 4 before the change comes on line and 2 looking at service implementation and the confirmation (or otherwise) of operational benefits so that lessons can be learned. The Gateway process is intended to provide assurance and support for the Council and project sponsors in discharging their obligation to achieve the Council s aims by: Achievement of more realistic time and cost targets for projects. Improvement of knowledge and skills among the Council staff through participation in review processes. Provision of advice and guidance to project teams by fellow practitioners. Deployment of the best available skills and experience on the project. Understanding of the project status and the issues involved by all stakeholders. Assurance that the project can progress to the next stage of development or implementation and achieve its aims. The six steps are outlined below Gateway 1 Strategic assessment Before embarking on any change project which will involve more than a few persondays of work effort, a Project Initiation Document (PID) is required. Dependent upon the size and significance of the change and whether or not it will impact on other services, the PID will need to be signed off by the relevant Head of Service or by CMT or SMT before any Head of Service can make a bid for capital or revenue, so that SMT/CMT can be confident that the project really does fit well with the Council s strategic aims. The acceptance of a PID does not guarantee a place in the programme merely that the project is in the right ballpark. A PID may ask for resources to do research for Gateways 1, 2 and 3. No project can be considered for funding without its PID being signed off at the appropriate level. For a place in the Capital Programme, a PID has to be scored by Cabinet members and SMT. Gateway 2 Business Justification Review Our project methodology calls for the preparation of Project Definition Document (PDD) or Business Case where a group of people, including those who are not directly involved with the project or part of its line management, can probe the business justification in some depth. This critical appraisal is intended to really test whether the benefits can justify the costs. It tests the internal logic of the project as well as its external place and probes whether it can actually be delivered with the resources bid for, and looks at the time allowed for the project and tries to check Date 17/04/2007 Page 65 of 82

66 that against available resources, not just money but critical skills and management effort. It is critical that no project proceeds to implementation without having this thorough appraisal. It is also desirable that the PDD/Business Case is completed before the Capital Programme is finalised. However, it has been argued that the time needed for a thorough PDD could not be justified if there was no likelihood of a place in the Capital Programme. So, although it is desirable to complete the review of the PDD/Business Case before the capital programme is finalised, it is permissible that the business justification Gateway can be either before or after the Capital Programme is defined. Gateway 3 Procurement Review Whether the review of the PDD/Business Case precedes or follows the Capital Programme, no steps can be taken to commit real resource to the project without careful thought about procurement. Procurement is at the heart of some of our projects e.g. the future of the leisure centres but it also features in many other projects. The question of whether or not to build it ourselves has been more or less eliminated from our IS/IT procurement over the last few years, but it is still a question that should be asked. Advice on procurement is set out in the Procurement Strategy and the financial categories and requirements are set out in part 4 of contract standing orders. Whatever is tendered for, whole life costing should be used in the evaluation of proposals and tenders. There clearly must be a set of questions on procedures and processes around procurement and it is important that this is challenged and tested and not merely drifted into, particularly as we are increasingly looking at partnership approaches. A separate procurement Gateway is a standard requirement of our process. Normally the Procurement Review should be handled by the Programme Board (AMG, EGG or AHG) but the conclusions must be summarised in Gateway 3. Gateway 4 Investment Decision This is the go/no go decision taken after the results of tender evaluation are to hand. Financial regulations and section of the contract standing orders set out the process. It is vital that the Board considers whole life costing of the proposal. Once the investment decision has been made we are into the execution phase of the project. Gateway 5 Readiness for service decision This is a specific stage that has always been recognised in some South Norfolk projects, but not in others. For example, before our new IS/IT system is allowed to take over the business there is always an extensive programme of pre-defined tests on dummy data. There is similar testing and certification of electrical installations before they are put into service. Signing off the practical completion of a building project should also be subject to testing. So should organisational Date 17/04/2007 Page 66 of 82

67 change projects. Certainly they should be signed off as operationally ready before the new arrangements are put permanently in place. There should always be an explicit readiness for service Gateway Gateway 6 Post Implemnetation / Project Review The Council has now adopted the practice of post implementation project review, which usually takes place a few months after implementation has begun. This is proving a useful aspect of the South Norfolk process because it helps with learning from past experience and is a key element in continuous improvement Date 17/04/2007 Page 67 of 82

68 Appendix 4: Risk Management A risk is a threat that an event or action will adversely affect the project ability to achieve the Council s objectives. The Council has a standard procedure for documenting and managing risks. More details are on the intranet in the staff information area. Any project is likely to involve a wide range of risks and a great deal of effort could be expended in trying to manage risks which turn out not to be important. So the Council has adopted a consistent way of assessing the possible impact of a risk event in terms of safety, financial loss, service disruption, reputation, environment and many other factors. There is a five point scale ranging from catastrophic to insignificant. Of course, a risk which would be catastrophic for the project may not be catastrophic for the Council and it is important that the project manager thinks on a Council scale if her/his approach is to be consistent with risk management across the Council. Thus, a risk to a project which would involve a financial loss of more than half a million pounds would be catastrophic and justify a score of 5. Also deserving a 5 would be if the project went wrong to the extent that there was daily national media interest in it for five or more days or if the project led to multiple cases of injuries or illnesses that could be life threatening or cause long term disability, hospitalisation or death. The full scoring schema is set out below: 5 Catastrophic 1. Safety incident multiple cases of injuries or illnesses that cause or could reasonably be fatal, life threatening or cause long-term disability or hospitalisation. 2. Financial loss 500, Service disruption (unplanned) SNC not able to provide any service cover for 5 working days + 4. SNC unable to access I.T. for 5 working days + 5. Reputation daily national media interest in a single issue for 5 days Environment major or widespread physical damage requiring assistance of central government. 7. Other (but spell out fully in the Consequence box). Tick Significant 1. Safety incident injuries or illnesses that cause or could reasonably be fatal, life threatening or cause long term disability or hospitalisation. 2. Financial loss 50,001 up to 500, Service disruption (unplanned) whole service not able to function for 5 working days Service unable to access I.T. for 5 working days + 5. Reputation national media interest in a single issue. 6. Environment physical damage requiring special budgetary provision to rectify. 7. Other (but spell out fully in the Consequence box). Tick Moderate 1. Safety incident injuries/ or illnesses that result in an 'over 3 day' injury, major injury or hospitalisation 2. Financial loss 5001 up to 50, Service disruption (unplanned) team unable to function for 5 working days + 4. Team unable to access I.T. for 5 working days + 5. Reputation: e.g. ombudsman complaint justified; negative local media interest in single issue 6. Environment short term physical damage at a single location 7. Other (but spell out fully in the Consequence box). Date 17/04/2007 Page 68 of 82

69 Tick Minor 1. Safety incident Minor injuries including those that require first aid and result in lost time 2. Financial loss 251 up to Service disruption (unplanned) team unable to provide any cover for one day 4. Team unable to access I.T. 5. Reputation ombudsman complaint made, hostile letter to local newspaper 6. Environment easily remedied damage 7. Other (but spell out fully in the Consequence box). Tick Insignificant 1. Safety incident - Minor injuries or illnesses including those that may require first aid but do not result in 'lost time' 2. Financial loss loss up to Service disruption (unplanned) individual staff off work 4. Individual staff unable to access I.T. 5. Reputation unfounded letter of complaint 6. Environment no obvious damage arising from incident 7. Other (but spell out fully in the Consequence box). Tick Whilst a significant potentially catastrophic risk needs serious attention and consideration, if the chances of it happening are negligible it needs must less consideration than if it is possible or probable. The Council uses a five point scale for assessing likelihood and this is set out below. 5 Probable >50% over 5 Years. Or >1 in 2 Chance in 5 Years 4 Possible >5% over 5 Years. Or >1 in 20 Chance in 5 Years 3 Unlikely >0.5% over 5 Years. Or >1 in 200 Chance in 5 Years 2 Rare >0.05% over 5 Years. Or >1 in 2,000 Chance in 5 Years 1 Negligible >0.005% over 5 Years. Or >1 in 20,000 Chance in 5 Years Risk should never be ignored but the amount of effort you invest to manage each particular risk will depend on a combination of its likelihood and consequences. In the Risk Management Action Plan, for each risk you should identify the existing controls to reduce the likelihood and actions that should be taken to further reduce the likelihood including the date for their completion and the person responsible. Similarly you should enter into the Risk Management Action Plan the contingency plan if the risk were to occur and any other actions to further reduce the consequence including the date by which they should be completed and the person responsible. A standard proforma in Word format for creating these Risk Management Action Plans can be downloaded from the intranet together with detailed notes on how it should be completed. Date 17/04/2007 Page 69 of 82

70 Appendix 5: Produicng a Gantt Chart To successfully manage a project, you will need a way of recording what has to be done and when it has to be done by. From this manual, it is clear that most significant South Norfolk Council projects will have at least six phases but in some of these phases, particularly Phase 5, there is a need to distinguish in much greater detail the specific activities and sequence in which they should happen. The first step in this process is to create a Work Breakdown Structure (WBS). The Work Breakdown Structure (WBS) The Work Breakdown Structure (WBS) is a list of the tasks necessary to achieve the objective of the project. The most difficult part of this is to decide how big to make these activities. A really good way of creating the WBS is to get your Project Team together to brainstorm what work is needed and how to arrange it. A useful principle is to break the work down as far as is necessary to effectively manage it and no further. To effectively manage the work, you will need to be able to decide whether it is on target and so identify any problems early enough to do something about it. It s often helpful if the tasks are small enough so that you can easily describe how complete it is - e.g. not started, just started, half finished, finished - rather than having to estimate complicated percentages - e.g. 65% completed. Once you ve got a clear idea of all the tasks involved, you may want to aggregate some of them into Work Packages. These are mini projects that are often given to a specific individual or work teams or even outsourced to a contractor. Make work packages that are logical - if it s an aggregation of disparate tasks, it can be very difficult for the person undertaking the work package to understand what is required. Sequencing Once you ve got your Work Breakdown Structure, you can work out the logical sequence for the tasks involved - in what order tasks have to happen. Some people find it easier to draw this relationship pictorially (see Project modelling below) while others find it easier to list predecessor and successor tasks for each task. A really good way of doing this is to get together as many of your proposed project team as possible, put each task on a Post It, and together, stick them on the wall in the right order. This gives lots of opportunity for brainstorming on how to do the project, and helps your team understand why things happen in the order they do. This will allow you to re-order easily where necessary and to spot conflicts. Often, the relationship between tasks is expressed as dependencies i.e. before you can start Task B, you may have to be sure that Task A is complete. Date 17/04/2007 Page 70 of 82

71 The Gantt Chart Once you have established a logical sequence, you can plot the tasks against time to create a Gantt chart. To do this, you will need to calculate the expected duration of tasks and their associated buffers. (See Calculating task durations and buffers below.) Clearly you will have to define the phases of the project to match the Gateways, but to help monitor how well the project is going and to make sure that you don t miss important dates, you ll probably want to put in some more milestones. These represent important points in the life of the project - for example, they could be when you have to report to the Project Board, or when you will finish major elements of work. Too few milestones and your project can feel like it s dragging on, while too many milestones can distract your attention from the work. The Gantt chart will undoubtedly change several times during the life of the Project. It is important to make sure that those involved always have the current version and so remember to include a version number or issue date to be able to check. Keep a copy of the Gantt chart you started with (the baseline ) so that you can assess whether the project is slipping, and when finished, you can review your estimates against the actual dates to improve for next time. Calculating Task Durations An essential part of plotting tasks against time is to estimate how long each task will take. The best way of doing this is to talk to the people who will be responsible for doing each particular task. If several people will be involved, talk to each individually. Always bear in mind that there are emotional aspects to those predictions - some people will be apprehensive and over-estimate the time necessary, others will be seeking to impress and under-estimate. Try to get a range of opinions so that you can cross-check. Where possible, consider how long similar tasks undertaken in the past took, and consider any special factors (other work/holidays etc) that might affect the task duration. If you can t reach agreement on a realistic duration, try to break the task down further and estimate each individual part, aggregating them for the task duration. Don t be tempted to pad the task duration as insurance against problems. Be honest about task durations and make allowances through buffers. Buffers Buffers are the allowances (of time and cost) for problems and unforeseen circumstances. Even if your project had a perfectly smooth run, buffers would still be needed because some tasks cannot be precisely estimated. This applies particularly to innovative or partnership projects. Without buffers, your project is guaranteed to move away from your planned timescale very quickly. Buffers can be large or small. They can be used between tasks, between groups of tasks or work packages, or before or after milestones. The essential characteristic of a buffer is that it is explicitly recognised, calculated and placed carefully by the Date 17/04/2007 Page 71 of 82

72 project manager, and serves a purpose that benefits the project. This distinguishes it from padding, which is usually hidden in a task duration, arbitrary in length and placement, usually added by those who will be undertaking the work, and which only helps them. Buffers help to ensure that a project stays within time and cost. Padding makes a project unnecessarily long or expensive. Calculating the size of buffers can be done in at least three ways: By risk: look at the risks associated with a particular task or group of tasks, and decide an appropriate buffer based on those risks. An example of this would be where a task depended on placing an advert in a weekly newspaper to be able to finish - an appropriate buffer might be one week in case the advert missed that edition. By experience: look at similar tasks undertaken previously and work out a buffer based on past delays. By formula: there are various formulas which can be used to calculate buffer size. Some are based on the length of preceding tasks. Some on the length of time between tasks. Choosing where to place a buffer is solely down to the project manager s skill and judgement. When deciding where to put a buffer, you may wish to consider the following: Multi-purpose: buffers which serve two or more streams of work. These can help keep projects together, which is vital if specialist resources are being used consecutively on several streams of work. If they are not needed because the work is going as planned, these cross project buffers can provide the opportunity for project team meetings/ get togethers. Holiday: arranging a buffer around a holiday period can be useful. Generally speaking, work tails off in the run-up to a major holiday period (such as Christmas) and takes a day or two to pick up again afterwards. Using this time as a buffer rather than a task period can recognise this fact of life, and boost project team morale. Transitional: before or after a major event can be a good place to put a buffer. Appropriate major events include work going out or coming back (such as when work is passed to or received back from an outside contractor), and milestones or meetings (giving extra time to prepare reports or write minutes). Putting Tasks Together Once you ve calculated task durations and buffers, you ll need to put them together on a timeline. This is either done by beginning from a given start date and assembling the tasks and buffers together in the correct sequence to work out the end date, or by beginning from a given end date and assembling tasks and buffers together in a reverse of the correct sequence in order to work out the start date. Date 17/04/2007 Page 72 of 82

73 As a general rule, you should aim to start each task as soon as possible. Sometimes a task has a period before it can start (a lead in ) and a period after it has finished before the next task can start (a lag ). A good example of this is building the foundations for a house where, depending on demand, you may have to wait for concrete to be delivered and after it is poured, you may have to wait for it to dry before the next phase of building can start. Identifying the Critical Path Each task has an earliest possible time it can start within the overall sequence of tasks in the project. It also has a latest time that it can possibly start if the finish of the project is not to be delayed. The difference between these two dates represents the potential range of movement of the task (its float ). The size of the float for a task is very important. The larger the float, the more delay the task can absorb without affecting the rest of the project. Looking at the Gantt chart, it should be possible to identify one consecutive sequence of tasks running from the project start to its finish which has the smallest combined float. This is called the Critical Path. It s called the Critical Path because any delay that affects tasks in that sequence will potentially have an effect on the overall length of the project. Identifying the Critical Path within your project can be an indication of where to focus your attention. Remember that changing the timing or sequencing of tasks during the project may change the Critical Path. Project Modelling A project model is a way of showing your project pictorially. Its main use is when the project is being planned, but there will be a need to update the model the project and it can be used to help manage it, so you will probably find it useful to use some kind of project management software. If the project is very simple, a spreadsheet will do. If it is more complex, you will need specialist software and the preferred South Norfolk package is Microsoft Project. The method of creating a project model is closely linked with the processes described above so they are not going to be repeated here. Creating even a simple model takes time, so you will have to decide whether it is worth it for you. Some people just see projects through making lists no matter which model they try, they don t find pictorially representing their projects helpful. But the vast majority of the rest of us, however, find that drawing pictures of how the project is going to work is completely indispensable. To put these diagrams into context, we ll use a very simplified project to build your dream house. This project has the following major tasks (in no particular order): o Buy land o Hire builder o Put in foundations o Draw up plans o Build house o Create garden Date 17/04/2007 Page 73 of 82

74 o Move in o Get planning and building regs. consent o Design garden Our first job is to put these tasks into the right sequence (see Sequencing above). If you ve used the Post It method, you ll want to record that final layout before the Post its start to fall off the wall or the cleaner arrives. If you are using the South Norfolk preferred software, you will almost certainly find the Tracking Gantt chart the best place to start. Though it is more than 100 years old, the Tracking Gantt project diagram has achieved pre-eminence in project management. There are several different ways of drawing it but there are always certain common elements: A timeline along one axis this timescale can use any units you like (hours, days, weeks, months etc) but practicality and the need to keep it to a reasonable size usually dictates the units. Bars to represent how long the task is expected to take or work packages - the length of these bars reflects how long the task is expected to take, and their placement relative to the timescale reflects when they should start and stop. Lines to represent dependencies between tasks. Figure 1 The tracking Gantt shown above is a very common version, and is often the one generated by project management software. Traditionally, these tasks have the timelines running horizontally, but if you have a project with few tasks but long timelines, you may want to experiment with a vertical timeline. The vertical order in which you list tasks does not represent anything however, the dependency lines on a more complex project can appear very confused so it s worth spending a little time playing with the vertical order of tasks to get your chart as clear as possible. Simple charts often just have dependencies that run from the end of a predecessor task to the start of its successor task finish to start and the dependency line runs from the end of the predecessor task bar to the beginning of the successor task bar (Fig. 2 below). Date 17/04/2007 Page 74 of 82

75 Fig. 2 TASK 1 TASK 2 Fig. 3 TASK 1 TASK 2 Sometimes, you may want one task to start only when another has started a start to start dependency and this is drawn as in Fig. 3 above. Note that in Fig. 3 that the task bars are not vertically aligned (which would indicate on a conventional horizontal timeline that the tasks were to start at the same time) the dependency is one way and although Task 2 can t start until Task 1 starts, Task 1 can start even if Task 2 hasn t. Occasionally, you may want to make sure that a task isn t finished (and the team moved to the next task) until another task has actually finished a finish to finish dependency (see Fig. 4 below). Fig. 4 TASK 1 TASK 2 All charts have to begin somewhere. You have to decide whether you schedule forward from a fixed start date or backwards from a fixed finish date. You also have to decide whether you want all tasks to start as early as possible (which is the normal way to schedule) or as late as possible. With these decisions made (and particularly when using software), tasks can end up plotted on the tracking Gantt in surprising positions! ALWAYS look at the dependencies (not the timeline) to see the order in which tasks happen. Budgeting Part of planning project is to work out how much money you will need pay for it. There are two basic techniques: Top Down estimating the overall cost of the project in one guess. This may be all you can do at the PID stage and it may even be enough for very small projects, repetitive projects or those similar to previous projects. But certainly by the time you get to the project definition gateway, you will need to use Bottom Up budgeting. Bottom Up estimating the overall cost of the project by aggregating the estimated cost of all the individual tasks that make up that project. Date 17/04/2007 Page 75 of 82

76 Appendix 6: Role of communication The Communication Plan will set out how key stakeholders will be kept informed about, or engaged in, the project. An effective Communication Plan will: Identify audiences, plan how, when and what to communicate to them Schedule regular updates to ensure stakeholders are kept informed of the progress of the project from start to finish Positively influence perception about the project and ensure buy-in from stakeholders Minimise risks to the project by providing open, effective communication channels that are able to quickly identify and deal with problems that arise Build in evaluation to make sure that key decisions are agreed and to check that communication is working/getting through Focus and co-ordinate activity by communicating the benefits and aims of the project. It can also: Create a market (e.g. make sure a new service has customers) Build support and maintain partnerships with common aims/goals Increase understanding of the project s purpose and value after completion Ensure smooth implementation. When you communicate with any audience about your project, you are doing so on behalf of the Council. This section of the PM Handbook has been prepared as part of the Council s corporate communication strategy to improve the quality and consistency of communications exercises, both internal and external. You must consult with the communications team to get advice at an early stage of the project and before the PID is submitted What is the difference between a stakeholder and an audience? A stakeholder is an individual, a group, or a subgroup that has an interest in or is affected by the project. Key stakeholders will be those individuals, groups or subgroups that play an active part in the project and have an interest in its success or failure. Your audience is made up of stakeholders, but also individuals, groups and subgroups that may not have an interest in the project but may need to know about it. While your project stakeholders may well be one of your audiences, your audience for communication may well include people who are not strictly speaking stakeholders, i.e. those who do not have an interest in the success of your project. For example, if you are providing a service in competition with other providers, the public may not strictly speaking be stakeholders in your project (i.e. the success of Date 17/04/2007 Page 76 of 82

77 your initiative has no impact on them), but they will definitely form part of the audience you want to inform and influence. Creating the Communication Plan 1. Decide the scope of the Communication Plan You need to set the scope of communications identify what your plan will cover and what it won t. Remember that other stakeholders can, and probably will, have responsibility for some aspects of communications. The Communication Plan should detail all the activity that is needed and identify who is responsible for each activity. For example, the plan will probably not schedule the day-to-day communications between members of the project team to progress the project. However, it may include regular key meetings between project stakeholders, and will in itself be a useful central source of information on who knows what about the project. 2. Set communication objectives The starting point for any Communication Plan is thinking about what you are hoping to achieve. Do you simply want to inform people, or to bring about a change? You may want to influence opinions. Often you will be trying to do all of these across a variety of audiences. Objectives should be active. For example, the launch of a new service objectives may include: To improve the corporate reputation of the Council To inform potential service users about the new service, how to access it and the benefits it provides, i.e. to encourage use of the service To inform employees within the Council about the new service, and encourage them to promote it to suitable audiences To inform partner organisations To increase awareness of the diversity of the Council s services, and how we are investing in priorities identified by local people Prepare a set of clear objectives, and then discuss them with the core project team to make sure that they agree with them, or to see if they have any to add. 3. Identify your audiences This involves thinking of all the groups you might need to communicate with to achieve the agreed objectives. Different groups will be affected by the project in different ways, and may need different information or you may want them to take different action. Date 17/04/2007 Page 77 of 82

78 When communicating with larger audiences (for example, the general public), you need to identify specific groups to target, as this will affect the messages you communicate and the methods you use: Older people (over 50s) Children and Young People Service Users Parents and carers Residents Employees Main groups such as residents and employees will then usually break down into a variety of subgroups that will need to receive different levels of information depending on their role in the project, or the action you want them to take. When launching a new service, for example, audiences may include: External: Residents who already use another Council service Residents who don t use an existing service Residents who may need help to access the service Partner organisations. Internal: All Council employees Senior managers Staff running new service Staff already providing services for your potential users Trade union representatives if not Council employees. 4. Identify the key messages These are the main messages you want to get across to the main audience groups. When launching a new service, for example, key messages might include: Who the service is aimed at What the service is, including benefits When it will be available start date, and opening hours Why it has been created How to access it How other services may have changed in light of the new service coming online The Council is planning its services in response to local need Service standards/customer promise of new service. These messages will be explored in more detail when you come to put together your communications matrix. It is vital that your messages include the wider context: how does your project contribute to the Council s strategic aims; how does it reinforce our values? Remember that your project is a Council project, and research shows that the more Date 17/04/2007 Page 78 of 82

79 people understand about what the Council does, the better their perception of our services. When you are communicating to the outside world, especially residents, you should be talking to them in terms of what changes are being made by the Council (not just your service) and how people will be affected, rather than about projects, deadlines, services and targets. 5. Identify and review Good communications can minimise risks in a project. As soon as a Risk Log is prepared for the project, it should be reviewed to see if any of the risks identified could be minimised through better communication, e.g. risk of poor attendance at an event, risk of low response to consultation exercise. At the same time, there may be risks associated with communication to add to the Risk Log. For example: The lack of availability of key members of the project team to sign off communication materials The risk of a launch date moving after communication has taken place. In this case, the first risk can be minimised by agreeing in advance a core group of approvers, and identifying someone to whom approval is delegated if the stakeholder is unavailable. The second risk can be managed by avoiding a specific date in publicity (for example, using coming soon ) until a launch date is confirmed. Finally, remember that failure to communicate properly about a project is a major risk in itself. 6. Review your starting point current opinions and knowledge Different stakeholders will view the same project in very different ways. To work out how best to communicate with them you need to think about their current opinions and knowledge. Consider the key audiences. What do they think/feel/know at the moment? What would you like them to think or feel? Are their opinions justified? Are there gaps in their knowledge? Do they have enough information to make a decision or take an action? Do they believe the information they get; is there a job to be done to re establish trust and credibility? 7. Messages When deciding the key messages, consider: What does each audience need to know for your project to be a success? What do they want to know? (consider using customer groups to find out) What information do they need in order to access your service/take a certain action that would help you? Who can help you get your message across? Date 17/04/2007 Page 79 of 82

80 You must make sure that any communications you produce fall within house style and corporate identity guidelines. It also contains guidance on plain English, briefing and producing materials; it is available on e-link Also, when creating the communication channels to relay your messages, always try to include who is doing what, when, where and why. 8. Channels There are many methods of communicating with your audiences think what is appropriate and when. This can include: Meetings Managers/colleagues/peers Key individuals/opinion formers who can help spread your message Presentations/exhibitions Letters/flyers Website/intranet Written communications Project reports for key stakeholders involved in the delivery of the project Newsletters. Note: If you have a budget which allows you to produce bespoke communication materials especially for your project, think carefully about how you spend your money. It is best to look at all the existing communication channels that you can tap into to reach your audiences first, and save your resources to target the people you can t reach in any other way with specially produced materials. It also stops target audiences being bombarded with uncoordinated communication materials. If you are hoping to feature in newsletters that already exist, you must look for the news angle to your project: What aspect of it will affect most of the audience of that newsletter? What do people not already know? What will interest people? What is new or different about it? When choosing the methods, you need to consider: What do they already know? What communication has already been done? What is the best method of getting to the audience group? What will reach them in the right place and in the right frame of mind, i.e. when will they be receptive to your message? Who influences them? What do they already read? Who do they speak to? Who do they trust? What channels do we know work? Date 17/04/2007 Page 80 of 82

81 When considering methods, you also need to look at the budget you have; it may limit the methods you use to reach audiences. It is also important to prioritise your audiences so that you can focus your revenue on the most important audiences. 9. Timing The Communication Plan should include agreement on the frequency of communication and the most appropriate time for it to be received by the audience. The timing of communication is important messages need to be delivered at the right time. A sensitive message delivered by on a Friday afternoon will have a negative impact, and create an impression of trying to hide things or get out of facing the audience. Delivered face to face at a prearranged time, it will create a more favourable impression. Consider: How would I like to receive this message? When would be the best time to deliver this message, and when will your audience be most receptive to it? How long will it take to change opinions? Are there logical opportunities on the calendar to exploit? (e.g. events linked to your project) When do you need to start? When do attitudes need to be changed by? How many opportunities will there be to communicate while the project is topical? Remember that messages don t just have to be given once. There may be opportunities to communicate at a number of stages during a project when it is first conceived or funding is confirmed, at milestones during its progress, at launch, follow-ups on success or results etc. 10. Planned actions Using the information you have, what are you going to do, for whom, and how often? You should have a list of planned communication and you must allocate responsibility for each action remember that certain key stakeholders can be allocated responsibility to cascade information too. Illustrate in a table with headings. 11. Creating the communication matrix Date (or in early stages, approximate timing, i.e. prelaunch, launch, post-launch) Intended Audience Key Message Method/ Channel Responsibility Date 17/04/2007 Page 81 of 82

82 12. Evaluation (lessons learned) It is best practice to evaluate all communications after each phase of the project to measure how effective they have been. Evaluation is always forgotten and yet it is the key to successful cost effective communications. Plan for it and budget for it right at the start of the process. Then as evaluation happens, reshape your communications according to the results. Have the original objectives been achieved? There are a number of ways to evaluate: Formal research using market research companies, e.g. commission a survey, buy questions in existing surveys Informal research, e.g. phone calls to a small sample of your audience(s), asking for feedback Results or performance figures which coincide with communications activity. Date 17/04/2007 Page 82 of 82