Solution design

Step 1

Define the problem

Don't start with designing

Over the years I’ve seen presentations of wonderful solutions but there is always a percentage of solutions that lack a problem.

A marketing teacher once showed me an electric fork and the story behind it that they also went to a restaurant and asked for a table close to a wall outlet. Part of the story was that they showed the prototype. Nobody questioned the necessity and the waiter went for a long extension cord. 

The majority of solutions start with a problem but a good designer tries to grab the question behind the question. You’ll need to ask nagging questions like “why is it a problem”?

Be aware of workarounds, be aware of the business value of the process that shows problems. Try to reach for the true causes. 

Once you agree on the challenge and the impact, the next thing is a preliminary business case. 

A business case captures the reasoning for initiating a project or task. It is often presented in a written document, but may also come in the form of a short verbal agreement or presentation. The logic of the business case is that, whenever resources such as money or effort are consumed, they should be in support of a justifiable specific business need.

Peek
Observe the process and identify the problem or challenge.
So often it happens that people have wonderful ideas but they lack a problem.
Boundaries
Determine what demand is determined by internal business policies, strategy and guidelines, compliance guidelines, legal demand
Grow
Step by step, get to a working and approved and embedded solution
Reflect
Observe the outcome of the embedded solution, does it solve the problem and can it be improved?
Previous slide
Next slide

Focus on input and output and accept that what happens in the black box is the domain of the mature professional. Process steps are part of a sequence and depending on the demand, the consultant can dig in deeper by opening the lid of the black box and identify finer granularity of process steps.

Wim
about granularity

Know the process

A valuable instrument in getting the true information about a process is the model of a use case. This use case has:

  1. A meaningful title.
  2. A brief description to provide context.
  3. Description of the input with all possibilities (this is not a description of prerequisites).
  4. The main flow ( sometimes called the happy flow) is described as a sequence of steps.
  5. Alternate and/ or Sub flows are also described step by step.
  6. Description of the output with all possibilities.
  7. Primary user (1 actor or person initiating the process).
  8. Secondary users; other actors involved as receiver, co-operator, advisor, validator, decision-maker.

Determine the design space

Design is all about creativity. But how much design space do you get?

This phase/ section is about the inventory of:

  1. Strategy.
  2. Money.
  3. Priority.
  4. Legal matters and business standards (compliance).
  5. Internal business rules.

These aspects present your boundaries and sometimes they appear like a complex jungle but when you find the open spot, there you got your design space. Some additional space can be bargained; think of a budget, internal business rules, and strategy but other rules give hard boundaries. 

The realization that you are designing.

There have been intensive discussions with all stakeholders. You should have found a sponsor outside of IT. After all, content and process logic are the property of “the business” and agreements have been made, frameworks have been set, but during those conversations you probably already felt the almost irresistible urge to present a solution.

Now is the time to do that. Take the time for that. Summarize what happened and what your observations are. Make it clear which frameworks you have determined and how you will use the space within them.

Accept that there will not be a wave of enthusiasm immediately because you are presenting a change and they are often seen as threatening.

You present your solution from an attitude of: this is going to happen. Do not ask for permission because it is your role to take those worries off your hands. Of course you first discussed that solution with your sponsor/product owner.

Petroleux

Realize your ideas

This is the moment when you will experience that everything that is done before is worth it. The basis for a functional design is on the table and can be further elaborated. Don’t think that everything has already been determined to the decimal point; keep flexibility or agility.

I have great experience in an approach that starts with an awareness and demand assessment. When your user representation has done the awareness session they are properly equipped to have a seat in the governance organization. 

One of the fundamentals of proper IT governance is a true demand and supply approach. This enforces the business to accept ownership in content and business logic.

The result is the outcome of a properly managed realization process.

Reflect on what you have done

It’s a cyclic process; supporting processes with services like IT assets.

Give the users a few weeks to work with a properly presented solution in a well-balanced adoption setting.

Don’t ask for reflection right away but make the users work with the tooling and get used to it.

But you’ll get to a point where you need to ask for at least two questions

  1. Have we created a tool that is of added value for the process that you are working on?
  2. Can we enhance it, what are the flaws in the current tools, and when there is sufficient budget, you can look at the release calendar and decide what the next features will be?

It’s never ready!