Project, Product, Change, and Process Improvement

Project management organizes temporary work toward defined deliverables. It addresses scope, schedule, resources, dependencies, risks, communication, and completion. Informatics projects include EHR upgrades, module implementations, integrations, migrations, and enterprise standardization efforts.

Product thinking manages an evolving capability rather than a one-time launch. A clinical documentation platform is never truly “finished.” New regulations, workflows, users, defects, and opportunities appear. Product thinking asks how the capability creates value over time, which improvements deserve priority, and what should not be built.

Change management focuses on people moving from current behavior to future behavior. It considers readiness, sponsorship, communication, training, local leadership, resistance, reinforcement, and identity. Change management cannot rescue a fundamentally poor workflow, but even a good design can fail without it.

Process improvement focuses on how work produces outcomes. Lean, PDSA, process excellence, and other methods identify waste, variation, bottlenecks, defects, and opportunities to redesign. Training is only one possible intervention; process improvement asks why the undesired behavior occurs.

Scope defines the boundaries of commitment. A project without clear scope gradually accumulates “small” additions until testing, training, and timeline become unreliable. Scope should identify what is included, excluded, assumed, and dependent on other teams.

Milestones mark meaningful readiness, not just dates. “Build complete” should have a definition. “Ready for UAT” should mean prerequisites are satisfied. Milestones become misleading when dates remain fixed but the meaning of completion quietly erodes.

Dependencies deserve explicit tracking. Training may depend on stable build. Interface testing may depend on vendor test data. Go-live may depend on role provisioning. A project can appear on schedule until a hidden dependency becomes critical.

Risks are uncertain future events; issues are problems already occurring. Mixing them weakens management. A risk register should identify likelihood, impact, mitigation, trigger, and owner. An issue log should identify current consequence, decision needed, and accountable owner.

Decision logs protect institutional memory. Projects often revisit the same arguments because rationale was never captured. A brief record of the decision, alternatives, evidence, owner, date, and consequences reduces circular debate and supports future optimization.

Agile is an approach to learning through iterative delivery and feedback, not an excuse to avoid requirements. The team still needs a problem definition, priorities, acceptance criteria, and architectural constraints. The difference is that work is broken into smaller increments so assumptions can be tested earlier.

Backlogs should represent value and learning, not a dumping ground for requests. A well-managed backlog identifies why an item matters, who benefits, dependencies, risk, and evidence. Hundreds of undifferentiated tickets are not a product strategy.

Iteration is valuable when feedback can change the next step. Demonstrating a prototype after all critical design choices are fixed is not meaningful iteration. Early prototypes should expose assumptions about workflow, content, and usability while change is still affordable.

Healthcare requires constraints that ordinary software teams may underestimate. Regulatory obligations, patient safety, data migration, validation, interface dependencies, training cycles, and downtime plans can limit how rapidly a clinical system can change. Agile principles need adaptation, not ritual imitation.

Resistance is information before it is a behavior problem. Users may resist because they do not understand the change, because the workflow is poor, because local expertise was ignored, because workload is already high, or because the change threatens role identity or autonomy. Informatics should distinguish these mechanisms before prescribing communication or training.

Sponsorship is different from approval. A sponsor actively removes barriers, communicates priority, makes decisions, and reinforces the change. A leader who signs a charter but disappears during conflict is not providing effective sponsorship.

Readiness varies across groups. Different units may have different staffing, leadership stability, device access, prior experience, and competing initiatives. Enterprise standardization does not require pretending that every site begins from the same condition.

Training addresses knowledge and skill gaps; it does not fix poor design. If users know what to do but the workflow is slow, confusing, or misaligned, retraining may temporarily improve compliance while preserving the source of frustration.

Reinforcement must connect new behavior to visible consequences. Post-go-live leadership, local support, performance feedback, issue resolution, and recognition of valid concerns help new workflows stabilize. Change is not complete when class attendance reaches 100%.

Improvement begins with a measurable aim. “Improve documentation” is weak. “Reduce median time from wound identification to completed assessment from 18 hours to 6 hours without increasing duplicate assessments” is testable and includes a balancing concern.

Measures should include outcomes, processes, and balancing measures. Outcome measures show whether the goal improved. Process measures show whether the intended mechanism occurred. Balancing measures detect harm shifted elsewhere. A faster workflow that increases missing data is not an unqualified improvement.

PDSA supports small tests of change. Plan the change and prediction, Do it at a limited scale, Study what occurred, and Act by adapting, adopting, or abandoning the approach. PDSA is a learning cycle, not a documentation form.

High reliability emphasizes sensitivity to operations and preoccupation with failure. Informatics teams should pay attention to weak signals such as workarounds, near misses, and recurring exceptions rather than waiting for a major event. Standardization supports reliability when it reduces unnecessary variation, but rigid standardization can be unsafe if local clinical differences are meaningful.

Root causes are often networks, not single causes. Complex failures usually involve interacting conditions. Improvement teams should avoid stopping at “user did not follow procedure” when system design, workload, training, environment, and policy also contributed.