Chapter 38 — Capstone implementation

Chapter 38 — Capstone implementation

Lesson map

Lesson 38 published. Map, example, EX112.

flowchart TD
  N0["Learning outcomes"]
  N1["38.1 Delivering changes"]
  N2["38.2 Tracking progress"]
  N3["38.3 Handling problems"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX112"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["38.1 Delivering changes"]
  N2["38.2 Tracking progress"]
  N3["38.3 Handling problems"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX112"]

[Learning outcomes]
    |
    v
[38.1 Delivering changes]
    |
    v
[38.2 Tracking progress]
    |
    v
[38.3 Handling problems]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX112]

Learning outcomes

You will (1) deliver capstone changes safely; (2) track progress against the plan; (3) handle problems openly.

38.1 Delivering changes

With approval, the IT team makes the capstone changes in planned order, with Elena supporting and recording. The HR-driven leaver job goes live first, after a final test. Repairs enrolment follows, then reception's individual accounts, then administrator reduction and licence clean-up. Each change happens at a quiet time with a rollback plan, and each is checked afterwards against its test. Doing one change at a time means any problem can be traced to its cause quickly. Each change is announced to staff beforehand.

38.2 Tracking progress

Elena tracks each task on a simple board: planned, in progress, done and verified. A task counts as done only when its test passes in production. She reports weekly to the IT lead and her supervisor. By the end of the second month, nine of eleven tasks are verified. The remaining two are the repairs app single sign-on, waiting on the supplier, and the final service account rotation, scheduled with the finance supplier. Delays are explained in the weekly report, with new dates agreed with the owners concerned.

38.3 Handling problems

Two problems arise. The leaver job disables a contractor whose end date was entered wrongly; the sponsor notices within an hour and access is restored, and the sponsor process now asks for date confirmation. The repairs supplier delays single sign-on by a month; meanwhile operatives use individual app accounts with their security keys through the provider. Elena records both openly in the project log, with causes and fixes, because hiding problems would make the evaluation untrustworthy. Both are reviewed at the next weekly meeting.

Worked example

Nine of eleven tasks are verified by month two; a wrongly dated contractor is restored within an hour and a supplier delay is handled with an interim arrangement.

Synthetic case. Tasks, problems and dates are synthetic.

Errors and limits

Marking tasks done before verifying them in production overstates progress.

Exercises

• EX112 — Done definition. When does a task count as done? Rubric: 3 = its test passes in production;; 2 = verified;; 1 = deployed;; 0 = none.
• EX113 — Remaining tasks. Which two tasks remain after month two? Rubric: 3 = repairs app SSO and service account rotation;; 2 = two;; 1 = vague;; 0 = none.
• EX114 — Contractor fix. What process change followed the wrongly disabled contractor? Rubric: 3 = sponsor confirms end dates;; 2 = date confirmation;; 1 = vague;; 0 = none.

Synthesis

One change at a time, verified progress and openly handled problems deliver the capstone safely.

Continue studying — chapter 38 of 40

← Chapter 37 (draft) · Course chapter index · Chapter 39 (draft) →