From Data to Decisions:Engaging Stakeholders Earlyfor Maximum Impact

This article will make the case for early stakeholder engagement in data projects. We begin by discussing the concept of data value quantification and its crucial role in justifying investments.

We’ll then explore the traditional approach to data projects, highlighting common pitfalls. We then present strategies for effectively engaging stakeholders early in the project lifecycle, drawing on real-world examples.

Finally, we emphasize the importance of connecting data initiatives to real-life business processes, ensuring long-term success and continuous improvement.

Data value quantification is the process of assessing and measuring the financial and operational benefits derived from data-related initiatives. According to the Enterprise Data Management (EDM) Council’s ROI Working Group, data value quantification involves “the systematic evaluation of data assets in terms of their potential to drive revenue, reduce costs, and improve efficiencies within an organization.”

For instance, a retail company might use data value quantification to evaluate the potential benefits of implementing a customer data platform (CDP). By analyzing customer purchasing patterns and preferences, the company can personalize marketing efforts, leading to increased sales and customer loyalty. Similarly, a healthcare provider might quantify the value of integrating electronic health records (EHR) with advanced analytics to improve patient outcomes and operational efficiency, thereby reducing costs associated with patient care and administrative tasks.

Quantifying data value is essential for several reasons.

First and foremost, it helps organizations justify investments in data management initiatives. Many foundational aspects of data management, such as metadata management, data catalogs, and data quality assurance, theoretically make sense, but at what cost? When it comes to making tangible investments in tools, technologies, or personnel to implement such initiatives, you face the challenge of demonstrating the expected (and later realized) added value.

A majority of data governance activation projects follow a variation of the following. They tend to be led or sponsored by a data leader, such as Chief Data Officer, Head of Data Strategy, or a more specific role like Data Quality Lead or Data Catalog Lead. These leaders have a particular vision and understanding of best practices in the data management field, and they conceive of the program and its requirements based on these best practices, aiming to address the issues that the organization faces. Often, they seek the costly support of external consultants early in the journey.

Initially, transformative funding is made available to kickstart these projects. This funding comes from a general acknowledgment within the organization that “something needs to be done” about data-related challenges. More often than not, it comes from a discretionary pot of money that, for example, a CIO has. At this stage, business users might be involved in initial discussions or kickoff meetings, but their engagement tends to be superficial. Many business users have had negative experiences with previous data governance projects, viewing them as burdensome costs.

As the project progresses, typically several months to a year in, the initial transformative funding runs out. At this point, the project requires additional funding to cover ongoing costs, tool implementations, and potentially hiring people for specific roles. That initial, transformative funding is not endless – it’s usually there for projects that are supposed to be time-bound. It’s very common that they fund a so-called “pilot” or “proof of concept.” But after that initial phase, the funding needs to come from somewhere else. And however many times you turn the situation over, that funding needs to come from an organizational unit that earns revenues – i.e., the much-feared “business.”

The corresponding business leaders were not deeply involved in the early stages of the project. They will review opportunity costs as this funding would compete with other initiatives. These leaders might have been content to support a project already funded from an enterprise perspective but are hesitant to contribute their own departmental funds.

The result? The program stalls.

I can’t emphasize enough how exceedingly common this scenario is.
I’ve seen it over, and over, and over again.

For instance, a leader in a financial institution I knew, oversaw a multi-million-dollar investment to document and maintain metadata in a technical data catalog. Despite the substantial investment, two years into the initiative, the data catalog showed minimal usage, with shockingly on average just a handful of active logins per month. The lack of engagement indicated that “the business” was not leveraging the wealth of metadata gathered. Consequently, when the organization tightened its budget and funding became less liberal, this leader failed to justify continued investment in the program.

In such situations, the initiative leaders often take ever more desperate steps to engage their business counterparts. Roadshows are planned, socialization sessions are set up, and individual business leaders are sought out. In some cases, external consultants come in to help write a business case for a given capability.

I’ll admit that I’ve been part of such engagement several times.

They aren’t fun.

Now, the issue is not that no value can be added.

The problem is that substantial costs are sunk into a solution before validating with those impacted whether the identified challenges are real and if the proposed solution truly addresses them.

Now, the argument I am putting forward here is simple, and it’s perhaps close to a cliché: engage the business early. Early engagement leads to better-defined use cases. It ensures that from the very beginning, before a proposal for funding has been drafted, the focus is entirely on the possible business impact. The first task is to understand the respective business processes and use cases. What is being done, produced, or delivered, and how is data playing a role? Are there any data-related pain points or gaps?

