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.