CPIA Module 15, Section 1: Project Lifecycle and Scope Definition
MODULE 15: PROJECT MANAGEMENT FOR INFORMATICS INITIATIVES

Section 15.1: Project Lifecycle and Scope Definition

Learn the foundational phases of any project (Initiation, Planning, Execution, Closure) and master the single most important document: the Project Scope Statement. We’ll teach you how to define clear boundaries to prevent “scope creep” and ensure everyone agrees on the definition of “done.”

SECTION 15.1

Project Lifecycle and Scope Definition

Building the Blueprint for Success Before a Single Line of Code is Written.

15.1.1 The “Why”: From Pharmacist to Architect of Change

As a pharmacist, your entire career has been a form of project management, executed on a micro-scale with every prescription you fill. You receive an initial request (the prescription), you plan the workflow (data entry, DUR, filling, verification), you execute the plan (dispensing), and you close the loop (counseling and documentation). You are, by nature of your training, a master of process, detail, and risk mitigation. The world of pharmacy informatics does not ask you to abandon these skills; it asks you to scale them. Instead of managing a single prescription, you will manage the implementation of a system that processes thousands of them. Instead of ensuring one patient’s safety, you will architect a workflow that protects an entire hospital.

The term “project management” often conjures images of complex Gantt charts, dense spreadsheets, and managers with headsets. While those tools have their place, the essence of project management is far simpler and more fundamental: it is the structured application of common sense to achieve a specific goal. It is the framework that prevents promising ideas from devolving into chaotic, over-budget, and ultimately failed initiatives. For an informatics pharmacist, mastering these principles is not an administrative burden; it is a core clinical competency. It is the skill that translates your brilliant idea for a better, safer medication process from a concept into a functional, adopted, and successful reality.

Why is this so critical? Because in healthcare IT, the landscape is littered with the ghosts of failed projects. Projects that started with a simple goal—”let’s improve our CPOE system”—and spiraled out of control, becoming bloated, unmanageable monsters that nobody wanted and nobody used. These failures are almost never technical; they are failures of definition, communication, and control. They are failures of project management. This section is your foundation in preventing those failures. We will deconstruct the universal lifecycle of any project and provide an exhaustive masterclass on its most vital document: the Project Scope Statement. This is where you move from being a participant in the system to being an architect of its improvement.

Retail Pharmacist Analogy: Launching a New Clinical Service

Imagine your pharmacy manager tasks you with a major initiative: “I want us to launch a comprehensive Medication Therapy Management (MTM) and point-of-care testing service for diabetes and hypertension. You’re in charge. Make it happen.”

Your pharmacist brain immediately kicks into a structured, project-based mode, whether you call it that or not. You are instinctively following the project management lifecycle:

  • Initiation: You don’t just start buying a glucose meter. You first ask the fundamental questions. What is the goal? (Increase revenue, improve patient outcomes, achieve a higher star rating). Who needs to be involved? (The pharmacy owner, the other pharmacists, the technicians, the district manager). You draft a one-page summary of the idea, its goals, and who is on the team. This is your Project Charter.
  • Planning: This is the deep work. You break down the massive goal into smaller pieces.
    • Scope Definition: You decide exactly what this service will include. “We will do fingerstick A1c and blood pressure checks. We will NOT do lipid panels or any CLIA-waived tests requiring a separate license for now.” This is you defining your Inclusions and Exclusions.
    • Work Breakdown: You list every single task: research state laws, purchase equipment, develop documentation forms, create a marketing flyer, train the staff, design the workflow for scheduling and billing. This is your Work Breakdown Structure.
    • Scheduling & Budgeting: You estimate how long each part will take and how much the equipment and supplies will cost.
  • Execution: This is the “Go” phase. The team starts working on the tasks you defined. You’re ordering the A1c machine, the other pharmacist is writing the training manual, a tech is clearing space in the consultation room. Your job is to make sure everyone is on track, answer questions, and solve problems as they arise.
  • Closure: The service is launched. Is the project done? No. The closure phase begins. You gather feedback from the first few patients. You review the billing reports to see if it’s profitable. You hold a meeting with the staff to discuss what went well and what didn’t (Lessons Learned). You get the pharmacy owner to formally sign off that the initial launch phase is complete and successful.

The rigor, foresight, and structured thinking you would apply to this pharmacy initiative are the exact same skills required for a major informatics project. Whether you’re launching an MTM service or a new automated dispensing cabinet configuration, the principles of defining your goals, planning your work, executing the plan, and formally closing it out remain the universal path to success.

