Further Reading: Technology and Systems

On the citation tiers, see how-to-use-this-book.md.

Three notes before the list, and the second is a caution about this chapter specifically.

No product is named anywhere in this chapter, and that is deliberate. Software in this market changes, consolidates, and is acquired constantly, and a named recommendation would be wrong within two years and would read as authoritative for five. §39.3's nine functions are stable; the products filling them are not. Choose by function, evaluate against your own workflow, and treat any list of tools — including one you find elsewhere — as perishable.

Second: §39.7's data material is the most jurisdiction-dependent content in Part VIII and none of it is legal advice. What counts as sensitive-category data, what obligations attach to it, what retention periods apply, and whether a sole trader is in scope all differ by country and are changing. The five practices listed are defensible almost everywhere and they are not compliance. Find out what applies to you.

Third: §39.9a will date faster than anything else in this book. It is written to be useful anyway, by describing a test rather than a toolset — does this remove typing, or does it remove judgment? If the specific examples read as quaint by the time you find them, the test should still work.

Tier 1 — Verifiable published sources

Why findings do not become changes

Argyris, Chris, on single- and double-loop learning. Carried forward from Chapter 30, and here it is the theoretical name for §39.1: fixing an outcome versus changing the rule that produced it.
Any current material on lessons-learned repositories and why they fail. The consistent cross-industry finding is that they are written and not read — which is Rasheeda's ninety-one entries, documented across construction, software, aerospace, and healthcare. Search: lessons learned failure, post-project review effectiveness.
Reason, James. Managing the Risks of Organizational Accidents. Chapter 34's recommendation, and the concept of latent conditions is what an unclosed finding is: a known defect sitting in a document, waiting.
Weick and Sutcliffe, Managing the Unexpected — preoccupation with failure, which is the disposition a finding log is trying to institutionalise.

Habits, triggers, and why intention fails

Any current work on implementation intentions — Gollwitzer's research on if-then planning is the formal version of §39.2a's triggers, and the finding is robust: specifying when and where dramatically outperforms specifying what. "−6 months, send the access text" beats "remember to ask about access" for reasons that are measured rather than asserted.
Clear, James. Atomic Habits, or any comparable treatment. Popular, and its cue–routine framing maps directly onto artefacts and triggers. Read it for the mechanism, not the motivation.
Gawande, Atul. The Checklist Manifesto. Recommended twice already in this book, and here for the specific question of what belongs on a checklist and what does not — §39.9's "systematise anything with a right answer" is his distinction.

Documents, versions, and information architecture

Any introduction to version control concepts — not the software, the ideas. One current version, an immutable history, and a naming convention are borrowed wholesale from software practice and transfer to a folder of run sheets almost unchanged.
Any material on file-naming and records-management conventions from an archives or records-management source. Dry, free, and better than anything written for event planners.
Hutchins, Edwin. Cognition in the Wild. Chapter 27's recommendation, and the most relevant book on this list for the idea that a team's knowledge lives in its artefacts and arrangements rather than in heads — which is §39.2's test in its theoretical form.

Data protection and privacy

Your own jurisdiction's data-protection regulator. In the EU/UK, the ICO or your national DPA publishes free, plain-language small-business guidance, including on special-category data. Equivalents exist in most jurisdictions. This is the correct source and it is free.
Specifically, the guidance on health data. Dietary and access requirements are the part planners do not realise they are holding, and the guidance is clearer than any summary.
Your storage and platform providers' own documentation on link sharing and access control. The shared-link problem in §39.7 is solved by a setting most people have never opened.

Automation and its limits

Any current work on automation bias — the well-documented tendency to under-check confident automated output. This is the mechanism behind §39.9a's second warning, and it is studied in aviation and medicine where the consequences are visible.
Bainbridge, Lisanne. "Ironies of Automation" (1983). Short, decades old, and still the best thing written on this subject: automating the easy parts leaves a human responsible for the hard parts, with less practice at them. Directly applicable to a generated timeline.

Tier 2 — Attributed professional practice

"A system is not software; it is the mechanism by which a finding becomes a change." The author's framing, and the chapter's whole argument.
The five reasons a finding dies. The author's, and reasons 1 and 3 are the ones supported by the widest cross-industry evidence.
The four components. The author's taxonomy.
The four kinds of trigger, and the claim that threshold triggers are the most valuable and least common. Practice.
The ten-trigger set. The author's, assembled from this book's own findings — which is exactly what it is for, and a reader's set should differ.
The nine stack functions, and function 8 as free and universally absent. Practice.
The six platform questions, and the parallel event. Question 5 is the author's and is the most useful.
The four document conventions and the folder tree. Borrowed from records management and software practice, not invented here.
The unit convention. The clearest single recommendation in the chapter, and it is derived from four documented errors in this book rather than from anywhere external.
The correspondence log and the decision record. Practice, and the estimate of forty log entries and six decision records per wedding is the author's.
The venue file. The author's, closing a Chapter 34 finding.
The five-field finding log, and "a log of unclosed findings is worse than no log." The strongest claim in the chapter and it is an assertion, supported by Case Study 39.1 and by the lessons-learned literature above.
"Three or four changes a season." An estimate, and D.3 argues it is defeatist. The author's position: it is what people actually do, and planning against a higher number produces zero.
§39.10's six ways technology makes things worse. Observation.

Tier 3 — Illustrative and constructed

Rasheeda Iyaloo's three years, and every figure in Case Study 39.1. Constructed.

Case Study 39.2 is different from every other case study in this book, and the difference matters. Its twenty-two changes are not constructed — every one was produced by a chapter of this book and is sourced to it. What is constructed is the costing, the ranking, and the second-year projection.

Which makes it the book's own audit rather than a worked example, and it is deliberately uncomfortable: the book accumulated twenty-two obligations across thirty-eight chapters and never totalled them, which is precisely the failure it spent those chapters diagnosing. DQ1 says so.

Two further notes on it. The nineteen-hour estimate is the author's and is probably optimistic — most people's implementation estimates are. And the second-year projection — twenty-two becoming twenty-one — is a construction chosen to make a point that a more flattering projection would have obscured: a systems practice does not clear a backlog, and a shrinking list would mean either that nothing is being noticed or that the logging criteria have quietly tightened.

Where to go next

Read Gollwitzer on implementation intentions, or a good summary. It is fifteen minutes and it is the research behind §39.2a.

Then build the trigger set (B.2). Ten rows, four minutes per event thereafter, and it is the highest-return item in this chapter.

Read Bainbridge's "Ironies of Automation." Eight pages, from 1983, and it will tell you more about §39.9a than anything published this year.

Find your data regulator's small-business guidance on health data (C.4). Free, and most planners have never read it.

And do Case Study 39.2's DQ6: copy the twenty-two, cross out what does not apply to you, add your own season's findings, rank the combined list, choose four — and take #2 as one of them regardless.

Then date the rest. Eighteen items with dates is a queue; eighteen without is what this book has been carrying invisibly since about Chapter 20.

Part IX preview

Part VIII ends here.

Chapter 40 is the capstone — the complete wedding, start to finish, stress-tested against a scenario designed to break everything this book has built. Bring all of it: the timeline, the run sheet, the failure playbook, the guest walk, the reconciliation, and the twenty-two.

And Chapter 41 asks the question none of Part VIII's arithmetic has touched.

Chapter 36 counted the hours. Chapter 37 priced the Saturdays. Chapter 39 has just asked you to find nineteen more hours in a year that Chapter 36 established is already full.

Chapter 41 asks what all of that costs the person doing it, and how long anybody can do it.