Most people outside consulting have a vague idea that consulting projects like McKinsey do result mainly in a lot of slides. But what does this slide pack or deliverable actually look like in real life? What is the quality bar these deliverables need to meet? And what ends up in the final report compared to the work that goes in?
In this article, we’ll first discuss what a deliverable is, so the baseline is clear. Then we’ll dissect the final deliverables from a real-life BCG project that were made public because the client was City of Dallas. We’ll look at how the deliverables fit together, what function each one plays, and which best practices you can use in your own work. In addition, we’ll see how the client turned the recommendations into an implementation plan.
And finally, we’ll share some practical tips on how to structure your project and work plan around deliverables to better focus your time and effort.
Deliverables are the final artifacts that are handed over to the client once a project ends. For consulting firms like McKinsey, BCG, and Bain, these deliverables almost always include at least one slide report that summarizes the process, key findings, and recommendations or next steps resulting from the project.
The typical output is a short executive-level report coupled with a detailed report, created as slides but delivered in PDF form.
As consulting is moving more toward an integrated and results-oriented way of working, deliverables may also include artifacts like Excel models, code, prototypes, mock-ups etc.
The deliverables are not everything that is created in the project, but instead a specific artifact or set of artifacts that are agreed upon before the project begins. Most often, the exact format is not defined, but the outcomes that should be included are, as you see in the example from McKinsey below.
An example of deliverables for a McKinsey project.
In June 2016, the City of Dallas engaged BCG in an 11-week project to evaluate how to improve public safety while safeguarding animal welfare, specifically, the problem of loose dogs. BCG briefed the City Council on August 30, 2016. Because this was a public-sector engagement, the deliverables are part of the public record (City of Dallas council documents), which makes them a rare chance to study real top-tier consulting output in full.
The deliverable handover consists of four parts:
Let’s jump into each of these in more detail.
The (relatively) short first deliverable is a slide-based 57-page deck presented to City Council. It represents a classic, best-practice deck with context, key findings, recommendations, and next steps and ends with a Q&A. The main part of the deck is only 35 pages, with some deep-dives ready in an appendix to be pulled up if there are questions.
There are several things to note with this deck; first, it illustrates how the situation-complication-resolution framework should be used effectively. The situation (context) sets the scene and places the BCG project in the wider landscape of the City of Dallas’ efforts to create a safe environment. The complication (key findings) then in detail build up what the problem is today and why it is a problem. Finally, the resolution (recommendations) is presented in a to-the-point, prioritized way and emphasizes funding needed and estimated impact of each recommendation so decision makers can easily determine which recommendations to implement.
The executive-level report follows a clear situation-complication-resolution structure.
Second, the deck only picks out the most important findings from the hundreds of slides that make up the working material and detailed report. This is best practice and one of the ways to make your work stand out and seem polished.
Third, the deck succinctly described suggested next steps and includes a guide to the rest of the deliverables. This helps decision makers get an overview of the results, yet not drown in data and keep the focus on actions to take tomorrow.
The next steps slide in the BCG report is short and clear, and the deliverables overview provides a guide for the many slides and pages that follow.
The second main deliverable of the project is a 94-page white paper. This is essentially a written version of the executive deck with a fully written narrative and full-length explanations for each recommendation. Where the executive deck is meant to be presented, this white paper is meant to be read as a stand-alone document on its own.
The white paper also details the approach BCG used in more detail. It especially covers the goals BCG set out to achieve with the project (and which anchor the deliverables), the research and analysis process they used, and the team that helped contribute.
The white paper is a typical deliverable in a public-sector project, but very rare in private engagements.
The third deliverable of the project is a 115-page dense deck with details on each recommended initiative.
It starts off with an overview of all recommendations, how they are prioritized, and what the estimated funding need is to implement all recommendations. Then it dives into each recommended initiative with an overview of the initiative, background and context, key assumptions that underpin the recommendation, the sizing of the potential, and the cost to execute the initiative.
Each recommended initiative is numbered and tracked against the main overview. In addition, each section follows a fairly stringent structure, so it is easier for the reader to digest and compare initiatives.
The deep-dive deck has two functions; it summarizes findings systematically to encourage faith in the recommendations and that the consulting team has done their job, and it serves as a blueprint and background for the people implementing the initiatives. Because the recommendations are data-driven and the data is clearly shown along with key assumptions, it’s easier to convince stakeholders and the people on the ground that the recommendations are sound and should be followed.
The final piece of the deliverables for this BCG project is the long working documents file. This 137-page deck contains a mix of internal and external data, conclusions, methodology, and process slides and BCG puts a disclaimer on it upfront to indicate that this is working material and is not all verified.
This type of working documents deliverable is quite unusual in regular consulting projects, but reflects the fact that this particular project was both a public-sector and pro-bono engagement where BCG has wanted to leave the client with as much information to continue on their own as they can.
An example of the detailed slides found in the working documents deck.
Because this project was public-sector we get to see what happened after the project ended. BCG presented the findings to the City Council in August 2016 and in September 2016 the City Manager sent around an implementation plan to start acting on the recommendations. This included a budget increase to help fund some key initiatives, as well as a prioritized action plan and early solutions already in place.
In January 2017, the Assistant City Manager sent around a second update on the implementation of the recommendations. In these, they highlighted that they are already seeing positive results of the first initiatives.
In April 2017, there was another update showing even more progress being made and in June 2018 the City of Dallas published a dashboard linked to the recommendations, showcasing the progress.
Today, it looks like the loose dog problem is unfortunately back in Dallas, but they have engaged a new animal welfare services firm to help get a grip on the situation.
The City of Dallas ended up following several of the BCG recommendations.
You don’t need a top-tier consulting badge to apply these patterns. Start here.
A real top-tier consulting deliverable is not “just” a collection of many, heavy slides. Nor is it simply a summary of everything that has gone on in the project. Instead, it’s an action-oriented, results-focused report aimed at moving decision makers in one direction or another.
The fastest way to internalize these patterns is to study full, worked examples and then build from structured templates that already encode the storyline. Pick one upcoming deck, pick mainly the slides that focus on recommendations, results, and next steps, rewrite its titles as conclusions, add a scope slide, and move everything that doesn’t feel strictly necessary to an appendix. That alone will move your output noticeably closer to the top-tier standard.
Try the Slideworks PowerPoint add-in: the full slide library inside PowerPoint for teams, with smart search and exclusive new slide drops.
Try the add-in now
Q: What is a deliverable in a consulting project?
A: A consulting deliverable is any artifact a team produces and hands over at the end of the project. The main deliverables are agreed upon before the start of the project.
Q: What does a top-tier consulting deck typically include?
A: A top-tier consulting deck typically includes a title and agenda, context and scope, approach and methodology, an executive summary, an action-titled analytical body, recommendations, a prioritized roadmap, maybe a business case, next steps, and a detailed appendix.
Q: What are the working documents behind a consulting deck?
A: The working documents are the models, survey datasets, interview guides, benchmark databases, and source analyses a team builds during an engagement; they underpin every number on the client-facing slides but are rarely handed over as-is.
Q: How many slides is a consulting deck?
A: An executive-level consulting deck is often 20 to 50 slides backed by a much larger appendix. BCG’s Dallas council deck ran to 54 slides with a roughly 350-page supporting compendium.
Q: Are consulting deliverables confidential?
A: Most consulting deliverables are confidential to the client, but public-sector engagements like BCG’s Dallas project become part of the public record and can be studied in full.
Q: What format are consulting deliverables in?
A: For slide-based deliverables, they are almost always handed over in .pdf format. This is both to ensure every slide looks perfect no matter who opens it up (and with no risk of missing fonts, wonky alignments or similar) and partly to hide any notes or imperfections or weird but necessary layouts that the team has had to do.
