What is a good use case?
From our experience, here is a non-exhaustive list of the key elements of a good use case.
A use case can be measured
Without measurement, it is impossible to justify identifying areas for improvement. This means that for each of the actions identified in the use case, measurement indicators must be defined.
- From a micro point of view: the very concrete contributions of deploying a metadata catalog solution, for example: uses of sensitive data, data accessibility, applications containing sensitive data, uses of personal data, etc. Beware that this can quickly turn into a race to complete, which is not very interesting. It is therefore essential to introduce two elements: temporal notions in order to avoid the soufflé and more cultural elements (access to the platform by population, return to the platform, use of a functionality...)
- From a macro point of view: evolution according to the axes of data governance identified with a maturity matrix. We evaluate the Data maturity, we set priority actions and we measure the before/after evolution brought by the use case.
This will also allow us to verify that the actions identified are sufficiently pragmatic. For example, actions such as "better decisions" or "better data quality" will be difficult to measure
A use case has a defined scope
Data perimeters are often complex. It is therefore essential to limit the scope of the use case in order not to get lost. This is despite the power of connectors that facilitate data recovery. The objective is not to create hundreds of thousands of data but to make the most important ones understandable. At least at first!
it must be transverse: IT & BI users are often already convinced of these approaches, but expect a lot of business feedback. Therefore, we need to find use cases that allow us to integrate this population. This way, we can multiply the points of view and facilitate the integration into daily life.
A use case is marketable
This is one of the weakest links in the data governance process. You have to be able to create a certain attraction, a certain excitement. Pragmatic use cases (quickly attainable objectives, concrete and measurable actions...) are a key element of this excitement.
Key success factors of a use case
Choosing your battle
The creation of a use case is interesting in that it allows us to identify the pains of the teams in the field and to associate actions with them. This brings us back to a subject that is dear to us and that we often hear about: is a Top Down or Bottom Up approach better? Of course, the top down approach allows for a certain legitimacy that is very appreciable in this type of approach. But we have noticed that it is often an off-the-ground approach, the business justification is difficult to identify. The soufflé falls back. The Bottom Up approach has the advantage of being rooted in the daily life of the players by responding to specific pains. The difficulty is then to position these actions in a coherent logic to support the business objectives. So, according to a DataGalaxy expression, "Think big, act small".
Iterativity and incrementality
As seen in the previous article, each organization has its own level of maturity and its own constraints. It would be illusory to try to move from anarchy to data governance 2.0 at any cost. The use cases must therefore take this reality into account and place data governance in a certain pipeline logic. Each new use case complements and extends data governance: it addresses a different domain, completes the previous one, reaches a different population, etc.
How to formalize it?
Here is an example of a template for describing your use case.
Once you have identified the objective of your use case, what you want to do and for whom, you can then market it with a short tagline:
- I want to perform an action CONTENT
- so that a population of BENEFICIARIES
- obtain a gain in productivity or quality OBJECTIVES
Of course, you will also have to adapt it to your context (is the approach tool-based, for example) and complete its description with
- Functional referent holders for this project
- A core deployment team
- KPIs to objectify it
- A business domain
- A schedule
- …
We represent these use cases in the form of two slides: The first one allows us to facilitate the presentation of the use case
The second is the one that allows us to describe what we really want to answer. It can be based on a customer journey of the data user.
What might it look like?
Here are two examples from two very different companies. Each of them has of course taken the time to describe, in other slides :
- The stakes / why it is necessary to manage this data, if possible by giving a strong business context: contribute to operational performance, meet regulatory requirements, meet new challenges...
- Project expectations: how this use case will meet the challenges
- Where they wanted it to go in order to give a target
- Pragmatic elements about the project: team, process, schedule...
Here is a first use case for a BI project
Here is a second use case for a compliance / churn calculation project.
