At the core of the new Project Management System are six stages, linked to the new gateway approvals process:
1 Project Mandate
The first gateway consists simply of the appropriate Programme Board taking ‘ownership’ of a project idea, confirming that it is in line with their objectives and current priorities, and commissioning the next stage of project development work.
2 Project Proposal
This gateway consists of three key elements:
A more detailed review of the strategic fit to determine if the proposed project is the most effective way to meet the identified programme objectives.
A comprehensive review of the potential corporate considerations relevant to the proposed project.
A high level risk and impact assessment, on the basis of which a project “category” will be assigned, determining further approval and monitoring requirements.
3 Business Case
This gateway is where the detailed project planning work is undertaken, including appraisal of project delivery options; resource planning; developing budgets for project development and delivery (both revenue and capital); detailed risk and stakeholder analysis; and value for money assessment. Taken together, these elements comprise the business case for the project.
4 Project Start-Up
The project will be formally accepted onto the relevant programme on completion of gateway 3. However, it will not have authority to proceed to delivery until the Programme Manager confirms that all the necessary preparation for project delivery has been completed, using appropriate tools from the PMS. This will include establishing and briefing the project team and (where necessary) project board; setting up reporting templates; confirming the project scope and exclusions; and agreeing tolerances and change controls.
5 Project Delivery
As part of gateway 4, project stages and milestones will be identified which will enable stage reviews to be scheduled at appropriate points during project delivery. Again, the number and frequency of these will depend on the scale and complexity of the project. In addition to these scheduled reviews, project reviews can be requested at any point where there are concerns about progress, or where the project moves outside its agreed timescale or budget tolerances.
6 Project Close
Project close reviews should be carried out for completed projects to ensure benefits realisation plans and any post-contract management arrangements are in place and to capture lessons to be learned.
The gateways are based on experience from other Core Cities, in particular Manchester City Council, that an effective gateway process is the key to successful programme and project delivery. It ensures that each project or potential project (the first three stages are all part of the approvals process for potential new projects) has been properly evaluated, scoped, planned and delivered at key points in the project lifecycle.
With the increasing need for us to achieve more with less resource, it is essential that we properly define and evaluate each potential project in order to avoid wasting resources on:
The gateways are therefore mandatory, and Programme Managers will not accept onto their programme any project which has not been through the gateway process, meaning that the project has no authority to proceed. However, the gateway process (as with all elements of the new PMS) is designed to be scalable. Directorate Programme Managers will guide Project Managers to use only those PMS tools and templates which add value, depending on the type and nature of the project.
You need to keep in mind that you get out what you put in. This process will help you start your project off on the right foot, and stay that way.
The following sections provide further details of the requirements for each project stage and its associated gateway. The approvals each project needs will depend on which category it falls into (based on the risk and impact assessment which forms part of gateway 2), but the basic process is illustrated below.
(You can download this diagram as a word file here.)
The process is intended to be flexible in order to aid efficient project delivery, not to hinder it. Therefore, whilst all approvals need to be validated by the appropriate Board, the process can be carried out quickly if needed, with “fast-track” or interim approvals available as follows:
As with all elements of the PMS, if in doubt, consult your Directorate Programme Manager.
The starting point of any project is an idea. This can come from almost anywhere, for example:
Whatever the source of the idea, for it to become a project, an appropriate Programme Board need to take ‘ownership’ of the idea, confirming that it is in line with their objectives and current priorities and commissioning the next stage of project development work.
The first step is therefore to contact your Directorate Programme Manager with a brief description of your idea. They will firstly check the project database (to be developed as part of the new Project Management System) to see if we’ve been here before. However, even if a project has been considered previously and rejected, circumstances may have changed to make the project now a viable proposition.
The Directorate Programme Manager will then identify the relevant programme and work with that programme manager and programme director to review the project idea against the programme objectives, existing portfolio and performance, available resources and their alternative uses. This will then be presented to the Programme Board, who will make a decision as to whether the idea is worth pursuing.
Project ideas may also be generated within the programme itself, from a review of the current project portfolio against the programme’s objectives and targets to identify where new initiatives may be needed to address gaps or shortfalls in delivery.
The Gateway 1 template includes a section where you are asked to define what the project is which is seeking approval – e.g. a feasibility study, development of a funding bid, procurement of a capital project, service improvement initiative, etc. The template includes a drop-down menu to select options from, or you can define a new project type if needed. The reason for including this is that it’s important for the project approvals to be specific so that projects don’t automatically “roll on” e.g. from feasibility study to delivery with no formal approval or proper resourcing of the wider follow-on project. Completing this will also help people find your project in future if, for example, someone is looking for lessons learned from previous projects of this type.
Gateway 1 requires a short template to be completed for submission to the Programme Board. This won't usually need to be any more than a single side of A4.
The process to take a project through this first gateway is illustrated here.
This stage develops the mandate into a more detailed project proposal. The key elements are:
This includes many elements of the old NPMF2 Project Appraisal Form, but not the delivery and funding options appraisal. Instead, we are looking at this point for a more detailed review of the proposed project against alternative means of meeting the programme objectives. The reason for this is to enable the Programme Board to consider carefully whether this project is the most effective way to meet those objectives, before too much resource is used on detailed delivery planning.
The Project Proposal stage also involves a more comprehensive review of the potential corporate implications of the proposed project than the old PAF. This is to enable us to identify potential legal, financial, property issues, etc. at an early enough stage to influence the decision on whether and how to take the project forward. This expanded corporate considerations review will also ensure that opportunities to contribute to cross-cutting objectives such as equalities, community safety and sustainability are identified at the outset and can be properly built into the project, rather than “bolted on” at a later stage.
These sections will be reviewed by nominated corporate officers (via the Programme Manager), who will comment on whether the relevant issues have been properly considered, and make suggestions for how they might be taken forward. This also serves to get the project onto the “corporate radar” and to provide an early warning of potential input needed to the project at a later stage if it is approved.
This section is looking for a high level review of likely costs, complexity of funding, timescales, risks, and level of stakeholder involvement. The project category will be identified by applying a simple assessment matrix, and this will determine further approval and monitoring requirements:
There are further details on the Project Risk and Impact Assessment in the Toolkit section.
Gateway 2 requires the following form to be completed.
This stage is where the detailed project planning will be undertaken, including appraisal of project delivery options and assessment of value for money; development of the project plan or timetable; resource planning; risk and stakeholder analysis; and development of the project structure and governance. The Business Case for the project will be compiled from these elements.
The size and complexity of the Business Case will depend very much on the project type and category. For major capital projects, it will be quite extensive, and will need to include detailed financial and technical analysis. In other cases, a much simpler analysis will be enough to answer the two key questions which the Business Case needs to address:
The key elements of the Business Case are as follows:
For externally funded projects, the funding body (e.g. ERDF) may have a very detailed project proposal or evaluation template which includes all of the elements which need to be considered at this stage. Similarly, for Private Finance Initiative and Public Private Partnership schemes there are often prescribed formats for the Outline and Full Business Case which need to be prepared at specific points in the project approval process. There is obviously no benefit in duplicating this in a separate document for the Stage 3 Gateway. In this case, just use the sections in the Gateway 3 template to signpost to the relevant sections in that document.
This stage involves the final preparation for project delivery, using appropriate tools from the Project Management System in consultation with the Directorate Programme Manager. This will including establishing the project team and (where necessary, depending on the project category) project board; setting up reporting templates; and agreeing tolerances.
A good project plan, properly thought out and put together at this stage is going to be critical for effective delivery of the project. It is absolutely vital that there is a clear plan in place that sets out:
The final step is to assemble the Project Initiation Document (PID). The analysis and planning you have done during the previous project stages together with the final preparations as above will give you all of the information you need to include, so you can 'assemble' the PID instead of writing it. The PID is a suite of existing project documents, and the only new document needed will be a simple cover sheet signposting to where the relevant information and analysis is held.
The key components of the PID are:
Once you have brought all the elements of the Project Initiation Document together, this should be approved by your Directorate Programme Manager. We don’t think it’s necessary for Programme Boards to approve the PID, as this is very much a technical, process-related gateway. However, if the Directorate Programme Manager has concerns, for example about whether the resources needed to deliver the project have been secured, then they may escalate this to the Programme Board.
It’s important to emphasise that the process is intended to support the project manager in developing robust delivery and governance arrangements, not to cause unnecessary delays. It also protects project teams from pressure to deliver immediately without proper planning and resources – for example, where posts have not been backfilled or responsibilities reassigned as per the resource plan, and the project manager or other key members of the project team are therefore carrying all of their previous workload in addition to their project role. It will obviously be important for the process to be flexible and responsive, for example to enable us to respond quickly to funding opportunities or to meet urgent requirements. However, there are numerous examples of projects from both public and private sector organisations where costs have increased significantly due to poor project planning and inadequate resourcing.
Gateway 4, as with all the gateways, is therefore mandatory. In future, this may be linked to the project being allocated a cost code. An amendment to the Council’s Financial Regulations has also been proposed to include a requirement to pass this gateway before committing any expenditure relating to the project.
The PID should then be “frozen” or archived to use as a baseline. At key points throughout the project (particularly at stage reviews), you will then be able to compare the project’s performance against the PID to check that is still viable, worthwhile and deliverable.
After all the effort of defining your project, and taking it through the series of approvals, this is when you actually get to deliver the plan!
How you manage the project on a day to day basis will depend on all sorts of factors like your own style of management, the relationship you have with members of your team (e.g. do you line manage any of the team, or are they from a different area of the authority, or a different organisation?), whether you have a Project Board, and so on. However, there are a number of things that you need to keep on top of and inevitably there are some processes and associated documents to keep up to date. These include:
Advice, tools and techniques to help you with these are provided in the toolkit section.
The rest of this section provides information on the following topics:
A key principle of the PMS is managing by exception. As the Project Manager, you have been trusted to deliver your project on time, within budget and to the right quality. If everything is going to plan, or at least within the tolerances that you’ve agreed with the Programme or Project Board, there is no need to take up more of their time than is needed. However, if there are problems or issues that you can’t resolve, or if your tolerances are under threat, then they should be involved
You will still need regular contact with the Project Director (or other senior accountable officer), so that you are able to access the support you need to deliver the project.
Another aspect of managing by exception is what to do if something unexpected happens and it can’t wait for a scheduled Project or Programme Board meeting to be resolved. In these circumstances, the first thing to do is inform the Project Director. You then need to assess the impact of the problem, and decide what you need to do to resolve it. This might simply be a set of actions, or it might need a whole new project plan. Your Directorate Programme Manager will be able to help you work out an appropriate response to get the project back on track.
Alongside the principle of managing by exception, PMS also introduces the concept of reporting by exception. As part of Stage 2 (the project proposal), a project category was identified, determining what approvals and monitoring the project would require.
As a project manager, you will only be asked to provide one monthly Traffic Light Report, which the Project Board (for category A projects) or Programme Board (B or C) will review. If all is going well, this is all that will be needed, but if not, the new programme structures provide a number of escalation routes depending on which aspects of project delivery are causing problems. For example, the Project Review Group will be able to advise on commercial and technical issues, whereas the Directorate Programme Board is likely to be better able to consider aspects such as communications, risk management, and quality.
The emphasis on programme management which is at the heart of the new PMS is also important here. This means that your report will not simply be collated along with other reports to be circulated to the programme board, but will instead be carefully reviewed (and where necessary challenged) by the programme manager in advance of the meeting. The programme manager will then highlight the relevant issues or requests to the board and ensure that a swift response is provided to the project manager after the meeting. Directorate Programme Managers will fulfil the same role in relation to reporting to the Project Review Group.
As well as producing regular Traffic Light Reports for the Project or Programme Board, it’s also important to keep the Council’s project database up to date.
The database is compiled automatically from the various stage documentation submitted and gateway reviews for individual projects and programmes. This provides a secure, central location for the formal copies of these important documents and approvals. It also enables a level of project/programme interrogation to be undertaken, assisting Directorate Programme Managers (DPMs) and others when reporting.
As part of the start-up gateway, you will have identified milestones in the project plan which will enable stage reviews to be scheduled at appropriate points during delivery of the project. The number and frequency of these will depend on the scale and complexity of the project, and not all projects will need to have any stage reviews.
The stage review is an opportunity to review how the project is progressing against the plan detailed in the Project Initiation Document (PID) and to ensure that the planning for the next stage of the project has all been completed, and that all necessary resources and systems are in place.
The stage review should review whether the project is delivering Value for Money, and to ensure that it still represents the most effective and efficient way to meet the relevant objectives. It is important to remember that a project can and should be stopped at an time if the answer to the question Do we still have a viable and worthwhile project? is "no".
In addition to scheduled stage reviews, project reviews can be carried out at any point if there are concerns about progress, or where the project moves outside its agreed tolerances. Project reviews can be requested by the Programme Board or the Head of Programmes and Major Projects.
Some things in your project will go particularly well, while other things might go badly and cause problems for the project. Either way, you and other members of the project team will learn lessons as you deliver the project that could be useful for other projects in the future. So you should capture these lessons so that future projects are able to recreate successes and avoid mistakes.
A Lessons Learned log is very simple. It is made up of:
Anyone can record a lesson at any time in the project, and you should create an environment where people are encouraged to share this kind of learning. This is particularly important when lessons can be learned after something has gone wrong.
Remember that the whole point of a lessons learned log is to make sure that mistakes aren’t repeated, not to assign blame.
It is just as important to have a controlled close to a project as it is to have a controlled start. Closing a project gives an opportunity to assess how successful the project has been. It also helps to make sure that everything is ‘tidied up’ – that everything that you said you would do has been done and nothing has been forgotten.
There is a simple checklist that you need to complete before you can consider closing the project:
Once you are happy that the answer to all of these questions is “yes”, you can complete the End Project Report.
The End Project Report is used to inform the Project or Programme Board that the project has been completed and is ready to close. It contains information on:
Follow on actions are used to highlight further work that could or should be done once the project has handed over the product to the users. This might include things like:
For Category A (high cost / high impact) projects (such a PFI schemes), post project reviews should be carried out a year or more after project completion to assess whether the planned benefits have been realised and outcomes achieved.