Best Practice Project on a Page Template

This may be obvious but it’s worth saying if only because it’s so obvious that it’s easily forgotten when you are busy… Simple, clear, concise project status reporting can transform the success of your project and the way your are perceived by key stakeholders.  Over the years I’ve attended many project management workshops and training sessions and they nearly all focus on the technical aspects of managing and budgeting within large projects. If reporting and communications is considered at all they tend to assume that all your stake holders are equally engaged and skilled at reading summary reports.

Senior management seldom have the time to read through a 30 page progress report, what they want is a Summary on a Page (SOAP). In this blog I will share with you a “Summary on a Page” template that I’ve now used on numerous projects with great success.

The Project on a Page Template

You can use this project on a page template as it comes but I suggest instead that you or someone in your companies marketing department adapts the colour scheme, fonts, branding etc to match your companies house style or style guide for best results.

Project Summary on a Page Template

 

Let me talk you through this simple one page summary report step by step:

  1. You need to decide on your reporting period. I’d recommend the project manager produces a summary report on Friday after having walked around all the key players to ensure that report is as up to date and as accurate as possible. Doing this on a Friday lets you be clear about what’s been done that week and more importantly be precise about what must happen next week to keep the project on track.
  2. The Management Summary box should be used to give a very brief commentary on where the project is – certainly no more than 100 words. You should leave the bullet points to do most of the talking. Focus on what has been done and then what needs to happen next week, only picking on the 2 or 3 key things that need to be in the management summary. Remember that in a summary “Less is more”.
  3. Key Issues or Key Risks: As a project manager you should be maintaining a risk register.  One the summary report you need to use your skills to pull out the 3 to 5 key risks items that you want to communicate.  Feel free to include the full risk register as an appendix for anyone who wants all the details.
  4. Actions this week: You’ll no doubt have a long action list or work break down from your project plan.  In your summary report pick out 3 to 5 high impact actions that you want to communicate. Technically if you have items on a critical path these really should be on the management one page summary. I always include the full action log / register as an appendix (see below).
  5. Key Milestones: Pull out of your project plan all the key milestones. At a summary level just use simple RAG Reporting (Red=Bad/Trouble, Amber=Slipping/Needs attention, Green=On Track). This lets the summary report focus on the out come or delivery rather than how you get there in detail.
  6. Summary Gantt Chart: I like to include a very high-level timeline or gantt chart just pulling out the key milestones / activities.  You can show plan and actual on here.

Don’t feel constrained by how I’ve used the space in my template.  I’ll routinely rework this from project to project depending on what is most appropriate. In this template I don’t for example have a summary box for Budget but reporting if actual or committed spend is on track is often a requirement on larger projects.

As a project manager I find that focusing on clear concise reporting actually helps me manage the project and find the time taken to produce these reports to be time well spent actually managing the project better. Use the report as a working document, try not to have separate documents so your are not wasting time duplicating content.

Project Action Log TemplateAbove is a simple Project Action Log template that I’ll normally include as an appendix to the summary report for anyone who wants to see the detail. The action log is the detailed list of all the work that needs to happen on the plan and any follow up actions that are identified during project review meetings.

Project Issue List Template

This is the issue list template that I typically use.  The key is to make sure that every issue has a clear owner and a priority (RAG status). You will normally also want a column for the agreed completion date.

 

Tip: Although most people are familiar with a RAG stats or project traffic lights these days it’s actually a good idea to use BRAG statuses instead of RAG.  BRAG stands for Blue, Red, Amber and Green. This addresses the problem with RAG that completed tasks are shown with a Green status but that implies that they are not over the finish line and could still turn amber or red. The Blue in BRAG was introduced so that tasks which are finished (or done if your are using the Agile methodology) can clearly be shown as Complete and over the finish line. 

TIP: Don’t have a group of people or a department as the owner on issues – make sure it’s a named person with ownership and responsibility for seeing that the issue is resolved to the agreed schedule.

Summary Report on a page template – click here to download (Powerpoint PPT)

Good luck using the template. I’d love to hear your feedback and suggestions for improvements. I plan to update this template from time to time as a I receive feedback.

Question: What Is a project dashboard template?

Answer: In most organisations it would be perfectly acceptable to use the Summary on A Page template above as your project dashboard. You might want to create an even high-level summary which just pulls out a few KPI’s or metrics as dials for example percentage complete, budgeted cost of work performed, actual cost of work performed etc. If I get some time in the comping weeks I’ll add a page to cover this in more detail with some examples.

Question: What is a project overview template?

Answer: If someone has asked you for a Project Overview Template they are almost certainly referring to our Project Summary on a Page template shown above.

 

Strategies for managing risk out of your projects

One of the roles of the Project Manager is to identify risks to the project and create a Risk Register.  Once the risks have been identified their responsibility is then to work on strategies for managing those risks downwards or out of their project.  Below I present 5 key risk management strategies.  

  1. Prevention: by termination of the risk: by doing things differently and thus removing the risk, where it is feasible to do so. Countermeasures are put in place that either stop the threat or problem from occurring or prevent it having any impact on the project or business.  For example if you need to relocate a network server you may identify that there is a high risk of disk failure or some other form of hardware failure while the server is in transit.  You may decide to prevent this risk by avoiding the move entirely – this could be done by taking a backup on the existing server and restoring it onto a brand new server at the new location. A process that can be easily rehearsed and perfected ahead of the final move.
  2. Reduction: Treat the risk – take action to control it in some way whether the actions either reduce the likelihood of the risk developing or limit the impact on the project to acceptable levels. To continue the above example, when relocating many servers to a new office you could reduce the risk by moving the servers one at a time.
  3. Transference: This is a specialist form of risk reduction where the management of a risk is passed to a third party via, for instance, an insurance policy or penalty clause, such that the impact of the risk is no longer an issue for the health of the project. Not a lll risks can be transferred in this way. Continuing the above example again, when moving servers you might decide that contracting the work out to a firm who specialise in this type of work would be a good idea.  This would transfer the risk to a specialist but also likely reduce the risk by using people who carry out this type of work all the time and who therefore know the potential problems that may occur and ways of avoiding them.
  4. Acceptance: Tolerate the risk – perhaps because nothing can be done at a reasonable cost to mitigate it or the likelihood and impact of the risk occurring are at an acceptable level.  Bad Weather is a good example of a risk you may decide to accept.  For example some outside events can be ruined by bad weather.  While it may be possible to take out insurance against this the cost of doing so may be too high to be considered worth while.
  5. Contingency: These are actions planned and organised to come into force as and when the risk occurs. For example if it rains the concert will be held in the village hall instead of on the green.

If you have alternative ways of managing risks in projects then I’d love to hear from you.  In a future blog I’ll look at the best way to present a risk register and communicate how you are managing risks in your project.