See also: Testing Changes, Linking Tests of Change, Testing Multiple Changes, Implementing Changes, Spreading Changes.

1. Stay a cycle ahead.
   When designing a test, imagine at the start what the subsequent test or two might be, given various possible findings in the "Study" phase of the Plan-Do-Study-Act cycle. For example, teams that are redesigning same-day admission criteria should also be planning how those criteria will be applied. 
2. Scale down the scope of tests.
   Dimensions of the tests that can be scaled down include the number of patients, doctors, and others involved in the test ("Sample the next 10" instead of "Get a sample of 200"), and the location or duration of the test ("Test it in Operating Room #1 for one week"). 
3. Pick willing volunteers. Work with those who want to work with you.
   ("I know Dr. Jones will help us" instead of "How can we convince Dr. Smith to buy in?") 
4. Avoid the need for consensus, buy-in, or political solutions.
   Save these for later stages. When possible, choose changes that do not require a long process of approval, especially during the early testing phase. 
5. Don’t reinvent the wheel.
   Instead, replicate changes made elsewhere. For example, instead of creating your own atrial fibrillation treatment protocol, try modifying another hospital’s protocol. 
6. Pick easy changes to try.
   Look for the concepts that seem most feasible and will have the greatest impact. 
7. Avoid technical slowdowns.
   Don’t wait for the new computer to arrive; try recording test measurements and charting trends with paper and pencil instead. 
8. Reflect on the results of every change.
   After making a change, a team should ask: What did we expect to happen? What did happen? Were there unintended consequences? What was the best thing about this change? The worst? What might we do next? Too often, people avoid reflecting on failure. Remember that teams often learn very important lessons from failed tests of change. 
9. Be prepared to end the test of a change.
   If the test shows that a change is not leading to improvement, the test should be stopped. Note: "Failed" tests of change are a natural part of the improvement process. If a team experiences very few failed tests of change, it is probably not pushing the boundaries of innovation very far.