It’s the need that generates the model

(Not the other way around!)

Table of contents

∘ Introduction
∘ What does “the need generates the model” mean?
∘ Do you recognize yourself?
∘ Ask yourself the right questions
∘ How do you ensure that the need generates the model?

Introduction

“It’s the need that generates the model — Not the other way around!”

This is the phrase I uttered spontaneously more than 15 years ago during a pre-sales meeting for a BI solution, in response to a prospect who asked me if we offered ready-made reporting models.

Hah! How many prospects have asked me that question?

Apart from the fact that I told them it was easier to knit than to unknit, I’ve adopted this answer to many of the questions that prospects ask themselves when it comes to implementing a data tool, as well as customers bogged down in the realization of their data project, or simply despairing over the non-adoption of their data solution.

What does ‘The need generates the model’ mean?

Over the years, I’ve changed the formula to: “It’s the need that guides the modeling,” “It’s the need that determines the content,” “It’s the need that determines the project,” and so on.

It’s clear that the need is at the heart of all data projects.

Do you recognize yourself?

• “I’ve implemented a data cataloging solution, but users make very little use of the application.”
• “We have implemented a master data management tool, in which we have put a maximum of reference data, but users continue to use and exchange Excel files with each other.”
• “We have set up a complete reporting system with all the KPIs we feel are essential for monitoring our organization’s activity, but usage statistics show that users have gradually stopped using it.”
• “We have created a data lake with a maximum of data, with the aim of satisfying as many of the organization’s potential data needs as possible. However, we regularly receive requests from users who can’t find the data they need.”

etc.

I could write a novel just on the symptoms described by my prospects and heard from my customers about not using their data application.

Ask yourself the right questions

• Have you met your users’ needs?
• Have you solved one or more of their problems?
• Are they interested in using the solution?
• Have you listened to their needs?
• Did you put the need at the heart of your project?
• Did the need generate your model?
• (Bonus: Was the project driven solely by IT?)

How do you ensure that the need generates the model?

1. Get people involved
   A good data project is one in which the future users of the solution are involved from the outset and throughout the project:

• Appoint a functional/user project manager
• Appoint key users: Identify and select the users who will drive the project.
• Involve users in key phases of the project: Needs analysis, design, acceptance, deployment, change management, adoption, etc.

Don’t hesitate to work in small iterations, to enable ongoing validation of the future data solution by key users.

This is not a question of forced validation but of genuine collaboration between the producers and future consumers of data.

2. Know how to listen
Taking user needs into account is the key to successful data projects.

And we’re not just talking about “functional” users here, but all the people who use data, from those in charge of maintaining data flows to reporting users, Data Analysts, and Data Scientists.

It is therefore important to identify and listen to the needs of all these users by carrying out interviews and prototypes to involve them in strategic choices.

3. Understand the changing needs
Data projects evolve the most over time and therefore require constant adaptability and attentiveness to user demands.

• “I need a new indicator!”, “I need a new report!” — What are the consequences of these evolutions on my decision-making chain? What impact will they have?
• “We’re integrating a new entity into our organization, and this represents a new source of data in our customer repository.” — What impact will this have on the supply of data to our MDM customer repository? Do we need to review our matching rules?
• “We need to document the data products made available to data analysts so that they can independently choose the right data source for their work.” — What level of detail is required by table or column? How do we involve users in the documentation of these data products?

4. Let’s be agile
Needs that evolve over time call for agility.

Listening to needs and taking them into account in modeling and in what we deliver to users is essential, but so is relying on agile tools to be responsive and maintain user involvement.

Conclusion

Your choice of data tools should focus on agile solutions that are easy to deploy and implement so that realization is not a hindrance but the simple application of the need you’ve taken the time to analyze with your favorite users!