Panoply Blog: Data Management, Warehousing & Data Analysis

How to Propose a Data Stack

Written by Anders Schneiderman | Sep 3, 2020 3:08:40 PM

You've spent a bunch of time figuring out the best data stack for your company.  It was hard work, and occasionally it was frustrating, but mostly it was fun. 

Now for the un-fun part of the process: putting together a proposal to convince your Higher Ups to let you build your solution.  

One of the reasons this may not be your idea of fun is that you aren't comfortable creating what is essentially a sales pitch. After all, you're an analyst, not a salesperson.

In this article, I'll walk you through how to create a proposal that will convince the folks holding the purse strings to let you build the data stack that will help your company thrive.

Refresher: What is a data stack?

Before we explore what makes for a good data stack proposal, let's take a beat and make sure you're clear on what a data stack is. You may only have a rough idea what folks mean when they use that term—not surprising given that definitions differ.

The idea of a "stack" comes from the software world. When web developers talk about their "software stack" or "solution stack," for example, it's shorthand for describing the set of tools or components that are the foundation for building their solution—e.g., the operating system, web server, database, and programming language or framework. A data stack is the same idea, only instead of building a website you're creating an analytics solution.

While not everyone uses the term “data stack” the same way, there are 3 components most agree are critical for creating an effective analytics solution:

  • Data storage: where will you store the data and how? Typically this part of the stack is a data warehouse or some other platform that can handle gobs of data.
  • Data wrangling: what tools, languages, and/or frameworks will you use to clean up the data and transform it so it's easy to analyze? 
  • Data analysis: what BI tools, reporting tools, and other analytics tools will you and other staff in your company use to find actionable insights in the data?

Understanding your audience

One mistake analysts often make before they start writing a data stack proposal is that they forget to ask a simple question: who's the audience for their proposal?

A proposal isn't an analysis, it's a tool for making a sale. And it's hard to make a sale if you don't understand your audience. 

A data stack proposal isn't an analysis, it's a tool for making a sale. 

For example:

  • Is your audience primarily your CTO, who wants a deep dive on the technical details? Or is it your company's founder, who just wants to know the bottom line and the ROI? 
  • Does the person or people you're trying to convince want just your proposed solution? Or do they want to choose from several options?
  • Does your audience think in PowerPoint slides, or is a crisp Google Doc the way to go? 

So before you start cranking out your proposal, take just a few minutes to ask your manager:

  • Who do you and/or your manager need to convince with this proposal?
  • What does your audience expect in a proposal? And what are their preferences and pet peeves when it comes to proposals?

If you're thinking, “Do I really need to waste time thinking about people's stupid pet peeves and pointless personal preferences,” consider this: You're going to be living with whatever decisions they make—including how generous or stingy the budget is for your data stack—for a long time. Isn't it worth spending a few minutes now to get the best possible shot at getting the answer you want?

Components of a great data stack proposal

While what counts as a good proposal will differ depending on the audience, odds are you'll need most of the following components.

Your (company’s) goal and how your data stack helps achieve it

Before you began working on your proposal, at some point your company (hopefully) came to at least a rough agreement about the kind of analytics culture you're trying to create—e.g., to what extent you’re going to follow a self-service strategy. In the proposal, you'll need to: 

  • Briefly summarize these high-level decisions 
  • Explain how the data stack you're recommending will operationalize those decisions

You'll also want to take any gauzy expectations that were implicit in that high-level conversation and flesh them out. Of these expectations, the most important is scope—i.e., what you are and are not promising to accomplish.

Options and your recommendation

Next you'll want to either describe your proposed solution or present several options and explain which one you think is the best fit for your company.

While in some cases you might be able to hand over your recommendations and be done with it, in others you’ll need to outline at least some of the options you vetted and an explanation of why you landed where you did.

Which approach should you choose? It depends on several factors:

  • If there is only one even remotely sensible answer, that's all you need to cover.
  • If it's a pretty close call, it's usually a good idea to lay out the options.
  • If there are objections you know you're going to need to address, offering multiple options can be a good way to do it. For example, if one of the Higher Ups is going to push you on why you aren't choosing a free solution, lay it out as one of several options in a way that highlights why you don't think it's a good fit for your company.

Some managers prefer getting a single answer, whereas others prefer having options to choose from. If there's a strong cultural preference in your organization, fit your approach to it—but only if it doesn't seem artificially forced.

When describing options and your proposed solution, how much detail should you go into? It depends on what your audience expects and what you need to explain to "close the deal." Regardless of how much detail you end up deciding you need, if you are presenting several options you should consider summarizing them in a table. Design the table so it's crystal clear what the trade-offs are and why your proposed solution is the best option. 

In fact, it might be worthwhile to begin your research on the proposal by mocking up a table. It can be a useful way to make sure you don't go down the rabbit hole on too many details and to keep your research focused on coming up with an answer you can clearly and succinctly explain.

What it'll take to implement your proposed data stack

You will also need to explain how you will go about implementing your proposed solution and provide a rough timeline.

