DB-WEB-04 · Rev A · 2026 Selected work
Deon BaileyEmergency preparedness
Selected work

The framework, applied.

These case studies show how the Preparedness Knowledge Cycle works in practice. Both are composites: the problems, methods, and lessons are drawn from real professional experience, but organizations, people, and specific details are fictionalized. No employer or client information appears here.

Composite case study · details fictionalized

Turning a shelf of static plans into a living planning system

Context

A mid-sized public agency responsible for roughly thirty planning documents: base plans, functional annexes, hazard-specific annexes, and supporting procedures, accumulated over a decade under several different planners. The most recent planner has just resigned.

The challenge

No one remaining could say with confidence which plans were current, which contradicted each other, or which restated the same facts differently. A single department reorganization the previous year had silently invalidated the contact rosters, succession orders, and notification procedures in at least six documents, discovered only when a call-down drill failed. The agency's real problem wasn't any individual plan. It was that the planning suite had no architecture: no map of what existed, what each product depended on, or where its facts came from.

The approach

Instead of starting with the most out-of-date document, the work started with an inventory and a crosswalk: every planning product mapped to its regulatory driver, its approval authority, its state or federal template equivalent, and, critically, the operational facts it consumed. That last column exposed the disease: the same fifteen or so facts (key role holders, facility details, system names, delegation chains) appeared in nearly every document, each maintained separately, each drifting independently.

The redesign

The suite was rebuilt around the three-layer model. A single knowledge base became the authoritative home for operational facts, owned by the programs closest to them. Plans were rewritten to reference that layer rather than restate it: a succession order names a position, and the position's current holder lives in exactly one place. A quarterly validation rhythm gave each fact an owner and a review date, so currency became a scheduled behavior instead of a heroic one.

Outcome

The next personnel change required one update in one place, and a short list of consuming documents was flagged for review automatically by the crosswalk. Plan maintenance shifted from an archaeology project to a routine. Most importantly, the system survived its own test: the knowledge stayed intact through subsequent staff turnover, because it no longer lived in anyone's head.

Lesson

Plan drift is an architecture problem wearing a diligence costume. Agencies respond to out-of-date plans by exhorting people to update them more often; the durable fix is making sure each fact only has to be updated once.

Composite case study · details fictionalized

Making corrective actions actually correct something

Context

A preparedness program running a compliant exercise cycle: annual exercises conducted, after-action reports written on time, improvement plans dutifully attached. On paper, a model program.

The challenge

Reading three years of after-action reports side by side revealed the quiet failure: the same findings recurred year after year. Notification lists were stale in 2023, 2024, and 2025. Role confusion at the operations desk appeared in every functional exercise. Each finding had been recorded, assigned, and reported, and none had changed anything, because corrective actions were tracked as tasks in a document rather than as updates to the knowledge and plans that produced the failure.

The approach

Every corrective action was reframed with one added question: what does this finding change, and where does that thing live? A stale roster finding doesn't close when someone updates the roster; it closes when the authoritative source of that roster is identified, an owner and review cycle are attached, and the plans consuming it are pointed at the source. Findings were sorted into three destinations: updates to operational knowledge (layer one), revisions to plans and procedures (layer two), and changes to the exercise and training program itself (layer three).

Outcome

Corrective actions stopped being a compliance artifact and became the program's update mechanism: the return arrow in the model, operating on a schedule. The test of success was the next exercise cycle: the recurring findings finally stopped recurring, and the new findings were genuinely new, which is what a learning system is supposed to produce.

Lesson

An improvement plan that doesn't specify where the lesson goes is a list of good intentions. The value of an exercise isn't the report; it's the knowledge update the report triggers.

A note on these studies

I publish composites rather than client or employer work. The reasoning is part of the methodology: preparedness documents describe how real organizations respond under stress, and even sanitized details can reveal more than intended. The patterns here are real. The particulars are not.