Generating and testing solutions

model for improvement

You will now have an initial set of ideas that you think will help to achieve the aim and these will be captured and structured in your driver diagram.

Although you may have some good ideas, we encourage you to get your team (and maybe other people) to think divergently and generate as many ideas as possible.

This is where you can use the creativity of the team and continue to use your open-to-anything, curious mind-set. Having lots of ideas gives you lots of options and reduces the impact of any ‘solution bias’ whereby a single idea is pursued at the expense of thinking more creatively.

There are many techniques for generating ideas, but it is likely that you will use some sort of brainstorming technique to generate many possible solutions. You should use the drivers you have identified to provide focus for peoples idea generation.


Additionally, you can encourage people to build upon ideas that have been captured. This isn’t a competition, it is collaboration. Use additive thinking (that idea + this idea) rather than criticizing or dismissing ideas.

Remember that some people may feel exposed putting their ideas forward and if they get bruising criticism they are unlikely to take that risk again and you have lost the creative input of that person for this project and probably others too.

Of course, some ideas have more obvious potential than others and it will be those that we test first, but if these don’t have the effect we anticipate, we will need to return to the ideas pool and try something else.

You will now have answered the question 'What change can we make that will result in improvement?' and are on the verge of being able to (rapidly) test your ideas.

On rare occasions you may have a complete solution idea that you absolutely know will achieve the aim. If that is the case get on and implement that idea – if you are that sure it will work, don’t waste time testing, just do it!

However, most of the time we don't know for sure what will work and that is why we use the PDSA technique.


To achieve your aim you may have a set of obstacles that need to be overcome that has an obvious priority for resolution: unless 'a' is resolved, you can't address 'b' or 'c'.  If that is the case, then 'a' is the obstacle you will need to start with and you will be selecting an idea to test that does that.

However, you may not have an obvious priority order and if that is the case, you can start with any of your ideas.  Consider picking ideas that you think will give early or obvious benefit to the people doing the improvement work as your starting point. This can give people confidence that the project will make a difference and a sense of achievement when the ideas are implemented.

In either instance there may be more than one idea that you think may help. You will need to work with the team to settle on which of these is the stronger contender.

Whatever your starting point, it is best not to try and work on lots of ideas at once - it can be done, but it is better to pick on  a single ideas and test that rapidly using the skills and resources of your team, rather than spreading your team thinly across multiple ideas.

Once you have prioritised and selected the idea that you are going to work on you are now ready to start rapid testing using the PDSA approach.

 Rapid Testing

You now have a key part of your plan; the change idea that you think will overcome the obstacle you are working on or help move you towards achieving your aim.

You may need to ‘create’ something as part of that idea – maybe you need to revise a process or work description so that people are clear on what the new way of operating is that they are testing. If you do have something to create, that all happens as part of the plan step. 

The other thing that happens as part of this step is deciding when, where, who and how long for you will test out the idea and what your expected results will be – which of your measures that you have identified are you hoping to affect or is there something else you need to measure to demonstrate you are getting the results your expected from the experiment? 

Try and keep the test periods to relatively short timescales, which is easier if you are making small changes. Remember we are trying to rapidly discover what works and what doesn’t. 

This is putting the solution into effect – finally you are experimenting with your idea, putting it into operation! You will need to keep a curious eye on how things are proceeding, making sure you are measuring appropriately and observing what happens. All of these will measures and observations will be used in the study step.

You will find yourself naturally ‘studying’ whilst you are doing, but at the end of the defined testing period you need to collate your results and see what happened. Did you get the result you were expecting? Has the obstacle been overcome? Have you moved closer to achieving the aim? If not, why do you think that was? Was this the wrong solution or does it just need a few tweaks here and there?

Again, this is a continuation of the curious mind-set, seeking to find out why something did or did not happen as predicted. 

The final step in the cycle. This is all about taking what you have learned in the study step and then doing something with that learning. If it was a success, do you now need to roll this solution out to a wider set of people?

If it was unsuccessful do you need to go back and experiment with another of your change ideas or do you just need to make some minor adjustments to this one and test again?

This iterative testing and refining of a change idea through two or more PDSA cycles is known as a PDSA ramp – literally the cycles ramping up towards a successful change:


What you can probably see is that the Act step then merges back into the Plan step as you go through another cycle of rapid experimentation.

Once you have overcome your first obstacle or tested your first change idea, you just select the next one and go again. And you keep going until you achieve your aim or reach your timebound checkpoint where you will review where you are and what your next steps will be.

Use the PDSA sheet to capture and display your work on each change idea. Capture the plan outlining what the hypothesis about the test you are going to undertake e.g.

We believe that if we [do x] then we will see [y result] which will help towards achieving our aim of [z outcome]. We will run this test for [n days / weeks / months] and study the results”.

State clearly which of the measures you will be recording and studying during this test and preferably show and capture this visually in some way – e.g. a run chart that is updated with an appropriate frequency during the test period.

The upper section of this sheet allows you to identify and records the tasks that are required to set up the plan. Assign the tasks as required and track their completion. You can’t start the test until all the necessary elements are in place.

In the PDSA cycles section of the sheet, use the ‘Do’ box to capture the in the moment observations of the test and use the ‘Study’ box for briefly outlining the findings when your team study the results ((bullet points are always helpful).

The ‘Act’ box is where you outline what will happen next – an iteration of the idea, a wider roll out of a successful test etc.