Growing your data program with a use-case-driven approach

How to Bridge the Gap Between Strategic Vision and Tactical Execution in Data Initiatives

In recent years, the growing value of data in business is undeniable. At the heart of harnessing this value lies the data program, a crucial part of any organization that develops processes and frameworks to capitalize on data. The success of these programs is typically measured by maturity levels, which indicate how efficiently data is transformed into tangible value (data maturity test example).

As a first step, it’s essential to craft a long-term vision for the data as a valuable asset. Then, a high-level roadmap to realize this vision should be defined, which is typically the outcome of a data strategy exercise. However, despite the importance of such an exercise, creating a vision and strategy isn’t enough. The real challenge, and often the most complex aspect, lies in the execution phase — turning the strategy into real changes within the data program. This phase can be tricky and full of potential obstacles, as theoretical plans will meet the realities of organizational dynamics and technological constraints.

In this post, we propose an effective approach to navigate these complexities and transform the long-term vision of the data program into reality.

The planning-building spectrum

Once a long-term vision for the data program is established, the next step is transforming this vision into a concrete, operational reality. The activities necessary for this transformation can be grouped into two fundamental categories: planning and building.

• Planning encompasses the design, preparation, and architecture phases. It’s often the domain of managers and architects, resulting in extensive documents and slide decks that outline architectural frameworks and conventions.
• Building, in contrast, involves the actual implementation that affects the end-users. This phase is typically managed by technical teams who develop and build the platforms and algorithms necessary to gather, process, and utilize data.

Here, a key question is how and when to allocate the resources to these two categories. For example, you might start with detailed planning of how you want the whole data program to look before actually building something. Or, begin with building to quickly gather insights and then adjust your plans accordingly. This decision about resource allocation — whether and when to focus on planning, building, or both together — is a crucial factor for the success of your transformation.

In the following, three different resource allocation approaches are discussed.

Planning without building

Consider the situation dominated by excessive planning and designing, with minimal emphasis on execution. Although it might seem unlikely, this imbalance is surprisingly common. While planning is essential, excessively prioritizing it over building can lead to several issues:

• Rapid Technological Changes: In the fast-evolving tech landscape, waiting too long for the ‘perfect’ solution can mean missing out on newer, more effective tools. This endless chase can prevent any real progress. Remember, “Perfect is the enemy of good”.
• Theory vs practice: Plans that look flawless on paper may not translate well in the real world. Prolonged planning without testing can lead to investing time and resources in strategies that ultimately don’t work. Remember, “You know nothing until you’ve deployed to production”.
• Value vs Cost: Excessive planning without implementation doesn’t generate value, but rather consumes resources, leading to inefficiency and increased risk.

Figure 1 illustrates the data program’s costs and value creation over time for an excessive planning scenario. At first, there are high costs associated with extensive planning and architecting, whereas value is low as nothing is built yet. In a later stage, the implementation starts and value can be created. If everything goes according to the original plan, the value creation happens efficiently and cost-effectively leading to stagnating costs and strongly increasing value. However, it is crucial to recognize the ‘if’ in this scenario as deviations from the original plan are common in real-world projects. Hence, in this approach, the potential value is kept behind a barrier of risk because of the large delay between the planning and the actual building.

Figure 1: value and cost as a function of time for the scenario where excessive planning is applied.

Building without planning

On the other extreme side, an approach of rushing into the building without adequate planning is followed. This method can yield quick results, but is full of challenges that can jeopardize the long-term success of the data program:

• Misaligned Goals: Without proper planning, there’s a higher chance of disconnect between technical solutions and overarching business objectives. This misalignment often results in efforts that do not contribute effectively to the company’s strategic goals or fail to address key business challenges.
• Integration Challenges: When solutions are developed rapidly and in isolation, integrating them becomes complex, resulting in inefficiencies and potential system conflicts.
• Scalability Issues: Building solutions without considering the bigger picture can result in systems that function well initially but struggle to adapt as needs evolve and scale. This short-sighted approach can lead to significant hurdles in future expansion and adaptation.

