No products in the cart.
MODULE 16: IMPLEMENTATION & GO-LIVE STRATEGIES
Section 5: Lessons Learned and Continuous Support
Formalize the knowledge gained from the implementation experience. We’ll cover how to conduct a post-launch lessons learned session and how to successfully transition the project from the implementation team to the long-term operational support structure.
SECTION 16.5
Lessons Learned and Continuous Support
Closing the Loop, Cementing the Knowledge, and Building the Future.
16.5.1 The “Why”: The Professional Obligation to Learn and Transition
In your pharmacy career, the concept of a “sentinel event review” or a “root cause analysis” is a sacred process. When a serious medication error occurs, the goal is not to punish an individual but to rigorously dissect the process to understand how the system failed, and then to implement changes to prevent that failure from ever happening again. This professional obligation to learn from experience is the very soul of a culture of safety. Similarly, after successfully launching a new pharmacy service, you don’t just walk away. You update the policy and procedure manual, you standardize the workflow, and you ensure every team member is competent in the new standard of practice. These are acts of professional closure.
This final section of the module applies that same professional rigor to the discipline of project management. A project that simply ends the day the command center closes is an abject failure of leadership. It leaves behind a mountain of valuable, hard-won experience that evaporates as the team disbands, virtually guaranteeing that the next project team will stumble into the exact same pitfalls. Furthermore, it leaves a powerful new clinical system as a “digital orphan,” without a clearly defined long-term home for support, maintenance, and growth.
Here, we will master the two essential acts of professional project closure. First, the Lessons Learned session, a formal, blame-free process to harvest the collective intelligence of the project team and convert it into a permanent asset for the organization. Second, the Transition to Continuous Support, the deliberate and formal handoff of the system from the temporary project team to the permanent operational support structure. Mastering these final steps is what separates a mere implementer from a true informatics leader. It is how you ensure that the value of your project endures and that the organization as a whole becomes smarter, safer, and more capable with every implementation it undertakes.
Analogy: Launching and Sustaining a New Anticoagulation Clinic
You have just spent six months leading the launch of your hospital’s first pharmacist-led anticoagulation clinic. The launch was a massive undertaking involving credentialing, protocol development, software implementation, and physician outreach. The clinic is now open and seeing patients.
Act 1: The Lessons Learned Session
Two months after opening, you schedule a mandatory four-hour meeting with the entire project team: the pharmacists who staff the clinic, the lead pharmacy technician, the scheduling clerk, the primary care physician champion, and the IT analyst who helped build the EMR documentation tools. This is a formal, facilitated session.
- What went well? The pharmacists report that the collaborative practice agreement you developed is excellent and gives them the perfect amount of autonomy. The physician champion agrees that patient satisfaction has been off the charts.
- What went poorly? The scheduling clerk reports that the first month was a nightmare of double-bookings and confusion because the new scheduling software wasn’t properly tested. The IT analyst admits the initial training on the documentation tools was too brief and caused a lot of user frustration.
- What would we do differently? The team collectively agrees that for the next clinic launch (e.g., a diabetes clinic), they will dedicate a full week to mock-scheduling and software testing, and double the length of the hands-on training for documentation.
Act 2: The Transition to Continuous Support
For the first three months, you, as the project lead, were the “single point of contact.” You handled IT problems, managed staffing shortages, and ordered supplies. This is “Project Mode” and is not sustainable. The transition to “Operational Mode” is a formal handoff.
- The day-to-day management of the clinic, including pharmacist staffing and performance reviews, is formally handed over to the Ambulatory Pharmacy Manager. This is now part of their permanent operational duties.
- The IT Help Desk (Tier 1 Support) is trained on how to handle basic software issues like password resets. They are given a knowledge base article you wrote.
- The permanent IT application analyst who supports ambulatory systems (Tier 2 Support) is now the escalation point for more complex software issues. You conduct a detailed knowledge transfer session with them.
- You, the informatics project pharmacist, are now only contacted for the most complex clinical workflow design questions that the manager and IT analyst cannot solve (Tier 3 Support). Your project is complete. The clinic is now a stable, living part of the pharmacy department.
16.5.2 The Lessons Learned Session: A Masterclass in Professional Reflection
The Lessons Learned session is one of the most valuable and frequently skipped events in the project lifecycle. It is a structured, facilitated meeting that should occur a few weeks after the stabilization phase concludes, once the dust has settled but the memories are still fresh. Its purpose is singular and sacred: to conduct a blame-free, honest assessment of the entire project lifecycle to identify strengths to be repeated and weaknesses to be corrected in the future. This is not a grievance session or an opportunity to point fingers. It is a professional post-mortem focused entirely on improving the organization’s implementation methodology.
The Psychology of a Safe Space
The success or failure of a Lessons Learned session rests entirely on the facilitator’s ability to create a psychologically safe environment. The session must begin with a clear statement of the ground rules, the most important of which is the “Prime Directive” of project post-mortems:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
This single statement shifts the focus from blaming individuals (“Why did Bob miss that deadline?”) to analyzing the process (“What factors in our process led to that deadline being missed?”). Without this foundation of blame-free inquiry, you will get defensive posturing, not honest reflection.
Masterclass Table: The Lessons Learned Session Agenda
| Time | Topic | Objective | Key Questions |
|---|---|---|---|
| 0:00 – 0:15 | Introduction & Ground Rules | Set the stage, state the purpose, and establish the principles of a blame-free, process-focused discussion. | “What is our goal for today? What are the rules of engagement?” |
| 0:15 – 1:15 | What Went Well? (The “Keepers”) | Identify the successes and strengths of the project. This starts the meeting on a positive note and identifies best practices that must be standardized for future projects. | “What were our biggest wins? Which processes worked flawlessly? Which tools were indispensable? Who were our unsung heroes and why were they so effective?” |
| 1:15 – 2:30 | What Went Poorly? (The “Fixers”) | Conduct an honest and open discussion of the challenges, failures, and frustrations encountered during the project. This is the core of the session. | “Where did our process break down? What were our biggest sources of friction or rework? What assumptions did we make that turned out to be wrong? What risks did we fail to anticipate?” |
| 2:30 – 2:45 | Break | Allow the team to decompress and recharge. | N/A |
| 2:45 – 3:45 | What Would We Do Differently? (The “Action Items”) | Convert the “What Went Poorly” discussion into concrete, actionable recommendations. This is the most important part of the meeting. | “For each of the challenges we identified, what is a specific, tangible action we can take to prevent it on the next project? How can we turn this lesson into a checklist item, a template, or a policy?” |
| 3:45 – 4:00 | Wrap-up & Next Steps | Summarize the key takeaways, assign owners to the action items, and communicate the timeline for publishing the final Lessons Learned report. | “What are our key takeaways? Who is responsible for what? What happens next?” |
The Facilitator’s Question Bank
A great facilitator comes prepared with probing questions to guide the discussion away from complaints and toward constructive analysis. Here is a sample question bank, organized by project phase, that a pharmacy informatics leader should be prepared to ask:
- Project Initiation & Planning:
- Did we have the right people involved in the initial scoping and planning? Whose voice was missing?
- Were our initial goals and objectives clear and measurable? Did they change over time?
- How accurate were our initial estimates for timeline and resources? What caused the biggest variances?
- System Build & Design:
- Did our design sessions effectively capture the needs of the frontline pharmacy staff? How could we improve that engagement?
- Did we spend enough time on workflow analysis before we started building?
- Were there any major design decisions we had to reverse late in the project? Why?
- Testing & Training:
- Were our testing scenarios realistic enough? Did they uncover the types of issues we saw at go-live?
- Did our training curriculum focus on the right things? What was the biggest knowledge gap for users after training?
- Was our super-user program effective? How could we better prepare them to be a first line of support?
- Go-Live & Stabilization:
- Was the command center structure and staffing model appropriate for the scale of our go-live?
- Was our issue triage and escalation process efficient? Were there bottlenecks?
- Did our at-the-elbow support plan provide enough coverage? Were there any departments or shifts that felt unsupported?
16.5.3 The Handoff: The Formal Transition from Project to Operations
The formal handoff from the temporary project team to the permanent operational support team is a critical milestone that marks the true end of the implementation. An informal, poorly defined handoff is a recipe for long-term problems. It creates ambiguity about who is responsible for the system, leading to dropped support tickets, frustrated users, and a failure to perform routine maintenance. A successful handoff is a deliberate process of knowledge transfer, documentation delivery, and formal acceptance of responsibility.
This transition is a fundamental shift in mindset and structure, as illustrated below:
Visualizing the Handoff: Project Mode vs. Operational Mode
Project Mode
- Focus: Build & Deploy
- Team: Temporary, cross-functional
- Pace: High-intensity sprints
- Goal: Meet go-live date
FORMAL HANDOFF
Knowledge Transfer & Documentation
Operational Mode
- Focus: Maintain & Optimize
- Team: Permanent, functional
- Pace: Stable, sustainable
- Goal: Ensure reliability & value
Masterclass Table: The Handoff to Operations Checklist
| Category | Handoff Item | Definition of Done |
|---|---|---|
| Documentation | System “Cookbook” | All technical documentation detailing the system build, configuration choices, and interface mapping is finalized and stored in a central, accessible repository. |
| Workflow & Policy Documents | All clinical workflow diagrams and associated policies and procedures that were updated for the project are finalized, approved, and published. | |
| Help Desk Knowledge Base | A set of Tier 1 support articles for the top 10-20 most common user questions and issues has been created and delivered to the IT Help Desk. | |
| Knowledge Transfer | Formal Training Sessions | The project’s application analysts have conducted formal, scheduled training sessions for the permanent operational support team, walking them through the system build and support processes. |
| “Shadowing” Period | Members of the operational support team have shadowed the project team during the final weeks of stabilization to see how issues are worked and resolved in real-time. | |
| Formal Acceptance | Support Model Finalized | The tiered support model, including on-call schedules and escalation paths for the permanent team, is documented and approved. |
| Handoff Sign-off Document | A formal document is signed by the Project Manager and the Director of IT/Clinical Applications, signifying that the project is closed and the system is now under the ownership and care of the operational team. |
16.5.4 Architecting the Continuous Support Model: Your Long-Term Home
Once the project is formally closed, the work on the system is only just beginning. A clinical information system is not a static object; it is a dynamic, living entity that requires continuous care and feeding to remain effective. This long-term care is provided by the permanent operational support team, operating within a structured, tiered support model. For many members of the project team, including pharmacy informaticists, this operational team becomes their new permanent home.
The tiered support model is the industry standard for providing efficient, effective, and scalable IT support. It structures support into layers, ensuring that routine issues are handled quickly at the lowest level, freeing up high-skilled experts to focus on the most complex problems.
Visualizing the Tiered Support Model
Tier 3: Vendor / Developers
Deepest technical experts. Handle core application bugs, database issues, hardware failures.
Tier 2: Application / Clinical Analysts
(Your new home). System owners and stewards. Handle complex workflow issues, system configuration changes, optimization requests, and data analysis. Escalate to Tier 3.
Tier 1: The IT Help Desk
The “front door” for all support requests. Handle high-volume, low-complexity issues (password resets, “how-to” questions) using a knowledge base. Escalate to Tier 2.
End-Users (Pharmacists, Nurses, Physicians)
Report all issues to Tier 1.
The Pharmacist Informaticist’s Evolving Role: From Builder to Steward
Your role undergoes a profound and rewarding transformation after the handoff. You are no longer just a temporary project resource; you are now a permanent system steward or product owner for the medication management components of the EHR. This is a position of significant, ongoing responsibility and influence.
Your new operational duties include:
- Tier 2 Support Expert: You are the designated expert for resolving complex medication-related support tickets that the Help Desk cannot solve.
- Optimization & Governance Leader: You are a key member, and often the leader, of the governance committee that reviews and prioritizes all enhancement requests related to pharmacy and medication use.
- Data-Driven Analyst: You are responsible for monitoring the KPIs you established during stabilization. You will use this data to proactively identify problems and opportunities for improvement, and to build business cases for new optimization projects.
- Keeper of the Clinical Flame: You are the guardian of the system’s clinical integrity, ensuring that future changes and updates are safe, evidence-based, and aligned with best practices.
This transition from the frantic pace of a project to the deliberate, strategic work of long-term system ownership is a hallmark of a mature and successful informatics career.
