In a lot of ways, stakeholders are just like children. They have limited attention spans and respond positively to structure, simplicity and color. This becomes even more evident the more senior your stakeholders are.
It’s not surprising as they have a constant stream of requests for both decisions and resources. Keeping things simple and clear helps them do their jobs – and helps you as a product manager get the focus your product deserves.
This aim for simplicity inspired the creation of our Launch Readiness Template.
This powerful tool is a single summary slide that enables you to report the status of every mini-project or workstream related to launching a product.
You can create a version on your own but it’s usually much better to have a common template, agreed by the product team and senior stakeholders, that everyone uses.
Setting it up
Start by dividing your project into a manageable number of key workstreams (say 10-20).
Then, each workstream needs to have an owner. For example, your contact in Support might own and organize support team training, your contact in Development will be responsible for delivering the product against agreed requirements. As the product manager, your own name may appear several times!
Make sure you understand the relative importance of each workstream. This will allow you to make a distinction between ‘critical activities’ that must be completed to launch on time and ‘other activities’ that can be finished after launch.
The critical activities have two RAG (Red, Amber, or Green) statuses. The first shows whether the workstream is introducing any risk to meeting the target delivery date, the other shows the level of completeness. In the example above there is just one workstream (Business sign-off) that is shown as putting the launch at risk.
For non-critical activities, the RAG status shows only the level of completeness. So in the version above, it’s unlikely the sales tools will be ready for the launch, but this is not seen as important enough to stop the launch going ahead.
Usually, you would create just the template summary page. However, it can be useful to provide further explanation on each workstream using a details page. If you do this, we recommend providing supplementary information only for those things that are red.
Using the template
Now you’re ready to send your Launch Readiness Template out to everybody involved in the project – particularly those all-important senior stakeholders.
We recommend issuing an update once a week during the launch project. That means you or your Project Manager (if you’re lucky enough to have one) need to get in touch with all your workstream owners and update each RAG status before you distribute the document.
A further refinement you could use is arrows (↑ → ↓) to reveal the RAG trend. For example, if a workstream is marked amber but the arrow is up (↑), this shows a trend towards green – which is less worrying than a down arrow (↓) trending towards red. We’ve shown that in the ‘Other Activities’ section. We always find that whatever format you use evolves at the beginning of a project until things settle down.
We’ve found that this handy little tool provides multiple benefits:
- The top line reminds everyone why the project is important
- It gives a structured, color-coded summary of the project status at a glance in an easy-to-digest format
- It forces you, and everyone else involved, to keep on top of things, avoiding unexpected surprises – one thing children tend to love that stakeholders most definitely do not!
- You get leverage with each of your workstream owners through the simple process of flagging their performance publicly
- It reassures stakeholders that you’re in control as you set and manage their expectations
- A consistent red RAG status over a number of weeks will focus senior stakeholders on areas of concern and builds the pressure on them to act. Their eyes are somehow trained to pick up the color red!
Ultimately, using this Launch Readiness Template keeps product managers on top of their launch and shows they’re professional and in control. We can personally vouch for its effectiveness.
Director, Product Focus
Join the conversation - 5 replies
It seems like an useful tool. How can I download it ?
Thanks for your feedback.
The example we show in the blog is simply a PPT slide, so easy to reproduce. If you’re interested in the template then the only way we have to provide it is to join one of our training courses and then we’ll give you a USB key with a whole set of document and slide templates.
This is great. My concern is the completeness rating. Wouldn’t it be ok if they were all red? Wouldn’t that just mean that there’s a lot of momentum toward a long term set of improvements, but the team is focusing on what is truly critical for the current launch / phase?
Hi David, Thanks for the comment.
A good way to use ‘Completeness’ is to give a forward looking view that shows your expectations of what will be the level of completeness of an activity at the milestone your driving for. In the blog we talk about managing a launch project and show that the ‘External comms’ activities have an expected completeness of amber. That means we expect there will be some activities that still need to be sorted out after launch.
This let’s stakeholders know two things i) things are not going as well as we wanted with external comms and ii) we’ll continue to need some resources working in this area after launch date.
A completeness status of green doesn’t mean we’re finished and that we no longer need resources working on an activity – it just means that we’re looking good for having everything ready for launch (and stakeholders need to understand this is what it means).
The other way of using ‘Completeness’ would be to show the degree to which something has already been finished. e.g. green means it’s all done, amber might mean it’s 80% done and red could mean its less than 50% done. Used in this way, you’re correct that all activities would start as red and gradually become amber and then green as the project progresses. Whilst perfectly valid, we think this is usually less useful to stakeholders than the forward looking view that we propose.
I like this, I often see a single “status” RAG being used, generally for completeness, and there is usually confusion about which type of completeness, as in the earlier comment and response, is intended. I like separating out the critical and other activities.
Is it fair to say that the Completeness can never be “better” than the Launch Risk? This is certainly the case for the example, and looking at the definitions it would seem to be so. Or maybe it could be OK as Completeness is explicitly stated to be about non-mandatory activities? It would be possible to have all the non-mandatory activities completed, but not all the mandatory ones. Maybe the two should be interpreted as “Risk to mandatory activities” and “Risk to non-mandatory activities”? That would fit in with why you only need one for the “other” activities
Hmm, food for thought