15.1.2 A Deep Dive into the Project Management Lifecycle

Every project, from building a skyscraper to updating a single order set in the EHR, follows a predictable and logical progression. This progression is known as the project management lifecycle. Understanding these distinct phases allows you to apply the right tools and ask the right questions at the right time. It provides a roadmap that turns a chaotic journey into a structured and manageable process. The four primary phases are Initiation, Planning, Execution, and Closure.

The Four Phases of a Project

1
Initiation

The “Should We?” Phase. Defining the idea, the problem, and the high-level goal.

2
Planning

The “How Will We?” Phase. Creating the detailed blueprint for success.

3
Execution

The “Let’s Do It” Phase. Performing the work defined in the plan.

4
Closure

The “Did We Do It?” Phase. Finalizing, handing off, and learning.

Phase 1: Initiation – From Idea to Official Project

The Initiation phase is the birth of a project. It is where a vague idea, a persistent problem, or a strategic goal is formally recognized and given the legitimacy to proceed to the planning stage. The primary goal of this phase is not to plan the entire project, but to determine if the project is feasible, valuable, and aligned with organizational goals. Skipping this phase is like starting a road trip without deciding on a destination; you’ll be busy, but you won’t get anywhere meaningful.

As an informatics pharmacist, you will often be the one originating the ideas. You might notice a recurring type of medication error and think, “There should be a clinical decision support (CDS) alert for this.” The Initiation phase is how you take that spark of an idea and turn it into a proposal that leadership can evaluate and approve.

Key Activities and Deliverables of the Initiation Phase
Activity Description Pharmacist’s Role & Informatics Example
Problem/Opportunity Definition Clearly articulating the problem the project will solve or the opportunity it will capture. This is the “why” behind the project. You observe that nurses on the oncology floor are manually calculating and documenting BSA-based chemotherapy doses, leading to frequent errors and delays. You document 3 recent safety events related to this manual process. The problem is patient safety risk and workflow inefficiency.
High-Level Goal Setting Defining what “success” looks like in broad terms. This should be a concise statement of the desired future state. The goal is to “implement an EHR feature that automatically calculates and documents BSA for chemotherapy orders, reducing calculation errors by 90% within six months of go-live.”
Initial Stakeholder Identification Identifying the key people and groups who will be affected by, or can influence, the project. This includes sponsors, end-users, and technical teams. You identify the stakeholders: Sponsor: Chief Nursing Officer (CNO). End-Users: Oncology nurses, oncology pharmacists. Technical Team: EHR analyst team. Clinical Leadership: Chair of the Oncology department.
Feasibility Analysis A preliminary assessment of whether the project is viable. This considers technical feasibility (Can our EHR even do this?), resource feasibility (Do we have an analyst available?), and financial feasibility (Is there a budget for this?). You have a 15-minute conversation with a lead EHR analyst. “Hey, is there a module for BSA calculations we don’t have turned on, or would this need to be custom-built?” The analyst confirms a standard feature exists but needs configuration. This confirms technical feasibility.
Develop Project Charter (KEY DELIVERABLE) A formal, high-level document that summarizes the project’s objectives, identifies the main stakeholders, and authorizes the project manager to proceed with planning. It’s the project’s official birth certificate. You draft a 1-2 page document titled “Project Charter: Automated BSA Calculations for Chemotherapy.” It includes the problem statement, the project goals, the key stakeholders, a high-level timeline (e.g., “Q3 implementation”), and a space for the CNO to sign, officially authorizing the project.
The Power of the Project Charter

Do not underestimate the importance of the Project Charter, even if it feels overly formal for a small project. Its power is political and psychological. The moment a sponsor (like a Director of Pharmacy or CNO) signs that document, your project is no longer just “a good idea you had.” It is now an officially sanctioned, recognized initiative of the organization. This signature grants you, the project lead, the authority to assemble a team, schedule meetings, and request resources. It is your shield and your mandate. When someone later asks, “Why are we spending time on this?” you can point to the charter and say, “Because our leadership has officially authorized it as a strategic priority.”

Phase 2: Planning – Building the Master Blueprint

