Project Manaverse

In this blog I’m going to share how I write my executive summaries for my project status reports.

What is a project status report? It is a report on the status or ‘health’ of your project. Status reports can be read by anyone who has an interest or ‘stake’ in your project, however, they are most commonly read by programme managers, portfolios managers, senior leaders, directors and executives. A decent status report should fit on one page. They often look like a ‘dashboard’.

What is an executive summary? The executive summary is usually the first part of the status report. As you might expect, it summarises the entire report in a short paragraph or two. Executives tend to have limited time to spend on your project, so the exec summary is their ‘go to’ place to get the latest news.

Executive summaries are quite simple to write once you know how. I’m going to share the five key elements that should go into any exec summary. I’ll do this while building up an example for you.

Part 1 – The RAG status

The RAG status communicates whether your project is red, amber or green (RAG). Green means everything is fine, red means the project is in trouble, and amber is somewhere in between. The RAG status of the project can be subjective and it’s something you need to be able to determine as a project manager. You are better placed to do this than anyone else, because no-one knows the ins and outs of your project as well as you do. You will have the best sense as to whether the project can still achieve its target delivery date.

Personally, I love the project RAG status. In half a second, in a glance, I can get a very good sense of how a project is doing. If I see the project is green, I know that all is well and I don’t need to know much else. Sure, there may be a few issues, but none of them will be big enough to materially impact the delivery date, the cost, or the scope. If the project is amber or red, I know that things are not so peachy and people are going to want some answers.

The RAG status is what the executives are chomping at the bit for, so let’s not keep them waiting. The first two words of our status report will communicate the project RAG, for example,

‘Project Amber…

Part 2 – The RAG Reason

Now that we’ve done the big reveal of our project health, it’s time to explain what’s driving the RAG. We only need to explain why the project is amber or red (we don’t need to explain why it is green, for obvious reasons). This is really important because the senior stakeholders will always, always want to know the reason why the project is amber or red. It’s always the first question they ask. So let’s tell them before they ask.

If our project is red or amber, it must be due to risks or issues, or both. It must be. We cannot have an amber status and then say we don’t have any risks or issues. Therefore, the risk or issue that is driving our amber status should be in our Risks and Issues log (and if it isn’t, we better get it in there quickly). If our project is a workstream of a larger project or programme, then the risk or issue should be in the overall project or programme Risk and Issues log, too. A logged risk or issue will have a reference number, and we should include that reference number in our executive summary. That not only makes us look very organised, but it also lets people know where they can find more detail if they want it.

So, let’s add all that into our exec summary. In this example, our project is amber because our testing is three weeks behind schedule (the issue detail found in the Risks and Issues log will explain why)…

Project Amber due to System Testing being three weeks behind schedule (Issue I065 refers).

Part 3 – the ‘so what’?

We’ve now revealed our project is amber, and that the amber status is being driven by our testing delay. Now it’s time for the ‘so what’? ‘The testing is delayed, you say? So what? What’s the big deal, it’s only 3 weeks?’ We now need to explain how being three weeks behind on our testing is enough to push our project into the amber status. In our case, it’s because the system testing is on the critical path, and we don’t have any contingency. The critical path is a series of sequential events (i.e. they cannot be done in parallel) that must happen by certain milestone deadlines to hit the overall project delivery date. Therefore, if one of these milestones is delayed, it moves all the other sequential milestones to the right, ultimately pushing the overall project delivery date to the right. By us saying that the system testing is on the critical path, it makes it very clear to anyone who knows anything about projects that our overall delivery date is now at risk. You should include any relevant key dates in your executive summary, as someone will invariably ask what they are. A baselined date is one that has been agreed or acknowledged by senior folk and usually requires some form of approval to change it. Let’s now add that to our executive summary…

Project Amber due to System Testing being three weeks behind schedule (Issue I065 refers). System Testing (baselined completion date 8th Oct) is on the critical path and this delay puts our target Go Live date at risk (basedlined 3rd March ’22).

Part 4 – throw in some good news

The plot is certainly thickening, but it’s all been doom and gloom. To show we are not complete failures (and to lighten the mood), it’s always good to throw in a few successes. In this example, we will call out some good news and show how great our engineers are at resolving defects. We’ll also confirm everything else is going well…

Project Amber due to System Testing being three weeks behind schedule (Issue I065 refers). System Testing (baselined completion date 8th Oct) is on the critical path and this delay puts our target Go Live date at risk (basedlined 3rd March ’22). However, our engineers continue to work through the issues and have closed a further seven defects in the last two weeks with only three now remaining open (twenty two closed in total). All other key project activity is progressing as planned.

Part 5 – the Route to Green

Okay, we’ve thrown in some good news to soften the blow, but that doesn’t change the fact our project is amber. What everyone really wants to know is what are we going to do about it? How are we going to dig ourselves out of this hole? This is known as the route to green (RTG), or the path to green (PTG). Never, ever, ever, write an executive summary status report without a route to green. You will be crucified. As project managers, we should always have a plan for bringing the project back to green. Without a RTG, the project should be red. The route to green should be specific, with key steps and target completion dates for those steps. Let’s now include this as the 5th element to our executive summary…

Project Amber due to System Testing being three weeks behind schedule (Issue I065 refers). System Testing (baselined completion date 8th Oct) is on the critical path and this delay puts our target Go Live date at risk (basedlined 3rd March ’22). However, our engineers continue to work through the issues and have closed a further seven defects in the last two weeks with only three now remaining open (twenty two closed in total). All other key project activity is progressing as planned. RTG: 1. Recruit one additional test lead full time equivalent (by 14th September). 2. Agree resources for weekend working on 18th & 19th September (by 15th September). This will ensure outstanding test scripts are executed by 1st October, allowing time for any defect retesting, therefore preserving our System Test completion date of 8th Oct.

So there we have it, an executive summary fit for a king. That should give those execs all the key info they need to know, and confidence you have things under control. The only thing they may ask is why the testing is three weeks behind. This detail will be in the Risk and Issues log, but you could always include a short and concise description in the exec summary, if you wanted to. Alternatively, you could hyperlink the reference number to the log.

If you have any questions or comments regarding the executive summary, or project management in general, please leave them in the comments section below, I’d love to read them. Until the next time!