A Design Sprint is a structured method of rapid improvement in the service sector. It can obviously be applied in the manufacturing sector.
The organization quickly tests a solution to a problem. It then decides whether to proceed with the proposed solution. Each team member developed skills and got to know other people. It is therefore beneficial for all, even if the solution is ultimately not implemented.
When you want to improve the way you do things, you can use a small step approach (Kaizen) or a breakthrough approach (Kaikaku). The Design Sprint is an improvement by breakthrough. It takes place over a week.
This methodology brings good results, especially when the terrain is favourable.
When to use the Design Sprint?
- After several small improvements, your teams want to solve a bigger problem.
- Your team has been struggling with the same problem for some time and can’t find a solution. You want to change your approach.
- An external factor (regulation, customer complaint, update of another system) requires you to find a solution quickly.
- You are developing a new product or service, everything is fine, but you have critical questions. What will customers think? What is the best technology?
- You need to define the strategy for your organization or project.
- You are wondering if you should offer your products or services in a new market.
In all these situations, you want to make a decision quickly. Unfortunately, it is complex. There are many things to consider and you don’t know where to start.
Before you get started
Obviously, first of all, you’ll have to assemble a team. You must identify the members of the work team. You want a variety of profiles, from different sectors, who work directly on the process, product or service you are asking about. Finally, you will need to find support, as high up in the hierarchy as possible. It will be easier to have “dedicated” resources for a week.
Now you want the best ones, and their managers don’t want to lose them for a week. To negotiate more easily, you could schedule 6 hours of work per day. You give each team member the first hour of the day to handle emergencies in their area.
The Design Sprint methodology is based on PDCA, nothing new in that, except for a vocabulary more specific to the service sector. However, the Design Sprint only deals with the first three steps: Plan Do Check. As in any blitz-type workshop, the idea is to have a functional solution at the end of the week. Corrections, improvements and decisions related to the solution will be made later. The “Act” is realized in a second step.
The Design Sprint in detail
Day 1: Understand
As always, start by stating the problem to be solved. Easy? Not really. Indeed, the problem is often a matter of point of view. You have to get the team members to agree on the problem to be solved. Although the sponsor may guide the team, the definition of the problem belongs to the team. For the team to have the intrinsic motivation to solve the problem, they must define it on their own.
Does one day seem like a long time to define a problem? Once again, not so much. As they define the problem, the team begins to solve it.
If I had an hour to solve a problem, I would spend fifty five minutes defining the problem and only five minutes to find the solution.
Albert Einstein (1879-1955), German, Swiss and American theorist physicist
How do I define the problem? You can:
- use brainstorming,
- analyze data (in the spirit of Six Sigma),
- listen to customers,
- walk the process (Gemba)
- question specialists
Once defined, write the problem in huge on a sheet of paper, so everyone will see all the times. The goal is to stay focused on your problem.
Day 2: Diverge
During this second day, you will find as many solutions as possible to the problem. It’s time to pull out the magic wand and imagine the perfect solution.
We are in a creative day, to stimulate the brains, you can settle in a different place: a coffee, a Lab or simply outside. Anything is possible, so treat yourself.
You will cover whiteboards with diagrams, black out Post-its and paper with your notes.
Day 3: Decide
It’s the hardest day. You will select a solution, among all those imagined. What is the best option? Everyone will be the advocate of his favorite. So find indicators, voting points, a measurement grid to choose a solution. It is possible at this stage to build a solution, but it will only be a combination of solutions discussed the day before, or an adaptation. The risk on the third day is to start over with new ideas.
Go back to your problem, what is the best solution to solve this problem? Remember Occam’s razor, it is often the simplest the best. In any case, it will be easier to implement.
Day 4: Prototype
Get to your pencils! You will prototype the solution, the proof of concept (POC). Obviously, this will not be the final solution. If you have a web-based solution, you will be satisfied with a PowerPoint presentation, possibly with a few links to simulate your solution. For a product, cardboard, scissors and glue will help you model it. If it’s a concept, you can use your artistic talents or go find images on the web to better explain it.
The objective of the prototype is to be tested by the customer. You have identified the best solution, but it is the client who will decide in the end.
Day 5: Test
To conclude the week, and get feedback, you will validate the solution by submitting it to users. Ideally, real customers will test the solution. They will tell you if it solves the identified problem.
At the end of the day, you will decide: we keep, we discard, we improve, and then everyone will go back to their routine the following week. At the end of the week, you will have completed the first 3 steps of a PDCA cycle.