If Initiation is deciding on the destination, the Planning phase is creating the turn-by-turn directions, calculating the fuel needed, packing the car, and checking the weather. This is, without question, the most critical and labor-intensive phase of the project lifecycle. The quality of your planning will directly determine the success or failure of your project. A common mistake made by enthusiastic but inexperienced project leads is to rush through planning to get to the “real work” of execution. This is a fatal error. Time spent in meticulous planning is saved tenfold during execution.

During this phase, you take the high-level vision from the Project Charter and decompose it into a detailed, actionable plan. You will define precisely what will be delivered, how it will be delivered, who will do the work, when it will be done, and how you will manage the inevitable challenges that arise. This is where your pharmacist’s attention to detail becomes your greatest superpower.

Key Activities and Deliverables of the Planning Phase
Activity Description Pharmacist’s Role & Informatics Example
Requirement Gathering The process of identifying and documenting the specific needs and expectations of the stakeholders. What must the final product do to be considered successful? You conduct sessions with oncology nurses and pharmacists. You ask detailed questions: “Where in the workflow should the BSA calculation appear? Which formula should be used (e.g., Mosteller, Du Bois)? What should happen if the height or weight is missing? Should the dose auto-populate in the order?” You document these as specific requirements.
Scope Definition (THE MOST IMPORTANT DELIVERABLE) Creating the Project Scope Statement. This document provides a detailed description of the project, its major deliverables, assumptions, and constraints. Crucially, it defines the project’s boundaries by explicitly stating what is included and what is excluded. Using the requirements, you create the Scope Statement. An exclusion might be: “This project will not address chemotherapy dose calculations based on AUC (e.g., carboplatin) or other non-BSA-based regimens. It will also not change the formulary status of any chemotherapy agent.” This prevents scope creep.
Work Breakdown Structure (WBS) Decomposing the major project deliverables into smaller, more manageable components called “work packages.” This is the foundation for scheduling and resource allocation. You break down the “BSA Calculation Feature” deliverable into tasks like: 1. Configure the Mosteller formula in the test environment. 2. Build the user interface display. 3. Test the calculation with 20 patient scenarios. 4. Write the training documentation. 5. Schedule end-user training sessions.
Scheduling & Resource Planning Assigning durations to each task in the WBS and identifying who is responsible for completing them. This results in a project schedule or timeline (e.g., a Gantt chart). You estimate the EHR analyst needs 20 hours for configuration and testing. The lead oncology pharmacist needs 8 hours to develop testing scenarios and review the build. You need 10 hours for project management and documentation. You map this out on a shared calendar or timeline.
Risk Assessment Proactively identifying potential threats to the project’s success and planning responses to them. What could go wrong, and what will we do if it does? You identify a risk: “The EHR analyst assigned to our project might be pulled onto a higher-priority regulatory project, delaying our timeline.” The mitigation plan is: “Meet with the IT manager to confirm our project’s priority and identify a backup analyst if possible.”
Communication Plan Defining how, when, and to whom project information will be communicated. This ensures all stakeholders are kept appropriately informed. You decide: “I will send a bi-weekly summary email to all stakeholders. I will hold a 30-minute status meeting with the core project team every week. Any critical issues will be escalated to the CNO via phone call immediately.”

Phase 3: Execution & Monitoring – Performing the Work

The Execution phase is where the plan is put into action. The project team begins the hands-on work of creating the deliverables defined during planning. For an informatics project, this is where the EHR analysts are building, the subject matter experts are testing, and the trainers are developing materials. It is often the longest phase of the project and can feel like the “busiest,” but if the planning was done well, it should be a period of controlled, productive activity, not chaos.

Your role as the project lead shifts from architect to orchestra conductor. You are not doing all the work yourself, but you are ensuring that all the different sections are playing in harmony and on tempo. This phase is inextricably linked with “Monitoring and Controlling.” You are constantly comparing your actual progress against the plan you created, identifying deviations (variances), and taking corrective action to get back on track.

