Building a business case for your company
As you are meeting with the stakeholders you identified in the preceding sections and iterating on feedback regarding your vision statement, it is a perfect time to ask your stakeholders about what is working well, what could be improved, their priorities for the coming year(s), and some of the burning challenges their team is facing. I’ve often found that asking key leaders across a company open-ended questions and deeply listening to their experiences is fruitful when it comes to identifying opportunities to help drive value for them from data governance.
For example, if a stakeholder tells you that they are having a difficult time in the board of directors meetings because the CEO is always questioning their data, you may have an opportunity to help them. Spending time unpacking the reporting process, the metrics on the reports, the definition of the metrics, how they are calculated, where they are sourced from, and the quality of the underlying data itself may expose that there are problems with the reporting going to the board. Conversely, this exercise may prove the data is accurate, and now the stakeholder is armed with strong backing from you, the leader of the data organization, to attest to the accuracy of the reporting. Often, the data is guilty until proven otherwise. It is your great privilege to support your stakeholder in providing reliable and highly trusted data to deliver their results to the board. Treat the experience accordingly.
No matter what your stakeholders tell you, the importance of these conversations is to listen. Very rarely are stakeholders going to tell you that they need better governance, or they need stronger technical metadata, or for a team to come in and profile their data more frequently. They are not going to speak to you in these data terms. What they will say is no one trusts the reporting, or I can’t get what I need when I need it. They are giving you the symptoms. It’s your job to identify the root cause to diagnose the problem and fix the underlying issue: data governance.
As you are executing these deep-listening sessions and learning about the challenges your colleagues are facing, start to identify common themes. It’s helpful to keep detailed and organized notes that you can easily refer back to, but that also can begin to group like problems together. Pulling on the preceding example, perhaps you hear from a number of stakeholders that there is inconsistency in reporting where the results sound similar, but the numbers are actually different. The executive team is now calling the data and the leader into question. You now know one of the components of your data governance business case is going to be centered around key metric alignment for the executive team. You will need strong metadata capabilities (Chapter 6) and data quality (Chapter 8) to help you, along with strong reporting and/or data analysts to help drive this alignment. Most importantly, you need to bring people together and drive consistency.
As you are preparing to write your business case, your listening sessions will produce themes, and you will center your delivery around the strategic implementation of capabilities and iterative delivery (sometimes referred to as quick wins) to show progress throughout the delivery. As you build your business case, be sure to highlight what your building blocks will be (that is, the components in Part 2 of this book) and the iterative delivery you will enact to drive impact along the strategic journey. As you iteratively deliver for your data domain executive in alignment with the themes you’ve identified, you will turn challenges into wins, naysayers into advocates, and you will become the trusted advisor the company needs to deliver excellent data governance for the company at large.
As you start to build out the business case, which you will do iteratively as we work through this book, there is some good news: you have already made progress. The preceding items are key components of your business case. You will need to include the following:
- Your company’s strategic vision and objectives
- Your team’s mission statement
- Your data governance program mission statement
- Your powerful objectives
From here, you can start to frame out the programs you’ll need to launch for your business case. At this point, you won’t know what most of them are; however, you may have already begun to identify thematic issues or problems through your stakeholder listening sessions. Perhaps you already know your company does not have a data catalog or a way to measure data quality with transparency. You can start to plot out the capabilities you will need to deliver as “Programs.”
I prefer to use a memo format to define a business case. The six-page memo is a strong format for delivering depth of content without losing your audience. Some companies pitch by using slides. You will need to determine which format is best for your company’s culture. No matter how you decide to pitch, writing a memo is a good exercise to ensure your thoughts are solid going into the business case process. Ultimately, how well you write your business case will determine your degree of buy-in from stakeholders and your degree of funding. An example template for a business case may look something like the following:
Figure 1.9 – Business case template
I suggest you put together this framing now, and as we go through the remainder of the book, fill in the business case for what you need for your company. As you gather information from meetings with your stakeholders, make notes and start to build your business case over time.
The fact that you have picked up this book and are working through it is a huge step on your journey. Continue to read, chapter by chapter, and execute the steps as we go. You can move as quickly or slowly as you need to in order to go at the pace you need at your respective company. Use this as a reference, a guide, and most importantly, the framework for how to deliver strong data governance at scale. Before we move into the next phases, it’s important to discuss a final constraint: when and when not to launch your program.
