How to Start DevOps in a Hospital: A 90-Day Plan

Ninety days is enough to change how a hospital ships software — provided the scope is ruthless. This plan asks for one value stream, one team, and one measurable outcome. Not a reorganisation, not a platform migration, and not a memo. Oncology centres already understand the logic: you do not treat everything at once; you stage the work, measure the response, and adjust. DevOps adoption responds to the same discipline. Terminology below follows the full DevOps reference at xOps School, which makes a useful companion for staff who want the definitions behind each step.

Before day one: three DevOps prerequisites

Two conditions make the quarter survivable. First, sponsorship with patience — a named executive who accepts that measurement precedes improvement and does not demand a transformation deck in week two. Second, a team with slack; improvement work done in evenings collapses at the first clinical escalation. The third prerequisite is a decision about language: agree that this is DevOps adoption on one stream, not a rebrand of the IT department, because scope creep kills more programmes than technology ever has. Groups that skipped these basics appear throughout the failure stories; groups that honoured them rarely need to invoke them again.

Phase one, weeks one to four: see and stabilise

1. Name the stream and the owner. Choose one patient-facing flow with a visible pain signature — pathology result notifications or appointment scheduling are typical. Give it a single accountable owner with time carved out, not a committee.
2. Map the value stream onto a single page. Every step from “clinician asks for a change” to “change is live”, including queues and approvals. Mark where work sits still. Most groups find waiting consumes over ninety percent of elapsed time.
3. Baseline the five measures. Lead time for changes, deployment frequency, restoration speed, the change failure rate, plus rework rate — DORA’s 2024 addition to the panel. Measure now, before any improvement, or the end-of-quarter comparison is guesswork.
4. Price the biggest queue. Cost of delay equals value per week times the weeks a change waits. If twelve improvements worth 5,000 units each wait three extra weeks, the quarter loses 180,000 units of value. One number like this converts sceptics faster than any deck.
5. Stabilise the ugliest manual step. One fragile script, one hand-edited config, one Sunday-evening task. Fix it this month, and say out loud that you did. Credibility compounds faster than tooling ever deploys.

Phase two, weeks five to eight: automate the path

1. Build once, in a pipeline. Move the chosen stream to a single automated build — Jenkins, GitHub Actions, GitLab CI or Tekton will each do the job; choose the one your team will maintain, not the one generating the most conference talks.
2. Work in small batches on a shared trunk. Branches live in hours, not weeks. Long-lived branches are the classic anti-pattern: they rebuild the silo your organisation paid to remove.
3. Pull feedback under ten minutes. Commit to trustworthy test result in roughly ten minutes. Split the suite if needed — fast core on every push, slower end-to-end checks on a schedule. Beyond that threshold, engineers batch changes and trust decays.
4. Rehearse the rollback and time it. Declare the deployment identifier and owner first. If no irreversible migration has run, roll back; if one has, toggle the feature off or fix forward. The recorded gap is stark: an unrehearsed rollback in one documented case took 190 minutes against roughly twenty when practised.
5. Make the database reversible. Adopt expand-and-contract migrations: add capacity first, remove old structure only when nothing depends on it. This single habit is what makes rollbacks boring.
6. Decouple deploy from release. Wrap risky features in flags, expose them first through a canary release to a handful of users, then widen.

Phase three, weeks nine to twelve: govern and spread

1. Move controls into the pipeline. Least-privilege access rights, OIDC credentials that expire rather than standing secrets, and break-glass merge paths that alert loudly whenever used. Controls exercised on every change outrank controls inspected annually.
2. Prepare the audit habit. Agree to sample roughly ten random changes each quarter as standing evidence. Present this to compliance as what it is — stronger assurance than signatures — and the relationship improves immediately.
3. Run the first blameless review. Publish, inside five working days of any incident, the sequence of events, the moment an owner was declared, and how long recovery took. Blame teaches people to hide; published findings teach the system to improve.
4. Coach team two. The enabling coach who sat with your first team now sits with the second. This is the highest-value hour in the programme.
5. Brief the board on the J-curve. Delivery improves, then dips as automation raises testing requirements, then settles higher. Agree the acceptable dip duration in writing now, in week twelve, before the dip arrives.

A note on tools and reading before you begin

Two procurement questions surface in week one of every programme, so they deserve answers up front. Which pipeline? Whichever your team will maintain — GitHub Actions, GitLab CI, Jenkins and Tekton each run this plan without modification, and switching later is cheaper than arguing now. And do you need value stream mapping software? No; a wall, some sticky notes and an honest hour will locate your queues as reliably as a licence. For preparation, the short reading list holds: Accelerate (2018) supplies the evidence, the updated DevOps Handbook (2021) supplies the plays, and Martin Fowler’s continuous integration essays supply the founding argument. Anyone on the team who finishes those three will recognise every step of the ninety days before it happens.

What this 90-day DevOps plan deliberately avoids

• A permanent “DevOps team” — naming a way of working, not a department; dedicated silos of this kind are a documented anti-pattern.
• Metrics-as-targets leaderboards, which reliably teach people to game the numbers.
• Heavyweight change approval boards; the evidence links them to worse performance, while peer review inside the pipeline performs better.
• Big-bang programmes and organisation-wide mandates before a single stream has proven the pattern.

How you will know the DevOps quarter worked

Recount the five measures and compare against week one. Expect movement on lead time and deployment frequency first, restoration time next, rework rate as the quality signal matures. Set expectations honestly using the adoption evidence: pilot teams averaged 4.25 of 5 while toolchain-first programmes managed 2.40 and outright mandates 2.50 — so the plan’s centre of gravity is coaching, not procurement. Maturity moves a group from siloed working through automated islands and integration toward continuous delivery and, at the summit, a self-improving learning system; ninety days typically moves one stream one or two rungs, which is precisely the pace that holds.

We draw the same staging logic elsewhere in our coverage: how cancer hospitals create personalised treatment plans describes tailoring a protocol to one patient, and this plan tailors a delivery protocol to one value stream. When the quarter ends and the numbers argue for expansion, our complete guide to DevOps, SRE and cloud-native engineering takes the next stage beyond the ninety days. Book the day-90 review now, put the week-one baseline beside the new numbers, and let the second team volunteer itself. Expect the volunteers to arrive carrying their own pain stories; that is how movements start inside hospitals, one relieved team at a time. Plans like this succeed quietly, which is exactly how hospital software should behave.