# Know whether it worked URL: https://docs.awellhealth.com/docs/improve-and-analyse/know-whether-it-worked > For the complete documentation index, see [llms.txt](https://docs.awellhealth.com/llms.txt). A change either moved the metric or it did not, and whether that can be answered is decided before the change goes live. This page assumes a metric has been named. If not, start with [Decide what to improve](/docs/improve-and-analyse/decide-what-to-improve). ## State the change as a hypothesis [#state-the-change-as-a-hypothesis] Write down what is expected to happen, and why, in one sentence: > We believe that \[change] will move \[metric] by \[amount] because \[reason]. For example: collecting intake through the care flow instead of by phone will cut staff time per new patient, because the manual call step disappears. Accuracy in the prediction matters less than having something to check the result against later. Work that was never tied to an expected effect cannot be judged, only defended. ## Surface the assumptions hiding in the plan [#surface-the-assumptions-hiding-in-the-plan] An assumption is a hypothesis nobody wrote down. It is a problem not because it is wrong but because it is unexamined. "We will roll this out across every site" contains one: that what worked at one site will work at all of them. That may be true, and it is a belief about how well the change scales, not a plan. The useful habit is turning assumptions into hypotheses that can be tested. Most trouble in an improvement program lives in the ones nobody said out loud. ## Test it as a time-boxed bet [#test-it-as-a-time-boxed-bet] A bet is a hypothesis with a deadline attached: > Because we believe \[hypothesis], we will \[action] for \[duration] and measure \[metric]. Running a small number of bets works better than working through a list of tasks. A list says what will be done, whereas a bet says what is expected to change and when the answer arrives, which means it can end early. ## Iterate the metric rather than debating it [#iterate-the-metric-rather-than-debating-it] Teams lose weeks choosing the perfect metric in a meeting room. Trying to move an imperfect one for two weeks teaches more, because the act of measuring exposes what the number actually captures. The right metric is usually close to the first one tried. The exception is a metric already defined by a regulator or payer, where the definition is not a choice. Use it as written. ## Measure the practice, not only the care flow [#measure-the-practice-not-only-the-care-flow] Lead time and iteration frequency describe how well a team runs the loop rather than how a patient is doing, and they set the ceiling on everything else: * **Lead time of a change.** How long from deciding a care flow should change to patients experiencing the new version. A long lead time means the loop is not really closing, whatever the intention. * **Iteration frequency.** How often the process actually changes. A care flow revised every quarter has four chances a year to get better, against one for a care flow revised annually. Neither is a clinical outcome, but both determine how fast clinical outcomes can improve, which is why they are worth tracking alongside them. ## Translate the movement into money [#translate-the-movement-into-money] An outcome that stays in clinical or operational units rarely survives a budget conversation. The translation is arithmetic, and it uses the organization's own numbers: * **Time.** Minutes saved per task × tasks per month × the loaded cost of an hour = cost avoided, or capacity freed for other work. * **Quality.** Movement on a quality measure × the payment or penalty attached to each point of that measure = revenue effect. * **Speed.** Weeks earlier that a program goes live × what the program is worth per week = revenue arriving sooner. Which of these actually moves money depends on how the organization is paid. Quality-linked payment, risk-adjusted revenue, service volume, shared savings, and avoided penalties all respond to different changes, so the same improvement can be worth a great deal in one funding model and very little in another. Check which model applies before promising anything internally. ## Say estimate when it is an estimate [#say-estimate-when-it-is-an-estimate] Before a change has run, any figure attached to it is a projection. Presenting it as one is both more honest and more persuasive, because the people who approve budgets have heard confident vendor numbers before. An estimated range with the measurement plan beside it stands up to scrutiny, while a single confident number invites someone to go looking for the assumption inside it. ## Next steps [#next-steps] **Next:** [Flow Path](/docs/improve-and-analyse/flow-path), to see where patients progress and where they stop.