Stage 1: Project Mandate

Project ideas

The starting point of any project is an idea. This can come from almost anywhere, for example:

• a new Government directive or other statutory requirement
• a funding opportunity or call for proposals
• a strategy or action plan
• a commitment in a service plan
• a service review or service improvement plan
• a Ward plan or Member request
• an example of good practice from another area.

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.

Portfolio review

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.

Project type

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 

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.

Download the Gateway 1 Template

The process to take a project through this first gateway is illustrated here.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Stage 2: Project Proposal

This stage develops the mandate into a more detailed project proposal. The key elements are:

Strategic Fit

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.

Corporate Considerations

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.

Risk and Impact Assessment

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:

• Category A projects (high risk, high cost, high impact) require a project board and will be monitored by the Project Review Group (in addition to the Programme Board). 
• Category B projects will also be monitored by the Project Review Group, but do not require a separate project board.
• Category C projects will be approved and monitored by the Programme Board only
• Category D projects will be approved by the Programme Board, but ongoing monitoring will be by divisional management teams (as part of “business as usual” delivery, such as the Local Transport Plan investment programme), with reporting to the Programme Board by exception only.

There are further details on the Project Risk and Impact Assessment in the Toolkit section.

Gateway 2

Gateway 2 requires the following form to be completed.

Download the Gateway 2 Template 

Stage 3: Business Case

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:

• Do we have a viable and worthwhile project?
• Is it measurable and will it achieve council objectives?

The key elements of the Business Case are as follows:

Options Appraisal

• Clear, measurable objectives
• Weighted evaluation criteria
• Options for intervention
• Robust cost estimates (including whole life costs)
• Value for Money analysis

Delivery planning

• Confirm scope and exclusions
• Product / output definition
• Timescales and stages
• Resource requirements (capital and revenue)
• Funding plan
• Project team / structure
• Risk log
• Application of lessons learned from previous projects

Consultation and engagement

• Stakeholder analysis
• Member involvement
• Partnership arrangements
• Governance, reporting and approvals

There are guidance notes on the Gateway 3 Template and further details on how to develop each element are provided in the toolkit section.

Download the Gateway 3 (Business Case) template

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.

Stage 4: Project Start-Up

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:

• What needs to be done (products) and how (tasks)
• When it needs to be done by (milestones)
• Who will do it and how much it will cost (resources)
• How it gets signed off and agreed (quality)
• How the project will engage with and talk to other people and groups (communications)

Project Initiation Document

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:

1. Project description, including background, objectives, outputs / targets, strategic fit, corporate implications, links and dependencies (from the Mandate and Proposal)
2. Business case, including options appraisal and value for money analysis
3. Resource management, including resource plan, funding plan and budget
4. Organisation and governance including project team structure
5. Reporting, including setting project tolerances
6. Project delivery plan (and a stage plan, if you’ve done one), highlighting milestones and proposed dates for stage reviews
7. Project controls, including tolerances and quality plan
8. Stakeholder analysis and communications plan
9. Risk register.

Download the PID template

Gateway 4

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.

Stage 5: Project Delivery

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:

• Traffic light reports
• Managing resources
• Risk management
• Issue management
• Change control
• Stakeholder management and communications

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:

• Managing by exception
• Reporting by exception
• Project information
• Stage reviews
• Project reviews
• Learning lessons

Managing by exception

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.

Reporting by exception

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.

Download the Project Traffic Light Report template

Project information

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.

Stage Reviews

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".

 Project Reviews

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.

Learning Lessons

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:

• How did the lesson come about – what happened?
• What did you learn?
• What can other people do to recreate that situation or avoid it happening?
• A contact for further information.

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.

Download Lessons Learned Log Template

Stage 6: Project Close

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.

Completing the Project

There is a simple checklist that you need to complete before you can consider closing the project:

• Have all the products been delivered and accepted?
• Are there any communications activities outstanding?
• Have all the invoices/bills been paid?
  (note: in some projects, financial close happens after the actual project is closed)
• Are all the risk and issue actions completed or closed, or are there any further actions required ‘outside’ the project?
• Have you captured any further lessons that will help future projects?

Once you are happy that the answer to all of these questions is “yes”, you can complete the End Project Report.

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:

• How well the project performed against the baseline PID
• How well the objectives have been met
• Lessons learned
• Follow on actions and a date for a post-project review.

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:

• Training needs
• Change requests that were rejected but still might be worth investigating
• Project issues that weren’t resolved
• Actions for any future review of the project.

Download End Project Report Template

Post Project Reviews

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.