Recently, I had the pleasure to speak to a well-credentialed Group Chief Data Officer of a group of companies counting more than 50,000 employees, who was about 1 year into his role. I asked him how his value-driving journey had gone so far, expecting the common answer dripped in disappointment. But he perked up and told me that he had had fantastic traction across various large business and functional areas. Examples of successfully enhanced use cases included leveraging data analytics to optimize investment strategies, improving risk management with predictive modeling, and enhancing client advisory services through better data integration. He specifically emphasized to have great 1:1 relationships with ~5 individual business unit leaders, who each had shown remarkable interest and continued enthusiasm into the data program.

I asked him when and how he engaged his business stakeholders, to which he answered that he started in his recruitment process (!). He had to go through a fairly long series of interviews, and in these sessions, he had shared that he had no interest in a job where he would not be able to drive real change.

When various executive business interviewers asked him what he would do, he simply turned the question around: what would you like me to do? What would help you?

From there, the pattern was set.

It worked.

For the most part, there is no secret methodology here. It’s a simple as identifying the business unit or functional leaders and asking them a few questions. In fact, especially in the beginning, the simpler, the better. No slides, no demos – focus on the business context.

One recommendation is to separate the understanding of the use cases from the data-related analysis. For example, if it has been determined that a company cannot create effective customer segmentation because data from different sources cannot be linked together, the first step is to thoroughly understand the use case. Articulate this understanding clearly—don’t settle for a mental check. Ensure the use case is explicitly defined and described. Describe at a high level what is being done and how it drives value.

Also ask the business stakeholders about the impact.

In the case of the segmentation, how much could customer experience increase, how much could churn be reduced, how much could cross-sell be increased?

This step is extraordinarily critical now.

It is very tempting to dive into practical solutions for the data integration problem, but if you cannot articulate a defensible value rationale at this point, you will not be able to build your business case later on either. The business case for the data capabilities will have an upper bound that is equal to the value of the entire use case, as only a part of that value can later be attributed to the data solutions. My advice is to make this a hard go/no-go tollgate: if you do not have a strong value rationale that is supported by the business, do not proceed.

This first hurdle is the most substantial one. Once you have a clear value statement, then business buy-in will be guaranteed. Moreover, because the expected outcome is clearly quantified, throughout the program, solution requirements can be much more transparently reviewed.

Once the initial kickoff is successful, don’t hang back, but maintain stakeholder interest. It is critical to sustain the initial engagement. Don’t have people drop off your radar after you’ve initiated the journey.

Circumstances and requirements change, leaders come and go, so stay in touch.

It’s much easier to incrementally alter the plan than to have to do a major overhaul every year or two. Regular updates on progress and highlighting key milestones are essential. Be deliberate about soliciting feedback to see if the experience is living up to the initial expectations. You care about that win on the board, so make sure you stay close enough to intervene as needed. And when you get that win, of course, celebrate the success.

It is also critical to translate the initial value statements into metrics so that you can prove them later on. Refer back to the segmentation example from earlier on – how could we measure the increased revenues through enhanced segmentation? By setting clear metrics, you can demonstrate the impact and justify further investments.

A final, much-overlooked capability is that of true business process reengineering. Pulling data into a data platform and building a statistical or predictive model is one thing. It’s entirely another thing to pick up actual business processes and rewire them to now depend on new data inputs. In our segmentation example, if different segments predict opportunities for cross-sell, how are these insights structurally passed along to the right person (the call center agent or the sales rep) at the right time to act on it? Too many AI and ML models strand in test environments not because they don’t have potential, but because the organization does not have the capability to redesign and reengineer currently active, mission-critical business processes.

Recently, I worked with a data governance team of a globally operating tech company that struggled to drive a data management operating model across their divisions and regions. One team stood out as significantly more successful—the team managing a set of data products powering their e-commerce processes. Upon reviewing the context and relevant stakeholders, it became clear why. They operated with a true product mindset, including sending celebratory emails about new functionalities and sharing quantified user engagement metrics.

Keeping the right stakeholders engaged was their forte.

In summary, an important key to successful data initiatives lies in early stakeholder engagement.

By involving business leaders from the outset, clearly defining use cases, and translating value statements into realistic metrics, organizations can build a compelling business case and ensure ongoing support.

And perhaps don’t forget, this can be one of the most fun parts of the project. This is where you can be creative with all options still open. Make sure you launch that project that you’ll enjoy working on in the next 2 years and being reminded of in years after that.