Key Activities during the Execution & Monitoring Phase
Activity Description Pharmacist’s Role & Informatics Example
Direct & Manage Project Work Leading the project team, assigning tasks, clearing roadblocks, and making day-to-day decisions to facilitate the completion of the project deliverables. The EHR analyst has a question about the rounding rules for the BSA result. You facilitate a quick 10-minute call with the lead oncology pharmacist to get a definitive clinical answer, allowing the analyst to proceed without delay. You are the central hub of communication.
Status Tracking & Reporting Regularly measuring project progress against the schedule and budget. This information is then compiled into status reports as defined in the communication plan. Every Friday, you update a simple project dashboard: “Task 1 (Build Configuration): 100% complete. Task 2 (Initial Testing): 75% complete, on schedule. Budget Spent: $5,000 of $15,000.” You then email this summary to your stakeholders.
Quality Management Ensuring that the work being performed meets the quality standards defined in the plan. This often involves peer review and testing throughout the phase, not just at the end. Before the build is released for formal user testing, you and the lead oncology pharmacist spend two hours in the test environment, running your own scenarios to catch any obvious bugs or usability issues. This is an internal quality check.
Manage Stakeholder Engagement Actively communicating with stakeholders, managing their expectations, and addressing any issues or concerns they may have to keep them supportive of the project. You hear a rumor that some nurses are worried the new feature will “dumb down” their practice. You proactively schedule a brief demo at their next staff meeting to show them how it works, answer their questions, and get their buy-in by highlighting the safety benefits.
Change Control Managing any requested changes to the project’s scope. This involves a formal process for reviewing, approving (or rejecting), and documenting any change that alters the original plan. During a demo, the Chair of Oncology says, “This is great! While you’re at it, can you also make it calculate carboplatin doses using the Calvert formula?” You reply, “That’s an excellent idea for a future enhancement. Per our scope, this project is limited to BSA. I’ll document your request and we can evaluate it as a separate project after we successfully go live with this one.” You have just prevented scope creep.

Phase 4: Closure – Finishing with Finesse

The Project Closure phase is the final and most frequently neglected part of the lifecycle. There is a powerful temptation, once the project is “live,” to declare victory and immediately move on to the next fire. This is a mistake that undermines the current project’s long-term success and prevents the organization from learning from its experiences. The Closure phase is not about stopping work; it’s about formally finalizing all activities, handing off the finished product, and extracting valuable lessons to improve future projects.

Proper closure provides a clean end to the project, ensuring all parties agree it has met its objectives. It provides a smooth transition to the operational teams who will support the new system or workflow long-term, and it creates a historical record and knowledge base that benefits the entire organization. For the project lead, it provides a sense of accomplishment and a final, formal recognition of the team’s hard work.

Key Activities and Deliverables of the Closure Phase
Activity Description Pharmacist’s Role & Informatics Example
User Acceptance Testing (UAT) & Go-Live The final round of testing where end-users validate that the system meets the agreed-upon requirements in a production-like environment. This is followed by the “go-live,” the actual deployment of the new feature for real patient care. You schedule and oversee the UAT sessions where a group of oncology nurses and pharmacists run through pre-defined scripts to test the BSA calculator. After they sign off, you coordinate the go-live event with IT for a Tuesday at 2 AM.
Transition to Operations (Handoff) Formally transitioning the ownership and support of the project’s deliverable from the project team to the permanent operational team (e.g., the IT help desk, the informatics support team). You create a “Support Document” for the IT help desk that explains how the new feature works, lists common troubleshooting steps, and clarifies who to escalate complex issues to (i.e., you or the lead EHR analyst).
Obtain Formal Sign-Off Getting the project sponsor and key stakeholders to formally agree that the project is complete and has met the objectives outlined in the scope statement. This is the official finish line. Two weeks after go-live, you send an email to the CNO (the sponsor) with a “Project Closure Form.” The email summarizes the project’s success metrics (e.g., “150 successful uses, zero related safety events”) and asks for their signature to formally close the project.
Conduct Lessons Learned Session A facilitated meeting with the project team and key stakeholders to discuss what went right, what went wrong, and what could be improved for future projects. You schedule a one-hour meeting with the core team. You ask three questions: “What should we start doing on future projects? What should we stop doing? What should we continue doing?” You document the answers in a Lessons Learned report.
Archive Project Documents Storing all project documentation—the charter, scope statement, risk log, status reports, closure form, lessons learned—in a central, accessible repository. You create a folder on the pharmacy department’s shared drive named “Project – Automated BSA Calculator – Closed [Date]” and save all the final documents there for future reference.
The Danger of the “Soft Launch” and the Never-Ending Project

Without a formal Closure phase, projects don’t end; they just fade away. The “go-live” happens, but because there’s no formal sign-off or handoff, the project team (often just you) becomes the permanent, de facto support team. Six months later, you are still getting calls from end-users about minor issues because there was never a clean transition to the help desk. The project is never officially “done,” so its success is never formally recognized, and the lessons from its execution are lost forever. Insisting on a formal closure process protects your time, ensures long-term sustainability, and builds a culture of continuous improvement.

