Green Isn’t Done: An Evidence-First Way to Run Medical Device Programs
Most device programs don’t slip because a task ran long. They slip because a risk nobody was tracking finally came due. Here is how to run a program against the thing that actually moves your launch date — evidence — instead of the thing that only looks like progress.
The comfortable lie of a green dashboard
I have sat in a lot of program reviews where the dashboard was a wall of green and the room felt calm. Milestones were closing. Tasks were being marked complete. The burndown looked healthy. And then, weeks later, the same program lost a full quarter in the span of a single design review.
Nothing about the schedule had lied, exactly. The tasks really were finishing. What the dashboard could not show was that the program had been accumulating unproven assumptions the entire time — decisions taken on faith that a supplier would hold tolerance, that a verification protocol would pass on the first run, that the process would transfer cleanly to manufacturing. Those assumptions were invisible on the plan because no one had written them down as work to be retired.
This is the central problem with the way many medical device programs are managed. We track activity and call it progress. But activity and progress are not the same thing, and in a regulated development environment the gap between them is exactly where programs go to die.
A status color tells you how people feel. A retired risk tells you where you actually are.
Why device programs break the usual project rules
In many industries, a project is essentially a race to finish a known set of tasks. Get the work done, ship the thing. If you manage the task list well, you manage the project well. Medical device development does not behave that way, and pretending it does is the root of most late-stage surprises.
A device program is not fundamentally a race to complete activities. It is a race to generate evidence — objective, documented proof that the design is safe, effective, manufacturable, and compliant. Design controls, verification and validation, risk management, human factors, process validation, and design transfer are not paperwork wrapped around the “real” engineering. They are the deliverable. The regulatory file is the product as much as the device is.
That distinction changes what a program manager should actually be managing. Your true constraint is not how fast people finish tasks. It is how fast you can retire risk and produce the evidence that the risk is genuinely retired. Two programs can have identical task lists and identical schedules, and one will launch on time while the other slips two quarters — entirely because of the order in which they chose to confront their unknowns.
Two critical paths
Every program has two critical paths running through it at once, and most teams only watch one of them.
The first is the task path: the sequence of activities on the Gantt chart. It answers the question, “Are the activities done?” It is easy to see, easy to report, and deeply reassuring, because tasks close on a predictable cadence and each closed task turns something green.
The second is the evidence and risk path: the sequence in which the program actually retires its uncertainty and generates proof. It answers a harder question — “Is the risk actually retired?” This path is quieter. It does not close neatly week to week, and a single open item on it can invalidate a wall of green on the task path.
Figure 1 — The task path can finish while the evidence path is still open. “Done” on the top lane says nothing about the bottom one.
When a program slips “out of nowhere,” what has almost always happened is that the task path reached the finish line while the evidence path still had open, unretired risks — and those risks came due at the worst possible moment, during a design review, a validation run, or the handoff to manufacturing. The dashboard was never measuring the thing that could hurt you.
Three habits that keep programs honest
Shifting a team from a task mindset to an evidence mindset is not a tooling problem and it is not a template you download. It is an operating discipline built from a few habits that, practiced consistently, make hidden risk impossible to ignore. Three of them do most of the work.
Figure 2 — Three habits that turn invisible risk into managed work.
1. Track assumptions, not just tasks
Every green status is a bet on something you have not yet proven. The bet might be reasonable — but if it lives only in someone’s head, it is not being managed. The habit is simple and unglamorous: make the assumption a first-class item on the plan. Write the bet down, name an owner, attach the specific evidence that would retire it, and give it a date. An assumption with an owner and a due date is a managed risk. An assumption without one is a landmine with a timer you cannot see.
2. Make risk visible on the wall
If your single highest risk is not the first thing the team sees each morning, it is not being managed — it is being hoped away. Visual management is not decoration; it is a forcing function. Put the top risks where decisions actually happen: on the board the team stands at, at the top of the status page, in the first slide of the review rather than the appendix. Attention is the scarcest resource on any program, and work flows toward whatever the team is looking at. Make sure they are looking at the right thing.
3. Pull design transfer forward
Design transfer is where more device programs lose time than almost anywhere else, and it is where the task-versus-evidence gap is most brutal. Treated as an event at the end — a gate you sprint toward and hope to survive — it becomes a cliff. Treated as a phase you de-risk from day one, it becomes manageable. Bring manufacturing, quality, and supply chain into the design conversation early. Build manufacturability, process capability, and inspection strategy into the design instead of discovering them after the design is frozen. The goal is that transfer confirms what you already know, rather than revealing what you missed.
Every green status hides a bet. Write the bet down, give it an owner, and give it a date to be retired.
Where programs actually slip
The same schedule can be run two very different ways, and the difference is entirely about sequencing. A risk-last program does the comfortable, well-understood work first and pushes the genuinely uncertain work — the hard verification, the process validation, the transfer — toward the end. It looks fast early, because early tasks close quickly. Then it hits a wall of unretired risk exactly when there is no schedule left to absorb it.
An evidence-first program does the opposite. It attacks its biggest unknowns while there is still time and budget to respond to what it learns. It may look slower at the start, because retiring real risk is harder than closing easy tasks. But it does not have a cliff at the end, because the end is where it confirms decisions rather than discovers problems.
Figure 3 — Same phases, two sequencing strategies. Front-loading risk retirement removes the late-stage cliff.
This is the practical payoff of managing the evidence path. You are not adding work; you are reordering it so that the riskiest work happens when you can still do something about the outcome. Bad news is only expensive when it arrives late.
A weekly operating rhythm
None of this requires a heavy process. It requires a consistent rhythm that keeps the evidence path in front of the team. A workable cadence looks like this:
Open every status review with the top three risks and what will retire each one — not with a list of completed tasks.
For every item reported as “green,” state the assumption underneath it and the evidence that supports the color. If there is no evidence yet, it is not green; it is a bet.
Track a single metric that matters: risks retired this period versus risks added. A program generating new risk faster than it retires it is going backward, however busy it looks.
Keep a live, visible design-transfer readiness view from the first month, so manufacturing questions surface as design inputs rather than end-stage surprises.
The point of the rhythm is not ceremony. It is to make sure the conversation is always about the thing that can actually move the launch date, and never only about the thing that is easy to count.
Common failure modes to watch for
A few patterns show up again and again when programs drift back toward managing activity instead of evidence:
Reporting percent-complete on tasks while the underlying risk register goes stale. The plan says 80% done; the risk file has not been touched in a month.
Treating verification and validation as a testing phase to schedule rather than an evidence strategy to design. Protocols get written to fit the calendar instead of to retire specific risks.
Freezing the design before manufacturing has had a real vote, then absorbing the cost of that decision during transfer.
Confusing a clean review meeting with a de-risked program. A calm room often means the hard questions were not asked, not that they were answered.
Letting “green” become a social status rather than an evidentiary one — a color people report to look on track rather than to reflect proven fact.
What good looks like
A well-run device program does not feel dramatic. The hard conversations happen early, while there is still room to respond, so the end of the program is quiet. Risk is visible, owned, and shrinking. Every green status can be traced to specific evidence. Manufacturing is not surprised by the design, and the design is not surprised by manufacturing. Design transfer confirms readiness instead of exposing gaps.
That is what “Medical Device Excellence” means in practice: not heroics at the end, but discipline throughout — managing the critical path of evidence, not just the critical path of tasks. Get that right, and the launch date stops being a thing you hope for and becomes a thing you can actually defend.
Bad news is only expensive when it arrives late. Evidence-first programs make sure it arrives early.
LET’S TALK If you have a program that looks green on the dashboard but feels heavy in the room, that is exactly the situation I help medical device teams work through — bringing structure to design and manufacturing engineering, quality and regulatory compliance, and risk-driven program execution. A second set of experienced eyes on your risk path is often the cheapest quarter you will ever buy back.