Seven Rules For Creating Great Client Deliverables

A simple set of questions to determine if you're giving clients work which is actually useful to them.

Welcome to my consultancy newsletter. Please subscribe and check out my best articles.

Seven Rules For Evaluating If Your Deliverables Are Any Good

When FeverBee began hiring staff, we had to begin developing processes to ensure consistency in the quality of the deliverables we were creating for client. It’s important, especially for people new to consultancy, that they avoid the common errors. 

This has evolved into a checklist of things to review before a document is sent to a client. I’m going to share it below. 

Rule One: Did we add unique value through our methodology?

Did you add unique value or simply move the pieces around? A common consultancy error is to gather information from a client and then create a deliverable which simply shows that information in a more visually pleasing, better structured, format. 

This often happens when you begin with a template and start trying to find the right information to complete the template. The very obvious problem with this is you’re not really delivering any value. You’re simply moving the pieces of existing information around - not synthesising it to create something useful.

The information you gather from clients should be run through your methodology (problem-solving, analytical, change-management, broader experience) to create something which didn’t already exist. The outcome should reflect how you’ve taken the information stakeholders have given you as inputs into your process, not as the outputs of your process. Can you clearly see the unique insights you’ve created in this process? Are the insights powerful and clear enough? 

Rule Two: Does it clearly match the project objectives as detailed in the SOW?

The second thing to review is whether the deliverables you’re creating precisely match those as explained in the SOW (or through documented change-order requests). 

A common mistake is to tweak the deliverables as you go through the process to accommodate new thinking. This isn’t bad, but you need to do it officially. You don’t want a stakeholder at the end of the project to be asking ‘and where is this deliverable?’ only for you to point out you combined it with a few other deliverables. This just creates unnecessary confusion. 

Make sure the names, format, and scope of the deliverables match precisely what’s written in the SOW. 

Rule Three: Does it address the issues raised by key stakeholders in the journey?

I know one person who freely admits to replicating the same deliverables for almost every client.

He only gets away with it because clients don’t talk to each other. But this isn’t good quality work because it doesn’t reflect the unique needs of stakeholders. The moment there is any contact between two past clients, he’s going to be found out.

Most projects will require you to engage stakeholders.

The deliverables you create should deeply reflect the needs and concerns of those stakeholders (i.e. this shows you aren’t simply making the same recommendations to every organisation).

Stakeholders should be able to see their concerns addressed and how the information they have provided has clearly shaped the deliverable. 

Rule Four: Does it highlight what the client should do differently?

It’s easy to present a bunch of research or insights gathered without answering the ‘so what?’ question. What is the specific thing the client should do differently as a result of the deliverable? 

When a client engages a consultant, they typically want the answer to the question; what should we do differently? 

This typically means what should they spend more time doing, less time doing, changing, and what should they stop doing? Your deliverables might contain one key idea or lots of small tweaks - but it should be clear what you want the client to do differently. 

Rule Five: Does it provide clients with information they didn’t (or couldn’t) already possess?

This is closely related to the top point, the deliverable should obviously contain information the client didn’t (or couldn’t) possess. If your deliverable simple state the obvious, information the client already knows, or something which would always be true (‘improve your customer experience!’) then what’s the point?

This doesn’t mean your deliverable has to recommend a completely different course of strategy from what the client already intended to do. But in those situations it should show why it’s the best path forward - most likely by exhaustively evaluating the other options against your unique criteria (added value) to highlight the benefits of your approach. 

The deliverables should always contain information and insights the client didn’t or couldn’t possess before the process began. 

The deliverables should clearly give clients extremely valuable information they didn’t possess before the process began.

Rule Six: Does it contain the implications of the recommendations?

Have you gone deep enough? Great deliverables should think through the implications of any recommendations you’re making and be structured in a way which makes them easy for a client to implement.

It’s critical to think fully through the implications of your recommendations to ensure they are practical and can be easily implemented by your client. This often means diving into the weeds to explore the how it will be implemented at the macro level. This is especially important when your recommendations are related to technology. The last thing you want is to outline an entire plan on a specific technology platform only to be immediately told that platform doesn’t pass the basic security review. 

You can’t specify every single thing a client should do, that’s not practical, but you should be able to go into considerable depth in your recommendations. The greater depth you’re willing to go, the better the recommendations will be. You should try to surface potential issues and how they will be overcome before you present the deliverables. 

Rule Seven: Is it visually impressive and arguments clearly presented?

This is clearly subjective, but the final step is to review the quality of the design of the deliverable. Design is always the last consideration. It’s not the least important, by any measure, but it’s the thing you should do last because you need all the other information in place before you do the design. 

During this phase, you should look at consistency of font, colors, contrast, spacing, page structure etc…You should check if the key recommendations are highlighted and the critical information stands out from the less critical information. You should check, if relevant, that your deliverables are telling a consistent story. 

Your deliverables should always look impressive. They should pop. The design matters a lot in the perceived quality of the deliverable. 

---

You can add and subtract your own rules here I’m sure. But the key recommendation here is to review what you’re creating to be sure it adds tremendous value to the client.