A leadership change creates a quiet risk for downtime preparedness. The person who knew where the workstations were, who to call at the vendor, which drills had revealed which problems, and which promises had been made to the board is gone. The person who replaced them inherits accountability for the program without the context that made it work.
The same applies when the downtime program owner leaves, when a new CNO arrives, or when a new administrator takes over after an acquisition. In each case, the new leader needs a way to understand the real state of the program quickly and to avoid assuming that no news means good news.
A structured 90-day readiness review fills that gap. It gives the new leader a defensible baseline, a prioritized list of actions, and a story to tell executives and the board.
Why Leadership Change Is a Risk Window
Several things tend to go wrong during transitions:
- Escalation and notification lists still name the departed person
- Vendor contacts and support relationships are tied to an individual who is no longer there
- Commitments made after the last drill or event are not tracked by the new owner
- Informal knowledge, such as which departments struggle or which workstation has a recurring problem, was never written down
- The new leader’s attention is pulled toward urgent priorities, and downtime sits unexamined until an event forces it
Days 1 to 30: Gather the Evidence
Start by collecting what exists. Request or locate:
- The current downtime policy and its last review date
- Department-level procedures and where they are posted
- Reports from drills, planned maintenance windows, and actual events from the past two years, including after-action reports and the status of their action items
- The vendor contract, support terms, and current account contacts
- Access to the Downtime Dashboard and the workstation inventory with locations
- The date the forms library was last reviewed and who reviewed it
- Training completion data by department, including agency and travel staff
- Budget history and the original investment case
- Any survey findings or regulatory comments related to downtime
Also talk to the people who held the program together: the outgoing owner if available, department leads, the IT staff who handle the integration, and the vendor account contact. Ask what keeps them up at night about the program. The answers are often more revealing than the documents. Our post on building a downtime knowledge base that survives staff turnover describes what a well-documented handoff should have contained.
Days 30 to 60: Verify on the Floor
Documents describe the intended program. This phase tests the actual one.
- Visit priority departments and locate each downtime workstation yourself
- Confirm each workstation is on, shows a current census, and has the forms staff would need
- Ask staff the four questions from our guide to an internal downtime audit: what they would do first, where the workstation is, when they last used it, and how they would register a new patient
- Run a timed activation in one representative department
- Confirm that notification trees and on-call rosters list current people and working phone numbers
- Check that the HL7 integration has been verified since the last EHR upgrade
Record what you find as specific observations, not impressions.
Days 60 to 90: Decide and Communicate
By this point you can assess the program using the five dimensions in our post on measuring downtime program maturity: technology, policy, training, testing, and governance.
- Build a gap list ranked by patient safety and regulatory risk first, then operational impact
- Assign an owner and a deadline to each of the top five gaps
- Confirm the governance structure. If clinical leadership is not already a co-owner, use this transition to establish it, as described in our post on getting clinical leadership to co-own downtime preparedness
- Meet the vendor account team to reset expectations and confirm contacts
- Prepare a one-page readiness summary for executive leadership with an honest status, the top gaps, and the plan
Red Flags to Watch For
Some findings should move to the top of the list immediately:
- No drill or planned-window exercise in the past 12 months
- Workstations that cannot be located or are not syncing
- Staff who cannot describe what they would do
- Forms that do not match current workflows
- No named owner for the program
- Open action items from prior events with no progress
What Good Looks Like at Day 90
At the end of the review, the new leader should be able to answer plainly: what is our actual readiness, what are the five things we will fix first, who owns each one, and when will we know it worked. That clarity is the difference between inheriting a program and owning one.
For an objective baseline, dbtech’s Downtime Audit Assessment gives incoming leaders an external view that is independent of anyone’s prior assumptions. To discuss a transition review, contact our team or request a demo.