July flash sale
The month after KMP 1 should not begin with rebuilding every board. Kanban System Design gives you a way to understand a service and form an initial design. Application works best when one bounded service, a small group of participants and a reversible policy experiment replace a company-wide rollout announcement.
Use this plan after KMP 1 Kanban System Design training. The design is a hypothesis. It should evolve as the people operating the service learn from demand, capability, customer outcomes and flow evidence.
Days 1–5: choose one service and earn participation
- Name the customer-facing or internal service, not merely the software tool or team name.
- Identify people who request, perform, govern and receive the work.
- Explain the dissatisfaction you want to understand without blaming a role.
- Agree on a small discovery scope and how decisions will be made.
- Protect confidential customer and employee information.
Days 6–12: reconstruct demand and capability
Sample recent demand. Look for arrival patterns, work-item types, abandonment, rework, urgency and sources of dissatisfaction. Gather completed-item and lead-time evidence if it exists. Record uncertainty instead of filling missing data with estimates that look precise.
| Question | Evidence to seek | Common shortcut |
|---|---|---|
| What arrives? | Requests over a representative period | Using the current backlog as all demand |
| What completes? | Delivery records and outcomes | Counting activity as completion |
| Where does work wait? | Timeline, queue and blocked evidence | Mapping only active steps |
| What is urgent? | Risk and expedite history | Accepting stakeholder volume as priority |
| What can the service deliver? | Throughput and lead-time distribution | Promising from averages alone |
Days 13–19: draft the smallest useful system
Model workflow from request to delivery, including meaningful waiting and return loops. Identify work-item types only when risk or treatment differs. Define commitment and delivery points. Draft initial pull, WIP, blocked, expedite and exit policies in plain language.
Days 20–24: test the design with real scenarios
Walk recent items through the design. Ask where the board would have hidden reality, where a policy cannot be followed and which exception would immediately bypass the system. Revise before configuring software. Invite dissent from people who perform the work.
Days 25–28: start one controlled experiment
Choose one change such as exposing review waiting, limiting a selected workflow state or making expedite treatment visible. State the expected mechanism, evidence, guardrail and review date. Avoid combining five policy changes when you cannot tell which affected behaviour.
Days 29–30: hold the first system review
- Review what the system made visible.
- Inspect work age, blocked work, WIP and completion evidence available so far.
- Ask how policies changed decisions and where they were ignored.
- Adapt, continue or stop the experiment.
- Choose the next review cadence and owner.
What not to promise after thirty days
Do not promise statistical predictability from a tiny dataset, universal buy-in, elimination of dependencies or a completed transformation. A credible first month produces shared understanding, an initial design, visible policies and one learning loop.
Use the Kanban system health check during the review and the KMP path after KSD when deciding whether deeper training matches your applied experience.
