I have shipped enough IT projects to know that most failures are not dramatic. They rarely look like a server bursting into flames. They look like a quiet drift: a deadline that slipped a week, then two, a feature nobody actually asked for, a stakeholder who stopped reading the updates because there were too many of them. The mistakes are small and ordinary, and they compound. When the project happens to be in healthcare, those small mistakes stop being inconvenient and start having consequences for real patients.
So this is my working playbook for keeping a delivery on the rails, and the things I pay extra attention to when the client is a hospital, a clinic, or anyone who handles medical data.
Plan before you build, then keep planning
A good plan is not a document you write once and file away. It is a living map. Before any work starts, I force myself to define the scope and the objectives in plain language, because that single act decides the direction of everything that follows. If you cannot write the goal in a sentence a nurse or a finance director would understand, you do not yet know what you are building, and that confusion will leak into every estimate you make afterward. From there I break the work into tasks and, crucially, map the dependencies between them. That is where the hidden bottlenecks and conflicts surface, the two tasks that both need the same person in the same week, the integration that cannot start until a third party delivers an API, the sign-off that has to clear a compliance officer before a single line of patient-facing code goes near production.
Then I write down what could go wrong. Delays, an unexpected technical wall, a vendor who goes quiet: naming these risks early lets me build contingency plans while I still have room to maneuver. I keep them in a simple register with an owner and a rough sense of likelihood and impact, because a risk with no name attached to it is a risk nobody will act on. The mistake people make is treating the plan as finished once it looks tidy. It never is. As the project teaches you things, the plan has to absorb them, so I revisit it on a schedule and adjust. A plan that never changes is usually a plan nobody is reading. The point of planning is not the artifact, it is the thinking the artifact forces you to do, and that thinking has to keep happening long after the kickoff meeting is over.
Communicate, and actually listen
Most of the misunderstandings I have seen on projects trace back to communication that was either too thin or one-directional. If stakeholders do not know where the project stands, they fill the gap with assumptions, and assumptions breed delays. The fix is not glamorous: clear channels, a steady cadence of meetings, short written updates, and being genuinely reachable when someone has a question. I try to match the channel to the message, so a routine status note goes out in writing where people can read it on their own time, and a decision that needs debate gets a real conversation rather than a thread that spirals for three days. The goal is that no stakeholder is ever surprised by something I could have told them a week earlier.
But broadcasting status is only half of it. The half people skip is listening. Feedback and suggestions from the people around the project, especially the ones who will use the thing, are free signal about what you are getting wrong before it ships. A clinician will tell you that the workflow you designed adds three clicks to a task they do four hundred times a day, and that is the kind of detail no requirements document ever captures. When you build an environment where people feel safe pointing out problems, the quality of the work climbs on its own, because problems get surfaced while they are cheap instead of hidden until they are expensive.
Stay organized, in tools and in mindset
Disorganization is a slow leak. Documents nobody can find, deadlines that live only in one person's head, deliverables that surface a day before they are due. I keep every project artifact in one accessible place and maintain a clear running view of what is owed and when. The version of a spec that lives on someone's laptop is the version that quietly goes out of date and then gets built from anyway.
Project management software does a lot of this heavy lifting. It tracks tasks, assigns responsibility, monitors progress, and gives the team one central home for plans, schedules, and documents. Pair that with a deliberate system for tracking risks, identifying them and noting how you will blunt their impact, and you stop being ambushed. Still, the tools are only half the story. The other half is a mindset: a willingness to adapt when circumstances shift, and the habit of spotting a problem while it is still small enough to fix cheaply. I have watched teams with immaculate tooling fail because nobody actually wanted to look at the uncomfortable numbers, and I have watched teams with a shared spreadsheet succeed because the people using it were honest about where they were behind. Organization is a behavior before it is a piece of software.
Stay flexible when reality argues with the plan
No plan survives contact with reality intact. There will always be something you could not have foreseen, and the projects that survive are the ones run by people willing to pivot. Sometimes that means trimming scope, sometimes reshuffling priorities, occasionally rethinking the whole direction. Being open to those moves is what keeps a project moving instead of stuck. The trick is distinguishing a genuine change of course from a flinch, because pivoting at every gust of wind is just another way to fail, only slower.
Flexibility also means staying open to the people telling you something is off, whether that is a teammate, a stakeholder, or an end user. Folding their input into the plan, rather than defending the plan against it, is one of the cleanest ways to avoid an expensive mistake. I have learned to treat the urge to defend a plan as a warning sign in itself. If I feel defensive about a decision, it usually means I am protecting my ego rather than the outcome, and the project pays for that every time. Changing the scope, shifting priorities, even reversing a call I made loudly last month is cheaper than shipping the wrong thing on schedule.
Test like you are trying to break it
Before anything goes live, it gets tested hard. Quality assurance is not a few happy-path clicks to confirm the obvious works. It is a deliberate attempt to cover the awkward scenarios, the edge cases, and the conditions designed to stress the system until its weak points show. That means more than checking that a form submits when everything is filled in correctly. It means feeding it the empty field, the impossible date, the patient record with a missing identifier, the sudden burst of traffic at the start of a shift change. A range of tests across different scenarios and use cases, including the ones meant to push the system past comfortable load, is how you find the issue while it is still cheap to fix instead of after launch.
Internal testing alone is not enough, though. The people who use a product will do things you never imagined. Getting a small group of real users in front of it, or running formal user acceptance testing, surfaces the problems that hide in the gap between how you think the system works and how someone actually uses it. UAT is also where you learn whether the thing you built solves the problem the user actually had, as opposed to the problem you assumed they had back when you wrote the requirements. In a clinical setting that gap can be the difference between a tool people adopt and a tool they quietly route around with a paper workaround, which is the worst outcome of all because it looks like success on the dashboard.
Build a team, not a roster
The interesting IT projects are too big for any one person, and the good ones are delivered by a team that genuinely works together. That depends on clear communication and a shared understanding of what the project is for. I set explicit roles and responsibilities, so nobody is guessing whether a task is theirs, because the work that falls between two people's assumptions is the work that never gets done. A shared map of who owns what removes a whole category of silent failure, and it also makes it obvious when someone is overloaded and needs help before they burn out.
The part that does not fit in a process document is trust. Give people the autonomy to make decisions in their own area, back them with the resources and support they need, and respect their judgment. A team that trusts each other catches problems faster than any individual hero ever could, because people will raise their hand early when they are not afraid of being blamed for the bad news. Pooling the collective knowledge of skilled professionals only works if those professionals feel free to actually contribute it, and that feeling is something a manager builds or destroys through a hundred small reactions to being told something they did not want to hear.
Let the software carry the routine
I lean on project management software for a reason: it removes the friction that causes drift. One central place for plans, schedules, documents, communication logs, and progress reports means everyone is working from the same picture rather than five slightly different ones. Task assignment, progress tracking, and reporting keep the whole group informed without anyone having to chase status by hand, which frees the people on the project to spend their attention on the work instead of on reconstructing where the work stands. If the tool also offers risk management features, use them, because surfacing potential risks early is exactly the kind of work software is good at remembering and humans are good at forgetting. The reporting matters more than it sounds: when a stakeholder can pull up the state of the project themselves, you spend far less time defending it and far more time improving it.
Set goals that are hard but honest
Goals are a balancing act. Aim too high and the team starts cutting corners to hit numbers that were never realistic, which is how unnecessary mistakes creep in. Aim too low and you leave the project's potential on the table, shipping something safe and forgettable when a little more ambition would have made it genuinely useful. The sweet spot is challenging but achievable, and finding it is one of the least appreciated skills in delivery.
I start from clearly defined objectives, then work with the team to turn them into SMART goals: specific, measurable, achievable, relevant, and time-bound. The framework is not decoration. Each letter kills a different way of fooling yourself, so "improve the booking system" becomes "cut average appointment booking time from four minutes to ninety seconds by the end of Q3." Those goals have to respect the real constraints, budget, timeline, and who is actually available, because a goal that ignores its constraints is just a wish. And like the plan, goals are not set in stone. Regular progress reviews against them tell you when something needs adjusting so they stay both realistic and useful.
Review progress on a real schedule
Regular progress reviews are where you catch problems while they are still small. A review is a moment to measure where the project actually is against where you said it would be, and to flag risks before they grow teeth. It only works if you have a baseline to measure against, which is the real reason the goal-setting up front matters so much: without measurable objectives, a review degrades into everyone agreeing that things feel roughly fine. The way I run one is straightforward.
| Step | What it means in practice |
|---|---|
| Set clear goals | Define measurable objectives up front so you have a baseline to judge progress against |
| Keep a fixed cadence | Decide how often you review and hold the line on that schedule |
| Gather and analyze data | Pull progress reports, project logs, and other signals, then read them for emerging risks |
| Engage stakeholders | Reviews are not just for the project manager: bring in team members, stakeholders, and other interested parties for their perspective |
| Take action | Close the loop by revising the plan, reassigning tasks, or whatever the findings demand |
The action step is the one people quietly drop. A review that surfaces a problem and then does nothing about it is just a meeting, and worse, it teaches everyone present that raising problems is pointless, which is exactly the opposite of what you wanted. Engaging stakeholders in the review is what keeps it honest, because the people closest to the work and the people paying for it tend to see different problems, and you need both views to act on anything real.
Treat mistakes as tuition
You will make mistakes. I have made plenty, and no amount of careful planning fully prevents them, because that is simply what working on complex things looks like. It is tempting to get discouraged when something breaks, but a mistake you understand is worth more than a success you cannot explain. The skill is not avoiding every error; it is refusing to waste the ones you make. When something goes wrong, I try to sit with it long enough to understand what actually failed and what I would do differently, and then I bake that into the process so the same mistake cannot repeat. A postmortem that hunts for a person to blame teaches everyone to hide the next failure; a postmortem that hunts for the broken process teaches everyone to surface it.
In healthcare the stakes raise this from good hygiene to a duty. A mistake here is not a missed sprint. It can mean a delay in a patient's treatment, the loss of important medical data, or a piece of equipment failing in a way that puts someone at risk. So the loop has to be deliberate: review the project regularly to find where things slipped, put procedures in place to prevent a repeat, and bring in the doctors, nurses, and patients who see the system from angles a project manager never will. They will tell you about the failure mode you never modeled because they live with the consequences of it. Done honestly, this builds the kind of resilience that makes the next project better, the ability to take a setback and come back steadier, and that matters in work and in life.
What is different about healthcare delivery
Every project carries risk, but a healthcare project carries a specific and heavier set. Regulatory compliance, the constant threat of a data security breach, and the duty to protect the privacy and confidentiality of patients' personal and medical information all sit on top of the usual technical challenges, schedule slips, and budget overruns. There is also the matter of approvals and permissions from the relevant authorities, which can gate the whole timeline in ways no amount of engineering speed can shorten. And looming behind all of it is the potential impact on patients, the possibility of an adverse event or a bad outcome, which is why these risks deserve careful assessment rather than a line in a register. The cost of getting it wrong is not measured only in money, and that changes how you weigh every trade-off.
I find it useful to sort them into three buckets.
Financial risks threaten the money that keeps the project alive. They come from inadequate funding, late payments, or shifting market conditions, a new competitor or a new technology that changes the math underneath you mid-project. Healthcare projects often need significant upfront investment, and if that funding is not locked in on time, the project stalls or dies before it delivers anything. The biggest financial risk specific to this industry is simply the cost of delivering the services, which is high and genuinely hard to predict, because the variables that drive it sit partly outside your control. You manage it with careful budgeting, funding secured in advance, and contingency plans for when costs run over, since they often will. The other side is revenue loss: if the project earns less than projected, you want to have estimated conservatively, monitored the revenue stream closely so you see the shortfall coming rather than discovering it at quarter end, and kept a plan in reserve for the gap.
Regulatory risks come from the dense web of law the industry operates under. A change in the regulatory environment, a weak compliance process, or a failure to meet a required standard can each cause real damage. Healthcare projects answer to rules governing the quality and safety of care, such as the Health Insurance Portability and Accountability Act (HIPAA) in the handling of patient information and Food and Drug Administration (FDA) regulations where medical devices and software are involved, and falling short can bring serious penalties or even shut the project down entirely. The defense is a thorough compliance assessment before work begins, so you know which rules apply before you have built anything that violates them, processes that keep you compliant as you go rather than as a scramble at the end, and contingency plans for the moment a standard is not met.
Operational risks live in the day-to-day running of the project. Inadequate staffing, equipment failure, or delivery delays all belong here. Staff a project too thinly and it cannot meet demand; let a critical piece of equipment fail and services get delayed or cancelled outright, which in a clinical setting is not an inconvenience but a care problem. The way through is correct planning and staffing, equipment that is in place and in good working order with maintenance accounted for rather than assumed, and, once again, a contingency plan for the failures and delays you cannot rule out. Operational risk is the most ordinary of the three and the easiest to underestimate precisely because it is so mundane.
The risks of delivering in healthcare are diverse and tangled, and they do not announce themselves politely. Sort them into financial, regulatory, and operational, plan for each on time, and you turn a field of landmines into a map. The teams that take patients seriously are the ones that take this boring, deliberate work seriously first.