11
Identify the Required Facts
The basis for a compelling pitch is a solid fact base. You’ll need proof for every point you make in your story. What I find most interesting about the structured thought process is the amount of thought that goes into a pitch before you even begin gathering data. Here we are, eleven chapters into the method before we’re discussing gathering facts. This is why the method is efficient. You’re doing your thinking before rushing off and conducting time-consuming analysis and research. All that thinking focuses you on gathering facts that will make your case stronger versus gathering facts because they’re interesting.
You may find this notion of not gathering data until this late in the process unrealistic. Do not mistake the length of the chapters preceding this as a proxy for the amount of time you’ll spend on the process. I’ve been in situations where we went from question to core idea to architecture in two days. We wrote the story and syndicated it in two days. We were in analysis mode on day five of the project. In other situations, you’ll already have significant amounts of background analysis complete before you even start a project using the structured thought process. Many pitches you’ll make will be related to your everyday work. You can use existing analysis to form your preliminary perspectives as you craft your core idea and your architecture. The broader takeaway is you need to think about structuring your pitch before conducting substantive analysis.
Whether you realize it or not, you’ve already identified the facts you need to gather and the analyses you need to conduct. You did this when you created your architecture. Previously, I mentioned you would build your architecture from the top down and then “prove” your core idea from the bottom up. The core idea drove your architecture’s structure and content. The bullet points in your architecture will drive the analyses you use to support your case. Those analyses will prove or disprove the points you’ve made in your architecture. If the analyses prove the case, you’ll proceed with your recommendation. If they disprove elements of your architecture, you’ll iterate and modify your architecture—and even your core idea—until all the points in your pitch are fully supported by facts.
Choose Your Analyses
You’ll need facts and analysis to support every point in your architecture. Sometimes the support will be a simple analysis, a page with customer quotes, a process diagram, or any set of facts that lead to your conclusion. Other times this will require several rigorous analyses to prove the point. The point you’re trying to prove will dictate which facts to gather and which analyses to conduct. Let’s look at how the architecture in Figure 6.4 (p. 98) dictates the analyses that need to be conducted. For each point in the architecture, I’ve suggested analyses that could be used to support the point.
Buy a new dialer
Our dialer is old and keeps breaking down.
Analysis: timeline explaining the history of when the dialer was put into service.
Analysis: error and downtime reporting for the dialer showing the frequency of breakdowns and the amount of downtime for the last six months.
There are newer and better dialers on the market.
Analysis: list of the top three dialers on the market with an explanation of their main features and functionality compared to our current dialer’s functionality.
A better, more reliable dialer will improve our collections performance.
Analysis: historical collections performance of our current dialer compared to estimated collections performance with a new dialer.
Analysis: estimated lost collections dollars attributable to the errors and downtimes of our current dialer for the last six months.
Buy from vendor ABC
Vendor ABC sells high-quality dialers.
Analysis: assessment of Vendor ABC’s top dialers. The analysis includes features and functionality as well as any industry benchmarking of ABC’s dialers versus competitor dialers.
Vendor ABC has competitive pricing.
Analysis: price list for Vendor ABC’s dialers compared to the prices of other comparable dialers in the market.
Only one other vendor’s products are approved by our IT group, Vendor DEF.
Analysis: list of the top dialer manufacturers including ABC and DEF and their approval status with IT. If a manufacturer is not approved, include the reason why.
Vendor DEF’s product is inferior to vendor ABC’s.
Analysis: side-by-side comparison of DEF’s top products compared to ABC’s top products. Key evaluation dimensions should include the metrics most important to the collections organization like speed, reliability, accuracy, and so on.
Our losses have increased by $ZMM this year.
Analysis: show historical losses for the last three years and highlight the increase of $ZMM this year.
A new dialer could deliver loss reduction of $XMM per year.
Analysis: show expected future loss reduction attributable to a new dialer versus continuing with the existing dialer status quo.
Every analysis is linked to a point from the architecture. All told, it’s eleven analyses. There are dozens of other analyses that could be conducted but they don’t need to be conducted. If these eleven analyses prove the points they’re designed to prove, then those points hold as true. If those points hold true, the three columns hold true. If the columns hold true, the core idea We should buy a new dialer from Vendor ABC to reduce our losses by $XMM per year is proven. This is what I mean by building from the top down then proving from the bottom up.
This approach applies to layer architectures too. Every point in the architecture must be supported by facts. The points themselves indicate which analyses to conduct. Here’s how you might define analyses for a layer approach using Figure 7.1 (p. 113) as an example.
Background
Our team has twenty-seven personnel who conduct document processing activities.
We’ve been at that staffing level for the last four years.
Analysis: bar chart showing staffing levels for the last four years.
Document processing volumes have been steadily increasing over that time period, but we’ve been able to meet demand and achieve our service level requirements.
Analysis: line graph showing document processing volumes and how they’ve increased for the last four years.
Analysis: bar chart showing the team meeting or exceeding service level requirements for the last four years.
Our team’s performance is measured by service level agreements, and we consistently meet our goals. When we meet our goals, the company does well. If we fail to meet goals, company sales and profit performance suffer.
Analysis: chart showing service levels correlated with company sales and profit performance over the last four years.
What’s changed
Document processing volumes are continuing to increase and we’re forecasting a personnel shortage for next year
Analysis: line chart showing current and projected document processing volumes.
Analysis: staffing required to meet service levels for increased document-processing volumes. Analysis should highlight the magnitude of the personnel shortage for next year.
If we have a personnel shortage, we won’t be able to achieve our service level goals, and company performance will suffer in the form of lower sales and profits.
Analysis: forecasted service levels if staffing is not increased but document processing volumes increase as projected.
Analysis: expected sales and profit performance based upon correlation between short-staffed service levels and company financial metrics.
Core idea
We should hire five new team members because we’ll be able to meet increased processing demands and help the company achieve its sales and profit goals.
Analysis: calculate the staffing gap and show how five personnel will be sufficient to fill the expected gap.
Analysis: show projected future service levels with the incremental five personnel given the expected document processing volume increase.
Analysis: expected sales and profit performance based upon correlation between fully-staffed service levels and company financial metrics.
This is another situation where eleven analyses would be sufficient to support the recommendation. Every analysis on the list is necessary. If any analyses were left out, the argument would be weaker, if not entirely invalidated. If the analyses all play out as expected, those results should be enough to get the pitch approved.
Necessary and Sufficient Analysis
Choosing analyses based upon every point in your architecture ensures you cover the necessary facts. Without those analyses, that particular point in your architecture won’t be supported. An unsupported point can cause your entire argument to collapse. Conversely, if you conduct extra analyses unrelated to proving a point, those analyses aren’t necessary. This is one way you can eliminate wasted effort. Redundant and irrelevant analyses do nothing more than frustrate your audience. If the analysis isn’t conducted to support a point in the architecture, you don’t need it and you shouldn’t be wasting your time on it. If you include excessive analysis to support a point, your audience will grow weary of those facts because they’ve already received enough information to consider the point proven. Focusing on the necessary facts will save you time and effort. That focus will make your meetings shorter and more productive. Let your architecture govern your analytical efforts.
You can use your architecture to manage stakeholder requests for additional analysis. We’ve all received requests to conduct irrelevant analysis. Unfortunately, when this happens, the only choices we have are to capitulate and do the analysis, even though we know it’s a waste of time or argue with our stakeholder about why we don’t need to do the work. In the former scenario, we’re wasting time and energy. In the latter, we can be perceived as uncooperative, insubordinate, lazy, or frustrating. Without a clear rationale for not doing the work, those arguments come across as whining and complaining.
If you have an architecture, you can push back on stakeholders in a logical way. If your stakeholder asks you to perform an analysis you think is irrelevant, pull out your architecture. If they’ve already bought into your architecture, this is a powerful technique. By agreeing with your pitch’s logic, they’ve given you an effective way to ask them how the analysis fits into proving the case. One of two things will happen: they’ll either explain how the requested analysis contributes to proving the case, or they’ll realize the analysis isn’t necessary to proving the case. In the first situation, include their requested analysis in your architecture. In the second case, they should be willing to abandon the analysis because they see why it’s irrelevant.
In addition to making sure your analyses are necessary, the analysis you conduct has to be sufficient to prove your case. Weak analysis results in a weak argument. You need to have enough data to convince your audience your recommendation is correct. If you’re trying to convince your audience to spend tens of thousands of dollars to launch a new product, you’ll need compelling evidence. If your analysis consists of quotes from fifteen people saying they love your product, that’s not sufficient for making your case. If you had market-research data from 15,000 consumers that made the same point, that would be sufficient. This is a “burden of proof” point. You need to have sufficient data to get a skeptical audience to agree with your recommendation. It’s easy to get people who support your pitch to go along with less rigorous data, but they aren’t the people you need to win over. You need to have facts that will sway your detractors and your nemesis from a position of resistance to one of support. Sufficient data is the way to make that shift happen.
Using your architecture to drive your analytical efforts is an efficient and effective way to ensure you have all the right information you need to prove your case. The analytical plan you execute will be focused on bringing the right data, and only the right data, to your final pitch meeting.