Figure 2 illustrates the generation of value and cost associated with a building-first approach. Here, value is generated quickly as pipelines and analytics are implemented from day 1. In addition, there is reduced cost due to less planning work at the start. However, as time passes, implementing more use cases typically brings a lot of overhead to these systems. In the end, there are difficulties with integration and maintenance, leading to elevated costs and a hard time when building new use cases. As a result, value saturates and costs start to increase, indicating an approach that is not sustainable nor scalable.

Figure 2: value and cost as a function of time for a scenario with excessive building and little planning.

Although this building-first approach might not seem like the solution for developing a complete data program, it can be a valid approach for scenarios where sustainability and scalability are less important and when rapid feedback is crucial. For example, building POCs or exploring/testing new technologies are ideal for this approach.

Embracing a use-case-driven approach

As discussed above, it is clear that “overthinking” the perfect architecture and diving straight into the problem without planning probably both don’t work. Here, we advocate for a hybrid approach that blends planning and building into a dynamic and iterative process, where both activities happen simultaneously and not sequentially. It might seem logical; nevertheless, this is often not how it flows in reality.

To successfully implement a hybrid approach, a multidisciplinary team is essential. This team should comprise individuals who understand the business aspects of the company, those with a comprehensive view of the data program, and technical experts capable of building solutions. This multidisciplinary team then takes on both planning and building activities.

It is not recommended to plan and build the whole data program altogether. Instead, the big transformation should be split up into digestible use cases that represent end-to-end projects with direct value creation. Considering this, a use-case-driven approach can be followed where every use case can be developed independently.

This use case development should be executed by the multidisciplinary team for which the use cases give guidance and a common goal. The team should do both planning and building activities. The planning activities initiate the process by defining hypotheses and proposing solutions, which are then implemented, tested, and validated by the building activities. This use-case-driven, hybrid methodology is illustrated in Figure 3.

Figure 3: schematic illustration of the use-case-driven approach to elevate your data program to the next level.

Applying this hybrid approach not only addresses the pitfalls of the extreme scenarios discussed earlier, but also offers additional advantages:

1. Testing and Validation of Assumptions: The assumptions or hypotheses set by the planning activities, upon which their architectures or models are built, can be tested and validated by the building phases early on.
2. Inspiration Through Prototypes: The technical team can rapidly develop POCs that inspire and inform the planning team. These POCs can reveal new insights and spark ideas for further enhancements in the data program.
3. Adaptive Problem-Solving: The use-case-driven approach allows for adaptive, responsive problem-solving. As new challenges or opportunities arise during the implementation, it’s possible to quickly adjust strategies and actions, ensuring the data program remains aligned with current business needs and technological advancements.

Figure 4 illustrates the data program’s cost and value when transforming it via a use-case-driven method. The cost curve starts with a “bump” that reflects the planning and building of a first use case. This first use case then results in a “bump” in the value curve once completely implemented. Hereafter, a next use case is implemented, and so on. As a result, the high risk of the excessive planning approach is mitigated as use cases are directly built. Moreover, sustainability and scalability are assured as there is a planning phase before the actual implementation for each use case. In the long term, this approach leads to an effective transformation of the data program with rapid and cost-effective onboarding of new use cases.

Figure 4: value and cost as a function of time for the use-case-driven approach.

Conclusion

When transforming a data program’s vision into a reality, we recommend employing a use-case-driven approach that encompasses a balance between planning and building. This use-case-driven approach should be led by a strong multidisciplinary team with business knowledge, data skills, and technical capabilities to plan and build end-to-end use cases. This approach brings value from the start, reduces risks, and ensures flexibility and adaptability.

• 👏 If you liked this article, don’t forget to clap!
• 🗣️ Share your insights in the comments.
• 👀 For more about Data Minded, visit our website.