Chapter 11 — Capstone project

Chapter 11 — Capstone project

Lesson map

Lesson 11 published. Map, example, EX051.

flowchart TD
  N0["Learning outcomes"]
  N1["11.1 Choosing the intervention"]
  N2["11.2 Design"]
  N3["11.3 Implementation"]
  N4["11.4 Evaluation"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX051"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["11.1 Choosing the intervention"]
  N2["11.2 Design"]
  N3["11.3 Implementation"]
  N4["11.4 Evaluation"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX051"]

[Learning outcomes]
    |
    v
[11.1 Choosing the intervention]
    |
    v
[11.2 Design]
    |
    v
[11.3 Implementation]
    |
    v
[11.4 Evaluation]
    |
    v
[Worked example] --> [Exercise EX051]

Learning outcomes

You will (1) design a capstone governance intervention; (2) implement it with stakeholders; (3) evaluate results against a baseline.

11.1 Choosing the intervention

For her capstone, Lucía chooses to govern customer address data, which the board funded. Addresses differ between the order and billing systems, causing misdelivered invoices and failed deliveries. She defines the problem with a baseline: share of customers whose addresses differ between systems, failed deliveries attributed to address errors and invoices returned undelivered. She agrees success criteria with the sales director as owner and Dr. Achebe as supervisor before starting. She records the baseline figures in her project log before any change is made to either system.

11.2 Design

Lucía designs the intervention: the order system becomes the authoritative source for delivery addresses, the billing system for invoice addresses, with clear rules on which changes flow where. A steward in sales reviews mismatches weekly. Address validation is added at order entry using a postcode lookup. Customers can update addresses through a portal that writes to the authoritative system. She records each design choice in a decision record with alternatives considered. The sales director approves the design after a review with IT and billing staff.

11.3 Implementation

Implementation takes four months. IT builds the address flows and validation; sales trains staff on the portal. Lucía runs weekly checks and finds an unexpected problem: some customers have several valid delivery sites, which the original design treated as mismatches. She revises rules to allow multiple delivery sites per customer with one invoice address. She notes that implementation reveals assumptions that design discussions missed, which is why monitoring during rollout matters. The revised rules are tested on synthetic cases before going live.

11.4 Evaluation

After implementation, Lucía compares results with the baseline using synthetic figures that mirror her observations. Address mismatches, failed deliveries due to address errors and returned invoices all fall. She checks whether other changes coincided, finding a seasonal drop in volume that could partly explain fewer failures, and adjusts her claims. She documents limits and recommends continued monitoring. Dr. Achebe approves the evaluation as balanced and well evidenced. She presents the before and after figures in a short table, with a note beside each figure explaining how it was measured.

Worked example

Lucía governs customer addresses with a baseline and agreed criteria, designs authoritative sources, steward review, validation and a portal, adjusts for multiple delivery sites and evaluates cautiously against the baseline.

Synthetic case. The project and figures are synthetic.

Errors and limits

Evaluating without a baseline makes improvement impossible to show.

Exercises

• EX051 — Address problem. What problems did address differences cause? Rubric: 3 = misdelivered invoices and failed deliveries;; 2 = both;; 1 = one;; 0 = none.
• EX052 — Delivery authority. Which system is authoritative for delivery addresses? Rubric: 3 = the order system;; 2 = partly correct;; 1 = billing;; 0 = none.
• EX053 — Surprise. What unexpected issue appeared? Rubric: 3 = customers with several valid delivery sites;; 2 = partly correct;; 1 = vague;; 0 = none.
• EX054 — Coinciding change. What coinciding change did Lucía find? Rubric: 3 = a seasonal drop in volume;; 2 = partly correct;; 1 = vague;; 0 = none.
• EX055 — Validation method. How are addresses validated at entry? Rubric: 3 = a postcode lookup;; 2 = partly correct;; 1 = vague;; 0 = none.

Continue studying — lesson 11 (chapter 11 of 12)

← Chapter 10 · Course chapter index · Chapter 12 →

Continue to the next authored lesson.