Chapter 29 — Applied project
Lesson map
Lesson 29 published. Map, example, EX085.
flowchart TD
N0["Learning outcomes"]
N1["29.1 Problem and baseline"]
N2["29.2 Causes"]
N3["29.3 Changes"]
N4["29.4 Results and handover"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX085"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["29.1 Problem and baseline"]
N2["29.2 Causes"]
N3["29.3 Changes"]
N4["29.4 Results and handover"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX085"]
[Learning outcomes]
|
v
[29.1 Problem and baseline]
|
v
[29.2 Causes]
|
v
[29.3 Changes]
|
v
[29.4 Results and handover]
|
v
[Worked example] --> [Exercise EX085]
Learning outcomes
You will (1) plan and deliver an applied improvement project; (2) measure results against a baseline; (3) document the solution for handover.
29.1 Problem and baseline
Ravi's project addresses delay between repair completion and the update appearing in the housing system. Delays make reports show jobs as open when they are finished and cause tenants to receive unnecessary calls. Using synthetic data that mirror his placement observations, he measures a baseline: the share of completions updated within one day and the median delay. He agrees a target with the repairs steward and a plan with milestones. The baseline figures are recorded in the project log before any changes begin.
29.2 Causes
Ravi investigates causes. Some contractors update the portal only at the end of each day; others batch updates weekly. The portal sends updates to the housing system once nightly, adding up to a day more. Some updates fail validation and wait for correction. He ranks causes by their contribution to delay and finds weekly batching by one contractor and the nightly transfer to be the largest contributors. He shares the ranking with the steward, who agrees to tackle the two largest causes first and leave the smaller ones for later.
29.3 Changes
With the steward's approval, Ravi works with the portal team to send updates every hour instead of nightly. The contractor that batches weekly agrees to daily updates after seeing its scorecard. Ravi improves validation messages so contractors fix failed updates faster. He tests each change on synthetic data and follows change control. He keeps a project log recording decisions, tests and results for his assessment. The changes go live one at a time, so that the effect of each can be seen separately in the monitoring results.
29.4 Results and handover
After changes, synthetic data designed to match the new process show the share updated within one day rising and the median delay falling. Ravi notes that real monitoring must confirm this. He hands the monitoring script, documentation and scorecard updates to the steward, with a monthly check scheduled. Ms. Moreau notes that projects succeed when they leave behind working processes and owners, not only a report describing what was done. The steward confirms that the handover pack is complete and that she can run the monitoring alone.
Worked example
Ravi baselines completion update delay, traces it to weekly batching and nightly transfers, introduces hourly transfers, daily contractor updates and clearer validation messages and hands over monitoring to the steward.
Synthetic case. The project data are synthetic.
Errors and limits
Projects that end without handover leave improvements unsupported.
Exercises
- EX085 — Largest causes. Which causes contributed most delay? Rubric: 3 = weekly batching by a contractor and the nightly transfer;; 2 = both;; 1 = one;; 0 = none.
- EX086 — Transfer change. How often does the portal now send updates? Rubric: 3 = hourly;; 2 = partly correct;; 1 = wrong;; 0 = none.
- EX087 — Handover recipient. Who receives the monitoring script? Rubric: 3 = the repairs steward;; 2 = partly correct;; 1 = other;; 0 = none.
Continue studying — lesson 29 (chapter 29 of 30)
← Chapter 28 · Course chapter index · Chapter 30 →
Continue to the next authored lesson.