The way to prepare an organization for a data-driven future is to collect use cases. These small business cases describe: which decisions you took, what data you need, and how this contributes to the strategic objectives of the organization.

Let me tell you the four essential, most overlooked steps to build a great use case.

1. Determine the business goals.

Mapping the ‘why’ is the most important factor. Everything an organization does must contribute to the goals of the organisation. Do not confuse this with the aim for the highest profit. Profit is a consequence, and often also a condition, for achieving the set goals. The business goals are the why of an organization; Why do we do what we do?

If you know the why, you can asses how a use case helps the organisation forward.

If you have to choose, or order many use cases, priorities should be set based on the value for the organization.

Let me give you an example about an international furniture company. Their vision is 'to improve the daily life of its customers'. This high level goal translates all the way down to the every day operation. It determines the way products are made. It determines and which products should have a place in the shop. It determines the shopping experience in the store and on the website. This vision is the base of everything.

This means that all the services the IT department delivers must serve this vision. The co-workers in the store rely on the IT services for their prompt and expert response to customer inquiries. The priority of your use case is thus determined by the impact it has on the experience of the co-worker and customer.

In this example an update to an application, which improves the store experience is more important than an improvement to a tool used only behind the scenes.

Make clear how the use case connects to the why of the company.

2. Look at the value chain.

A business process often consists of a series of actions in which those involved have different wishes and needs. A good use case takes into account this entire chain of actions and meets everyone’s needs. In an organization, a large part of the chain is now executed by technical processes. Payment, stock, planning and logistics systems are involved in the sale of a sofa by the furniture manufacturer. In addition, supporting processes such as marketing, the service desk, and an IT team are also needed to provide technical and operational support.

It is therefore essential to map the entire chain in order to ensure that everyone’s interest becomes measurable and transparent.

For example, you may discover that a capacity problem at the service desk has several causes. An important factor seems to be that HR has a hard time finding enough people with the right skills. In addition, it also appears that the current test team did not grow as fast as the number of software developers. Hence, the quality of the software has deteriorated, which means that the service desk is burdened with more user questions.

3. Determine the risks, costs and revenues.

A use case can contribute to the business objectives in various ways. The most important factors are:

• risk,
• costs and
• revenues.

In order to achieve an increased return in the short term, you search for the use case that, with little effort, will reduce the costs, increase the revenue or lower the risk exposure.

It is almost impossible to not make assumptions or to not use estimates in a use case. This isn't a problem. Embrace the uncertainty, make it measurable and tranparent.

4. Provide a clear scope.

To determine, and especially stick to, a scope is always a challenge. This isn't different when you define a use case.

Therefore, determining the scope is really important, from start to end. We have to define the technical systems, the associated processes and procedures that are and aren’t involved. Identify specifically what is inside and outside the scope. Keep in mind the interests of the various parties involved in the use case, what may be self-evident for one person, may need to be clarified for another.

An earlier version of this article was originally written for and published by SMT