Building a Plan
Each project execution methodology has recommended processes for developing a project plan and schedule. All of these should yield an appropriate plan, but some aspects of healthcare project management need to be considered before finalizing your plan.
■ Requirements
In order to be implemented, IT systems and products need to meet certain requirements that are defined by the end-user. These requirements, also known as design input, must be developed at the early stages of the project, approved, and maintained throughout the project life cycle. These requirements are critical because they will be the basis for approving implementation of the product the team develops. Therefore, sufficient time should be allotted to develop and refine these requirements, as well as acceptance criteria, which will be used to measure whether the requirements have been met.
■ Documentation standards
Throughout the project execution, certain documents are critical and will come under regulatory compliance scrutiny. These documents include engineering lab books, test records, and final test reports. The documents typically must follow GxP (Good Practices or In Compliance) requirements, which require the information be recorded clearly, using only blue or black ink, with changes being marked with a single strike-through, initialed and dated with an explanation for the change. These regulations are intended to encourage accuracy while preventing adulteration. Organizations typically require all personnel to take GxP documentation training. If not, you should ensure all personnel participating in test execution are familiar with these rules.
■ Document approvals
Regulations require most final deliverable documents to be approved before they may be implemented. This is especially the case when implementing or changing computer systems and processes involving manufacture or distribution of healthcare products, often referred to as GxP requirements. These reviews are a critical aspect of risk mitigation and are not a simple activity. Rather, these activities can derail an otherwise successful project that did not account for this appropriately.
Your project plan must allow enough time for these reviews to be conducted. More importantly, the team must proactively engage approvers, familiarizing them with the nature of the changes being proposed, perform tests to demonstrate the process or item will perform as designed, and that appropriate controls are in place to ensure errors can be easily identified, contained, and corrected. This communication should also identify the critical reviewers for each process area. These approvers should be actively managed early in the process, ensuring their needs are addressed in the document and supporting materials. This will expedite the approval process.
■ Validation
Any system or process that will be executed automatically, with limited or no inspection, must be validated, ensuring the team has statistically demonstrated that process outputs meet requirements. In most industries, this is accomplished through testing. In healthcare, validation testing is more formal, requiring a greater level of documentation and evidence collection. The validation tests must be defined in an approved validation protocol, with results summarized in a completion report that describes the statistical basis for concluding the validation was successful. This report must also describe all failures or changes to the protocol, along with a description of how the issue affected the outcomes and what actions, if any, the project team took in order to ensure requirements are met.
■ Training
It is natural to expect process and document changes to be communicated, but most regulatory bodies require training to be conducted, documented, and stored so it may be presented as evidence. Training delivery is often complicated by the number and span of locations, where the process is performed. In many cases, especially for more complex or critical processes, computer- based training (CBT) must be developed and deployed in an organization’s learning management systems (LMS). Simple changes may be communicated through the LMS system also, requiring the user to “acknowledge” awareness of the change by reviewing the revised procedure and recording this acknowledgement in the system.
Projects implementing new processes or functions must also consider how the training audience will be defined, and the extent to which different groups need to be trained. In cases where new regulations are implemented, impacted department managers and leaders will require basic awareness training, while line staff may require more specialized, detailed training delivered via CBT or instructor-led training.
■ Regulatory review
Most projects will not immediately trigger regulatory review, but documentation and process requirements ensure readiness for such audits. However, certain projects where introducing new manufacturing facilities or products are more likely to come under such scrutiny, especially for higher-risk products such as implants, respirators, and other life-sustaining technologies. Regulatory affairs should be questioned about the potential a project would require or trigger a regulatory body (e.g. US FDA or international regulator) inspection or notified body audit. In some cases, regulatory body notifications are required, with a defined waiting period. These types of reviews should be considered and included in your plan, should they apply, or have a significant risk of occurrence.
The project timeline, once drafted, should be reviewed with all key stakeholders to ensure it aligns with their expectations and that planned resources will be available to support planned work when it is expected to be performed.
Longer projects, greater than 2—3 years, should also be evaluated for any new or developing international regulations. Since most regulations are developed and implemented over many years, often in a phased approach, their application may need to be taken into consideration for all, or portions of a project timeline. While this type of dependency should have been highlighted in the WBS phase, adding the time element often highlights the need to take these changes into consideration.
Risk Management
Once a healthcare project is planned, most industry-specific differences will have been considered, and can be managed as any other project. However, a number of the issues previously discussed cannot be completely resolved by the project team. Rather, they need to be constantly monitored over the project’s duration. A robust risk register and management plan will help the team maintain visibility to these issues while proactively remediating these issues before they affect the project. Developing a list of relevant risks needs to be a periodic exercise, with all project team members contributing ideas or concerns, especially for topics relevant to their functional departments. In many cases, project risks are identified during unrelated conversations such as during problem solving or project team meetings. Therefore, all team members should be familiar with the risk register, where it is stored and how it should be used. By documenting risks in near real-time, the team can be confident it will not be unprepared when any of these risks are realized.
Conclusion
Project management in healthcare shares many characteristics with other industries, but some critical facets are unique. Organizations in this industry focus on their mission to improve patient lives, and projects tied to this mission will often garner good organizational support. However, it is critical the project manager define the project in a way to clearly connect its goals to achieving this organizational mission. Projects focused on cost reduction and efficiency without considering the patient experience and customer service is at risk of being de-prioritized, or not gaining the support needed to be successful.
Project managers familiar with the healthcare industry have a significant advantage over those without this experience, since they have cultural awareness that cannot easily be conveyed or taught. However, by strategically engaging leaders and functional experts, a project manager can quickly gain an appreciation for these dimensions, incorporating them into the overall goals and project approach and team structure. Ensuring the team regularly engages functions with visibility to these issues will make the team more effective while managing risks and issues specifically relevant to the healthcare industry.
Healthcare Provider Environment
The topics discussed throughout this chapter generally apply to healthcare providers, especially to larger hospitals and healthcare systems. However, there is much greater diversity in project management maturity and adoption. For example, one large regional healthcare system recently initiated a project to implement a new supply chain information system (SCIS). Since it did not have a project management office (PMO) or staff of experienced project managers, it assigned a functional team as a resource to serve as the project manager. While this approach resulted in adequate results, it is likely the project may have been able to be executed in less time, at lower cost or better quality with a dedicated PM.
In many cases, healthcare providers may have established PMOs, or established project management departments to support either construction or IT efforts, since these functions often rely on consistent project management methods to deliver their services independent of industry. However, this leaves significant opportunity to improve project execution in business operations and clinical care areas. With a focus on standardizing practices, tools, and deliverables, management can gain better visibility to project performance, thereby driving greater accountability from its teams.