A few pointers:

  • Add in a cushion. It's easy to get too optimistic about how long your shiny new solution will take to get up and running. Make sure you give yourself room for unexpected roadblocks and changing circumstances.
  • Break the timeline into iterations or a roadmap. In fact, it may be useful to briefly sketch a roadmap of where your company's analytics adventure will take it, with just the first phase or two covered by this proposal. This can be a particularly useful trick if you're worried about ensuring the project has a reasonable scope and need to set realistic expectations about what you can accomplish.

How much your proposed data stack will cost 

When explaining how much your proposed solution and any alternatives will cost, make sure you break it down by:

  • Initial and ongoing costs
  • Money and staff time, which should include time spent getting trained up

And as you did when providing a timeline, add in a cushion—nothing ever goes as planned.

Objections you need to address

While conducting the research for the data stack proposal, come up with a list of reasons why the people who need to sign off might balk at doing so. And then make sure that somewhere in your proposal, you address your audience's biggest concerns.

For example, suppose you're pretty sure your CFO is going to ask, “Why can't we just do all this using Tableau?” Make sure your proposal has a crystal clear answer to that question. And don't bury that answer in a paragraph where it would be easy for them to overlook as they are quickly skimming through the document; make sure it stands out.

How to structure and deliver the proposal 

Now you've got some ideas about what should go into the proposal. What should it look like?

Format your proposal to fit your audience

If your audience expects slides, do a slide deck. If they like short Google Docs, write a short Google Doc. Whatever your audience prefers, that's what you want to deliver—because, again, your proposal isn't an analysis, it's a sales tool.

Ditto for the language you use. If your proposal fits the way your company thinks and talks, you may improve the odds that you'll get a green light.

Fit your proposal to the process

It's also useful to know how you are going to deliver the proposal. Let's say the process works like this:

  1. You're going to do a detailed walk-through with your boss.
  2. Once they sign off, you'll have a 15-minute meeting some combo of C-suite stakeholders (CEO, CTO, COO, CFO).

You might decide to create a one-page executive summary, a table summarizing the options and your recommendation, plus a deeper dive. That way, you've got all your bases covered with both audiences.

Make sure you understand the approval process before you spend too much time on your proposal. Otherwise, you could end up with a proposal that is great for your boss but doesn't really work for the people who make the final decision.

Make it skimmable

For almost any audience, you can't go wrong if you make it easy to skim your proposal.

Headings, bullets, bolding—they are all your friends in the battle to get a thumbs up on your proposal.  Tables are good too.

Why is it useful to create a skimmable proposal?

The one thing you can be pretty sure of is that some of the most important people who have to sign off on your proposal are folks who spend a lot of time in meetings. In fact, they may spend most of their days in meeting after meeting. 

And while this proposal is your baby, it's probably one of many proposals they will have to deal with this week.

So create a proposal that requires as little effort as possible to understand.

Early on, practice explaining your proposal

As soon as you have a draft of your proposal, do a quick run-through where you pretend you are pitching it. Your dog won't mind and that practice could pay off big time.

Why? You're going to use your proposal to tell a story that convinces the Higher Ups to sign off. So, practice telling your story.

If you do, you'll discover which parts work smoothly, what additional details you might need to add to the proposal, and what needs to get reworked.

This strategy is particularly useful if at some point you're going to have to briefly present your proposal. The time to discover that your proposal doesn't quite work when you're explaining it is not when you've got 10 minutes with your CEO.

Stuff the rest into an appendix

As you're reading this article, perhaps there's a voice in your head that's saying, "If I follow your advice my proposal won't have all of the nitty-gritty details the Higher Ups need to understand before they sign off. There's no way I can capture the subtlety and complexity of the solution I've crafted in the ridiculously small amount of space that Higher Ups are giving me."

I feel you.

Here's my trick for dealing with the nerdy details I wish I could put into a data stack proposal when I've been told it can only be a few pages long: I put everything else I want to cover in one or more appendices.

That way:

  • I can let go of any frustrations this process is inflicting on my Inner Data Nerd.
  • If the Higher Ups really do need to know more details, I've got it written down. Then if I get questions about it during my presentation, I'm good to go.
  • Even if I don't end up referring to the appendix or appendices during the presentation, odds are at some point during the project, I'll be glad I pulled together these details.

Ask for feedback after presenting your proposal

There's a good chance this isn't the last time you'll need to put together a proposal.

So once you've presented your proposal, at some point in the next few days, take a minute to ask some of the folks who saw your presentation what worked for them and what didn't. At the very least, you'll learn some useful lessons that will help you do a better job next time...and that could help you level up to the managerial track.

But perhaps more importantly, by showing interest in what that Higher Ups think, you're demonstrating respect. And in doing so, you're helping to build the trust you will need as you build out your analytics solution

Many analysts don't bother to do this. So make yourself stand out by following up with at least some of your audience and asking for feedback.

Conclusion

Writing a data set proposal isn't fun. But if you do it right, it could make the difference between suffering through maintaining a duct tape solution and getting the resources you need to help your company thrive.