Masterclass: The Project Scope Statement

Of all the documents you will create in your project management journey, none is more important than the Project Scope Statement. It is the constitution of your project. It is the single source of truth that defines the project’s boundaries and the shared understanding of what the project team will deliver. A clear, comprehensive, and agreed-upon scope statement is the number one predictor of project success. A vague, ambiguous, or non-existent scope statement is a guaranteed recipe for the dreaded “scope creep”—the slow, insidious addition of new features and requirements that bloat your project, destroy your timeline, and exhaust your team.

This document is not created in a vacuum. It is the direct output of the stakeholder requirement gathering process. It translates their wants and needs into a detailed, structured definition of the project’s deliverables. Every single stakeholder, from the project sponsor to the end-users, must review and agree to this document before a single hour of development work begins.

The Anatomy of a Bulletproof Scope Statement

A robust scope statement contains several key components, each serving a specific purpose in defining the project’s boundaries.

1. Project Description / Justification

This section provides a high-level narrative of the project. It builds upon the problem statement from the charter, explaining the business need and why this project is being undertaken. It sets the context for everyone reading the document.

Example (BSA Calculator Project): “The current process for chemotherapy dosing requires oncology nurses to manually calculate Body Surface Area (BSA), transcribe the result, and have it independently double-checked. This manual process is inefficient and has been linked to several medication safety events involving calculation and transcription errors. This project will implement a feature within the core EHR to automate the BSA calculation and documentation, thereby improving patient safety and nursing efficiency.”

2. Project Objectives

This section defines the measurable criteria that will be used to determine if the project is a success. The best objectives are crafted using the SMART methodology: Specific, Measurable, Achievable, Relevant, and Time-bound.

The SMART Framework for Objectives
  • Specific: State exactly what you want to accomplish.
  • Measurable: Include metrics to track progress and determine success.
  • Achievable: Ensure the objective is realistic given your resources and constraints.
  • Relevant: The objective must align with the overall project and organizational goals.
  • Time-bound: State the target date for completion.

Example Objective: “To reduce the number of reported BSA calculation errors on the oncology unit by 95% within 3 months of the go-live date.”

3. Project Deliverables

A deliverable is any tangible, verifiable product, result, or capability that must be produced to complete the project. This is a list of the “what” the project will create.

Example (BSA Calculator Project):

  • A configured and tested BSA calculation feature in the production EHR environment.
  • A training guide for end-users (nurses and pharmacists) on how to use the new feature.
  • Completed training for 100% of oncology nursing and pharmacy staff.
  • A support handoff document for the IT help desk.

4. Exclusions (The “Out of Scope” List)

This is arguably the most important, and most confrontational, section of the entire document. It explicitly lists what the project will NOT do. Its purpose is to eliminate ambiguity and prevent false expectations. By forcing stakeholders to agree on what is out of scope upfront, you create your primary defense against scope creep later. Be ruthlessly clear and specific in this section.

Example (BSA Calculator Project):

  • This project will not create or modify any chemotherapy order sets.
  • This project will not address non-BSA based dosing calculations (e.g., Calvert formula for carboplatin).
  • This project will not alter the workflow for pharmacist order verification.
  • This project will not develop any new analytical reports for management.
  • This project will not be implemented outside of the inpatient oncology and infusion center units.

5. Constraints

Constraints are limitations or restrictions that the project must operate within. The most common are time (schedule), cost (budget), and resources (people/equipment). Documenting them sets realistic expectations.

Example (BSA Calculator Project):

  • The project must be completed by the end of Q3 to align with the hospital’s annual safety goals.
  • The total project budget, including vendor fees and internal labor, cannot exceed $25,000.
  • The project is limited to 40 hours of a single EHR analyst’s time.

6. Assumptions

Assumptions are factors that are considered to be true, real, or certain for the purpose of planning, even without proof. Documenting assumptions is critical because if they turn out to be false, they can pose a significant risk to the project.

Example (BSA Calculator Project):

  • It is assumed that the existing EHR hardware is sufficient to support the new feature.
  • It is assumed that key stakeholders (lead nurses, pharmacists) will be made available for testing and training as scheduled.
  • It is assumed that the vendor’s standard BSA calculation functionality will meet all clinical requirements without the need for custom development.