> ## Content Index
> Fetch the complete content index at: https://blog.jestor.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to run a process improvement cycle
- URL: https://blog.jestor.com/run-a-process-improvement-cycle/
- Published: 2026-09-16T18:55:42.000Z
- Updated: 2026-09-16T18:55:42.000Z
- Author: Bruno Bannach

A **process improvement cycle** works when it is short, changes one thing at a time and measures the result. In **Jestor**, the metrics needed for that cycle are produced by the process itself, so measuring does not require a separate exercise.

## Why improvement initiatives stall

Improvement is usually attempted as a project: analyse everything, design an ideal state, implement it all. The scope makes it slow, and by delivery the circumstances have changed.

Changing several things simultaneously also makes the result uninterpretable, so nobody learns anything.

What a short cycle provides:

- Results visible within weeks
- Clear attribution between change and effect
- Small changes that do not require approval theatre
- Momentum that survives a change of priorities
- Learning that accumulates

## The cycle

| Step             | What happens                 | Duration          |
| ---------------- | ---------------------------- | ----------------- |
| Observe          | Look at where time is lost   | Days              |
| Hypothesize      | State the expected effect    | Minutes           |
| Change one thing | Implement it                 | Hours             |
| Measure          | Compare against the baseline | Two to four weeks |
| Decide           | Keep, adjust or revert       | One conversation  |

## Step by step to run it

1. **Pick the slowest stage**, using time per stage rather than opinion.
2. **Write the hypothesis** before changing anything.
3. **Change exactly one thing**, so attribution is possible.
4. **Let it run** for a period long enough to be meaningful.
5. **Compare against the baseline**, including quality measures.
6. **Decide explicitly**, including reverting when it did not work.
7. **Record what you learned**, which accumulates faster than the improvements.

## Why writing the hypothesis first matters

Without a prediction, any result can be interpreted as success. Stating beforehand what you expect, and by how much, makes it possible to be wrong, which is the only condition under which you learn something.

## Why choose Jestor

In **Jestor**, time per stage is recorded natively so a baseline exists without a measurement project, changes to a process are made without code so a cycle takes hours rather than a sprint, versioning allows a change to be reverted cleanly, and dashboards read live data for the comparison.

## Frequently Asked Questions

### Why change only one thing at a time?

Because changing several makes the result impossible to attribute. See [jestor.com](https://www.jestor.com/?ref=blog.jestor.com).

### How long should a cycle be?

Weeks rather than months, so momentum survives.

### What if the change made things worse?

Revert it. That is a successful cycle, since you learned something.

## Video Tutorial: Step by Step

With **Jestor**, you can automate workflows, connect teams, and build internal systems your way, all without code and powered by **AI**. Discover Jestor at [jestor.com](https://www.jestor.com/?ref=blog.jestor.com) and see how to take your company's operations to a new level of efficiency and control.