Project Management

Abstract

Healthcare is changing ever faster and information technology (IT) projects abound. Historically, healthcare IT projects have failed at an alarming rate, generally for three reasons:

• Failure to plan requirements (scope)

• Failure to complete the work (on time) and

• Failure to deliver something that is worthwhile (expectations).

Projects can benefit from project management in order to complete them on time and on budget while meeting stakeholder expectations. Chief medical informatics officers (CMIO), chief nursing informatics officers (CNIO), and clinical informaticists are routinely called upon to lead healthcare projects, such as implementing electronic health record systems, preparing for changes in requirements and regulations or developing analytics projects to improve care. Clinicians often make good project managers since they already have many of the skills that make a good project manager, including the ability to plan and communicate. Without some basic project management training, however, clinicians do not necessarily know how to apply these skills to manage projects. This chapter will discuss tools that project managers use to bring projects in on time, on budget and with the ability to meet stakeholder expectations.

Learning Objectives

• 1. Describe the basic principles of project management.

• 2. Discuss how to determine resource needs for a project.

• 3. Analyze three challenges in project management.

• 4. List the five phases of project management.

Core Content (Competencies)

Project Management

• 4.4.1. Basic principles

• 4.4.2. Identifying resources

• 4.4.3. Resource allocation

• 4.4.4. Project management tools (non-software specific)

• 4.4.5. Informatics project challenges

  • 4.4.5.1. Scope creep

  • 4.4.5.2. Managing expectations

  • 4.4.5.3. Balancing competing priorities

Case Vignette

Good Hope Hospital (GHH) is a 500-bed community facility that implemented an Electronic Health Record (EHR) 4 years ago, complete with computerized prescriber order entry (CPOE), medication reconciliation, interfaced lab results, and full electronic documentation of patient demographics, vital signs, and clinical summaries. The rollout was successful in all areas of the hospital, except the Critical Care Unit (CCU). At the time of the deployment, the 20-bed CCU was overwhelmed with patients and had insufficient staff to handle the project. The department leadership was concerned about a potential negative impact on the patient outcomes, so a decision was made to delay the implementation of electronic documentation in that department. Now that 2 years have passed, the chief executive officer (CEO) of GHH is eager to bring the CCU in line with the rest of the hospital, although staff in that area are hesitant to move forward. The CCU leadership point out that they have been able to deliver superior patient care, despite the lack of CPOE and electronic documentation and medication reconciliation in the EHR, which was plagued with unscheduled downtime during its first year. The CEO counters that patients fall into an electronic “black hole” when they are at their most critical state and the hospital is missing out on funding opportunities through Meaningful Use incentives.

You have been assigned as the project manager to bring the CCU in line with the rest of the hospital’s electronic processes. The major objective, as given by the CEO, is clear: Implement full electronic documentation in the CCU using the existing EHR within 1 year and within a $250,000 budget. After meeting with the CCU leadership, you realize he and their staff are not in full support of the project, although they are willing to give it a try, as long as the following additional requirements can be met:

• 1. Deploy a real-time electronic view that can display clinical data from the EHR system (medications, labs, vitals, and I&O) in the same format as the existing paper flowsheets;

• 2. Integrate the existing medical devices into the EHR system to reduce data transcription errors, including hemodynamic monitors, ventilators, pumps, and hemodialysis devices; and

• 3. Deploy new mobile workstations so device availability will never impair patient care.

You immediately realize that a contract for implementation support will be needed with the off-site EHR vendor, to help supplement the already resource-limited, in-house IT department. Despite the request from the CCU leadership, the CEO remains steadfast with his time and budget expectations. As you would expect, this is not the only project underway at GHH. The CEO is also expecting the hospital to deploy a Barcode Medication Administration solution, a Patient Portal, a Drug Interaction Application, and an upgrade to the EHR within the same year. These projects require many of the same IT and functional resources as your electronic documentation project.

• Given the varied opinions and expectations across GHH, how would you go about conducting a Stakeholder Analysis for this project?

• What skill sets will this project require from your human resources, and what roles would you include on your team?

• What are the most important skills you will need to possess on this project, as the project manager?

• Since the CCU leadership has already added new requirements before the project even starts, how will you manage potential scope creep while still satisfying stakeholder expectations?

• How will you empower your team to perform, given the number of competing priorities?

• How will you manage a team that includes a vendor that will be conducting the majority of their work off-site?

Introduction

Healthcare is changing ever faster and information technology (IT) projects abound. While “failing fast and frugally” may be a good way to achieve innovation, it is not a good way to manage projects [1]. Historically, however, healthcare IT projects have failed at an alarming rate. A project is considered to be a failure when it is late, over budget and/or “has not delivered what was required, in line with expectations” ([2], p. 1). According to a Harvard Business Review study in 2012, over half of all projects fail [3].

Generally, projects fail for three reasons:

• Failure to plan requirements (scope)

• Failure to complete the work (on time) and

• Failure to deliver something that is worthwhile (expectations).

Projects can benefit from project management in order to bring them in on time and on budget while meeting stakeholder expectations. Skills project managers need in order to keep projects on track include the ability to:

• manage change,

• plan,

• communicate,

• analyze risk,

• solve problems, and

• control quality [4].

More and more often, chief medical informatics officers (CMIO), chief nursing informatics officers (CNIO), and informatics clinicians are called upon to lead healthcare projects, such as implementing electronic health records, preparing for meaningful use, or developing analytics projects to improve care. Clinicians and other healthcare providers often make good project managers since they already have many of the skills that make a good project manager, including the ability to plan, communicate, and “generate a spirit of cooperation while coordinating diverse activities” ([5], p. 23). Without some basic project management training, however, clinicians do not necessarily know how to apply these skills to manage projects. This chapter will discuss tools that project managers use to bring projects in on time, on budget and with the ability to meet stakeholder expectations.

Basic Principles of Project Management

The concept of project management has been around for centuries. In fact, there is evidence that the building of ancient structures, like the Giza Pyramid and Greek Parthenon, were among the first efforts that used a tool or process to accomplish a specific goal [6]. Over the years, project management has become more relevant for a larger number of industries, gaining traction as its own discipline by the 1950s [7]. In 1969, a group of project managers founded the Project Management Institute (PMI), which has become the leading association to help define standards, certifications, and practices associated with project management. Several other organizations have also defined standard practices in the area of project management, including the Australian Institute of Project Management (AIPM), the United Kingdom’s Association for Project Management (APM), and the International Project Management Association (IPMA) [8]. For the purposes of this chapter, the majority of the terms, concepts, and descriptions will be based on those that are defined by PMI.

Concepts

To start, project managers need to focus on the most fundamental question: What exactly is a project? In the most basic terms, a project “is a temporary endeavor undertaken to create a unique product, service, or result” in order to meet part of an organization’s strategic plan ([9], p. 3). This is an extremely important point to understand because as the term “project” becomes more and more commonplace, the definition can become somewhat muddied with the basic operations of an organization. Work that is ongoing in nature to help support the mission of an organization is not a project. In referencing the definition of a project, the ongoing work does not create a unique deliverable, nor does it have a defined start and finish (temporary). The major difference between projects and operations is that projects will end “when their objectives have been reached or the project has been terminated” ([10], p. 5). Once this basic difference is understood, project managers can begin to explore what this means for the healthcare industry.

In general, the healthcare industry is growing rapidly, spurred on by new standards of care, technology innovations, and an aging population of patients [11]. In order to keep up with these changes, and ensure timely and efficient implementation of new services and systems, healthcare facilities need to employ good project management principles. Some potential examples of healthcare projects that could benefit from project management may include:

• The implementation of a Barcode Medication Administration tool.

• The implementation of a Provider and Patient Portal.

• The physical move of a healthcare practice from one building to another.

• The implementation of a billing system for third-party reimbursements.

• A hospital center converting from paper records to an Electronic Health Record.

Each of these examples has very different costs, timelines, resources, and levels of complexity, but they all have several common qualities:

• They will create a unique product or service.

• They are temporary and will be considered complete once the objectives are met.

• They will require a specific set of resources, which may include people, technology, or physical assets.

• They have a primary customer.

Given these similarities, any one of these examples could be managed as a project using a defined methodology. There is at least one additional common attribute amongst these efforts; project constraints. Historically, projects were limited by the “triple constraint” of scope (the objectives that will be accomplished during the project), time (the duration of the project work), and cost (the budget of the project) [12] (See Fig. 16.1).

Fig. 16.1

The triple constraint of project management

A project could clearly define two of these items, while the third would be dictated or constrained, based on the defined needs of the other two. For example, the implementation of a Barcode Medication Administration tool could be done faster and with less cost, if the scope of work is reduced. Conversely, the tool could meet multiple stakeholder needs throughout the entire hospital, but the time or cost would need to be increased to meet that need. Over time, project managers have learned that there are other areas of impact beyond just those three, including resources, risk, and quality, effectively increasing the number of constraints from three to six [10]. Due to these multiple layers of impacts and constraints, it becomes more apparent that there needs to be a process in place to help manage the work, and that is where project management becomes a critical component for healthcare projects.

Phases of a Project

The lifespan of a project can be broken down into different phases. These are described by the Project Management Institute (PMI) in five distinct process groups:

• 1. Initiating Process,

• 2. Planning Process,

• 3. Executing Process,

• 4. Monitoring and Controlling Process, and

• 5. Closing Process (See Fig. 16.2).

  Fig. 16.2

  

  Depiction of the five phases of a project

These phases occur in a natural, linear fashion, with the majority of the staff’s workload occurring during the Executing Process. They are referred to as process groups because they are each contain a series of processes. In fact, the Project Management Institute (PMI) recognizes 47 distinct processes across these groups, which are further categorized into 10 knowledge areas with over 100 unique inputs, outputs, and tools and techniques [9]. For the purposes of this chapter, the concentration will be on the five basic process groups.

The first process group is Initiating. The primary function of this process is to evaluate the proposed project against business need and technical feasibility, and provide sufficient justification for a decision on the project’s approval [13]. Generally, the details that are captured during this evaluation process are presented in a project document called the Project Charter. The components of a project charter vary widely across industries and organizations, although at a minimum, they usually include the name of the project and project manager, a description of the unique product or service, a justification as to why it is being done, and milestones, risks, and expected cost and timeline (See Fig. 16.3). A project sponsor, who will serve as the champion of the project, may also be identified at this point and a link between the project manager and the business unit or department and decision-making bodies (e.g., Board, C-Suite). Regardless of the components, an approved project charter signifies the authorization of the project and the project manager. More details about the project charter are included later in the chapter.

Fig. 16.3

Example of a project charter highlighting its main elements

Once the project has been approved, planning can begin. The project manager will use the project charter to begin to define a project management plan. Planning represents a significant amount of time and work effort during this phase on the part of the project manager, as many aspects of the project are defined and planned, including the integration, scope, schedule, cost, quality, human and non-human resources, communications, risk, procurements, and stakeholders [10]. Several of these areas are described in more detail later in this chapter. Together, these components help outline the project management plan, as well as the knowledge areas described by the PMI. Once the project plan is finalized and approved, it can be helpful to create a formal project baseline. A baseline serves as a reference point for the project to help stabilize the project during monitoring and controlling. The baseline can also help the project manager to understand any gaps between what was planned and what was actually completed at the end of the project. In any case, there should be no changes to the baselined project plans without following a change control process, as defined by the project manager or the organization’s project management office (PMO). Change control and scope creep will also be discussed later in this chapter.

After planning is complete, the Executing process group starts. The responsibility of the project manager during this phase will vary, depending on the complexity of the project and the organization’s practices [13]. It is during this time, however, that the majority of work will be conducted to complete the planned objectives and project deliverables. During execution, the project manager will need to ensure that all processes are followed, the schedule, scope, and cost are managed, and risks, issues, and decisions are documented, reviewed, and communicated. This is often referred to as Monitoring and Controlling phase which runs in parallel to the Executing Process. Both sets of processes are considered complete once the objectives of the project have been met.

After the product or service has been successfully delivered, the project manager needs to archive the work and step away from the project in a process known as Closing. The project manager will review all deliverables against the project plan and charter to ensure they have been completed. Outstanding issues or action items will be documented and assigned to an individual or group for ongoing follow-up so all project activities can be closed. The project manager will also conduct a lessons learned process to highlight areas of the project that went well or could be improved in the future, so later similar efforts can perform even better. These lessons could be incorporated into a completion or closure document, which can be accepted by the project sponsor or other decision-making body. Upon acceptance, the project manager can release or close all project resources, including human, non-human, and contracts. The product or service should have been transitioned to an ongoing support team, as well, because upon closure of the project, the project manager’s responsibilities for this effort are complete, and the project manager will no longer serve as the point of contact for the product or service.

Project Management Tools

As with any other role, project managers need tools to successfully manage projects. These tools focus the project manager, the team and stakeholders on the project outcomes throughout the project in order to complete the project on time and within budget. These tools identify and manage information in order to address why this project needs to be done (business case), what needs to be done (project charter), which stakeholders need to be involved in the project (stakeholder analysis), when the project will be done (WBS or timeline), how information about the project will be communicated (communication plan) and how issues and risks will be managed (risk management plan). These are key tools that should be included in every project, no matter how big or small. For large projects involving multiple departments or areas, these tools need to include extensive detail around the project and the stakeholders. In smaller projects, the tools can be tailored and used as guidelines to move the project forward.

There are also a number of charts and graphics that can assist with the project especially during the planning phase. An Ishikawa or fishbone diagram is a graphic tool used to explore and display opinions about sources of variation in a process. This is a good way for the project manager to include the team and stakeholders in the project planning. The concept is that the main problem is entered at the right of the diagram, and the “bones” represent the main categories that affect the main problem. The idea is to have three to six main categories that encompass all influences. This technique is best accomplished by a group where brainstorming adds all possible causes to the “bone”. When complete the team usually has a good idea of the root cause for the problem (see Fig. 16.4). A mind map is another planning tool that supports team brainstorming activities (See Fig. 16.5).

Fig. 16.4

Example of a fishbone diagram used to identify sources of variation in a process

Fig. 16.5

Example of a mind map planning tool

A Program Evaluation Review Technique (PERT) chart is a project management tool used to schedule, organize, and coordinate tasks within a project. PERT is a methodology originally developed by the U.S. Navy in the 1950s to manage the Polaris submarine missile program. A similar methodology Critical Path Method (CPM) was developed about the same time for private sector project management. The PERT chart is sometimes preferred over the Gantt chart, another popular project management charting method, because it clearly illustrates task dependencies. On the other hand, the PERT chart can be much more difficult to interpret, especially on complex projects. Frequently, project managers use both techniques.

A Gantt chart is a horizontal bar chart developed as a production control tool in 1917 by Henry L. Gantt, an American engineer and social scientist. Frequently used in project management, a Gantt chart provides a graphical illustration of a schedule that helps to plan, coordinate, and track specific tasks in a project. Gantt charts may be simple versions created with a spreadsheet or more complex created using project management applications (See Fig. 16.6). Additional information on PERT and Gantt charts as it relates to finding a project’s critical path can be found in the “work breakdown structure (WBS)” section of this chapter.

Fig. 16.6

Gantt chart example created using a spreadsheet program

Business Case

In order to get a project funded, many facilities require a business case. According to Dawes, et al., a business case includes a “plain language statement of the problem to be solved, with key data to illustrate its significance, as well as its severity and complexity” ([14], p. 34). A business case should also identify stakeholders and how they will be affected if the project is done or not done. It states assumptions, estimated costs and resources. In addition, the business case includes options by comparing the current state and the potential future state if the project is completed. With limited funds, many projects compete against each other, and decision making committees need to understand the value of a project in order to approve funding and resources. A business case will help to present the value of the project to the funding committee. A well-written business case can increase a project’s chance of approval.

Business cases should be written in terms the stakeholder and approving authority will understand and support. Starting with a problem statement that shows the potential positive impact sets the tone for the business case. The problem statement should be tied to the strategic plan of the facility and show how the proposed project can support that plan. Problem statements should include quantification where possible such as ‘reduce errors by 5 %’ or ‘increase compliance by 10 %’. For example, data should then be presented to support the potential positive outcome including information that demonstrates what will occur if no change is made. General information about the potential costs – both the financial and resource costs – should then be described.

Once the potential project is described along with the estimated costs, the business case should include a timeline with major milestones. Decision makers need to understand how long it will take to achieve the potential results and how this project can fit into the other projects scheduled for that reporting period. The timeline can be high level and just include major phases such as planning, implementation, training if applicable, and the projected go live period.

Including an executive summary as part of the business case will also help the decision makers focus on what’s important. Key elements of the business case that should be included in the executive summary include the problem statement, scope of the proposed project, and both the business and financial impact of the project.

Project Charter

Once a project is approved, a project charter “formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities” ([9], p. 68). The charter documents the project and is a method to obtain sign-off and agreement from the stakeholders. Lowenhaupt & Friedman further described the purpose of the project charter to do the following:

• “Document agreement between client organization, team sponsor, project team, team leader, and project manager.

• Provide a clear statement of purpose of the implementation project and what the team is committed to deliver.

• Define the project roles and responsibilities.

• Provide the baseline for scope and expectation management” ([15]: p. 137).

The charter is a way to get all the stakeholders on the project to agree on the overall project and the methodology that will be used to complete the project. Charters should be succinct statements of the plan, the resources and their roles, the milestones and how the project will be managed. The content of the charter should include all the following:

• Project description, purpose and goals: This section should include a paragraph or two describing what the project expected to accomplish. In addition to the project purpose, a list of specific goals or outcomes should be included.

• Project scope: This section describes what is and is not part of the project. In addition, all the departments or units that are included or excluded from the project’s scope should be listed.

• Project assumptions: Assumptions guide decisions throughout the project. Including the expectations that guide the project effort help to standardize the decision making processes throughout the process. Assumptions can include resource duration, prerequisites, software functionality, building codes, and other constructs for the project plan.

• Project approach: This section includes a description of how the project will be implemented and the high level milestones, such as planning, analysis, build, testing, training, and go-live activities. In addition, the approach should describe how risks and costs will be managed.

• Project reporting structure: A reporting structure is important in any project. Since many of the team members of most projects do not directly report to the project manager, describing the hierarchy of responsibility and project organization structure is necessary. Including a description of who is part of the project including teams, stakeholders, leaders, and third-party vendors is also part of this section.

The charter drives the project and is used for the duration of the project to guide team members and stakeholders. It is a living document to be updated throughout the project as teams change or as the project changes. Stakeholders should sign-off on the initial charter at the beginning of the project. Any future changes should follow a change management process with approval and documentation.

Stakeholder Analysis

A project stakeholder is anyone who is impacted by the project, including those involved in the actual project work such as the project team. Stakeholders can have influence on the project deliverables or outcomes. PMI defines a project stakeholder as “an individual, group, or organization who may affect, be affected by, or perceive itself to be affected by the decision, activity, or outcome of a project” ([9], p. 30). Identifying stakeholders should occur as early as possible. A ‘savvy project manager’ should evaluate the political climate surrounding the project ([16], p. 74). There are several documents that can assist with this task. Lessons learned from similar projects and the business case can provide some good information regarding who was or will be impacted as well as their interest in the current project. Anyone the project manager, or project team, will need support or assistance from should be added to the list. Once a project sponsor is identified, they can assist with the identification. Project team members, the decision making committee and even vendors can assist with the identification of possible stakeholders. Depending on the project, potential stakeholders include:

• Organizational Leadership,

• Project Sponsor,

• End Users,

• Vendors,

• Project Manager,

• Project Team Members,

• Resource Managers,

• Marketing/Sales,

• Quality Assurance/Quality Control,

• Legal,

• Finance or Funding Source,

• Contracting Office,

• Patients,

• Visitors/Customers,

• Business Partners,

• Government Regulators,

• Consultants,

• Payors, and

• Providers.

Once stakeholders are identified, understanding everyone’s stake in the project includes identifying who stands to gain or lose if the project is success or unsuccessful [16].

This can be completed through a Stakeholder Analysis which begins once the initial stakeholders are identified and then is repeated for all new stakeholders. This analysis evaluates each stakeholder’s expectations, needs, perspective and objectives for the project. The outcome of the analysis should be reviewed often as the results will change over time as their views, their priorities or the project changes. There are various tools available to use for this analysis and they are all very similar. One tool looks at key information regarding each stakeholder, using a table where each stakeholder or group of stakeholders are on each row. The analysis concepts are in each column (See Table 16.1).

Table 16.1 Stakeholder analysis

Different organizations look at different concepts for the analysis, but the intent is the same, understanding each stakeholder to help define how to manage their expectations. Stakeholder Analysis concepts include:

• Stakeholder – the stakeholder role or name, such as project team or end users.

• Involvement – the stakeholder’s level of involvement in the project: Will they be active participants providing requirements, testing, or will they be inactive but impacted by the deliverables?

• Interest – the stakeholder’s level of interest in the project: Are they looking forward to the project and deliverables, or not happy with the impending change?

• Influence – the stakeholder’s level of influence within the organization or the project.

• Power – the stakeholder’s authority within the organization or within the project.

• Impact – the impact of the project or deliverables on the stakeholder or their department.

• Expectations – the stakeholder’s expectations for the project, project manager, deliverables, and other outcomes.

• Communication – the stakeholder’s expectation for communication, including form, frequency, and method.

• Support – the type of support the stakeholder can or will provide to the project and project team.

• Role – whether the stakeholder has a defined role on the project beyond stakeholder.

Once this analysis is complete, the project manager can determine the best method of managing each stakeholder, or group of stakeholders. Additional columns could be added to the above spreadsheet to define the method of communication and method of managing expectations. Another option is to use a tool with two rows and two columns to plot each stakeholder based on comparison criteria (see Fig. 16.7). There are variations on this tool as well and it would depend on what two criteria are important to evaluate or you could utilize multiple versions to provide differing viewpoints. The main criteria used for this tool include influence/ power and importance/ interest. Any stakeholders who are high for both criteria are key people and should be actively involved in the project. Stakeholders who are high for only one criterion should be closely managed to meet the specific needs. For example a stakeholder who has a high interest, but a low influence should be kept informed of the project progress. The ones who are low for both criteria should be monitored, but should take the least amount of effort from the project manager.

Fig. 16.7

Example of a 2 × 2 table for performing stakeholder analysis

The project manager can find themselves caught in the middle between multiple stakeholders as it is rare that all will have the same perception, goals or expectations in the project. Differing views can come from internal factors such as organizational leadership or clinicians, or from external factors such as, government regulations, the vendor or third party consultants. The stakeholder analysis can provide assistance with who may have the power or influence to assist when the disagreements go beyond what the project manager can negotiate. The project manager represents the organization when managing conflicting expectations from external sources. While vendors or consultants come in with much experience with implementing the specific project, the project manager and team, know the culture of the organization. In addition, the project sponsor is a great resource when issues need to be escalated as they represent the organization for the project.

Once the stakeholder analysis is complete, regular review is needed throughout the project since opinions change over time, especially if there are requests to change the scope. This task is typically completed by the project manager although anyone can provide input or assistance. An ongoing effort should be exerted to building and maintaining relationships with stakeholders.

Work Breakdown Structure (WBS)

PMI defines the Work Breakdown Structure (WBS) as “the process of subdividing project deliverables and project work into smaller, more manageable components” ([9], p. 63). PMI further explains, the WBS is a “hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables” ([9], p. 63). The purpose of the WBS is to create a structure for the work that will be delivered; that is to identify what must be done. Lewis considers the WBS the most valuable tool a project manager has because it ties the whole project together [17]. Even a small, short project can benefit from a WBS since the WBS:

• defines all the work to be done,

• creates a graphical representation of the scope and magnitude of the work,

• provides the basis for the resource assignments,

• allows the project manager to estimate the time for each task, and

• helps the project manager to calculate resource costs for the project [17].

By using a WBS, the project manager can organize tasks that will complete all the work required by the project’s scope. The first step in creating a WBS is to identify the major tasks needed to complete the scope. For example, these tasks could include major activities such as “analyze existing data”, “create reports”, “test reports”, “go live with new reports”, etc. The purpose of this first step is only to identify the steps, not to organize them. By identifying all the steps first, the project manager can better organize and create a schedule that includes all the steps.

Once the first step is completed, then the project manager begins breaking the major tasks down into further details. For example, the step of “creating reports” may be further detailed into sub tasks such as “complete report requests”, “develop template”, “create development database”, etc. Including team members or other subject matter experts (SMEs) in this step can be very useful as they often bring a different view of the work. The project manager continues to further define all the major tasks until all the subtasks are identified.

Once all the tasks and subtasks are identified, the WBS is complete. Next, the project manager assigns resources to each task and subtask and identifies how long each subtask will take. These are almost always estimates and can be based on previous projects. Often, at this phase, resources are not yet assigned to the project. Instead, the project manager may need to identify the resources needed based on the tasks and duration. Most IT projects will need similar resources, including at a minimum, a champion or sponsor, an analyst, a builder, someone to coordinate testing, to coordinate training, and resources from the unit or department impacted. For smaller projects, some of these tasks may be done by the same person; in larger projects more people are needed. The project manager should identify resources based on the tasks and durations, as well as the skills needed, rather than specific individuals. For some projects, the team is identified in advance of the project based on how previous projects were staffed. There is no formula to identify the right number of resources; teams should stay as small as the work allows to keep the project costs down. In addition, there are times when adding more resources does not get the work done any faster or more efficiently, but instead can add more complexity to a project.

Once identified, team members can help identify how long a task would have taken them in similar projects and them the project manager can then add or subtract time as needed for the current project. The next step is to identify how to determine when the task is complete. This includes identifying any deliverables or outputs for each task. Not all tasks will have an output; some tasks are just an activity to complete in order to do other tasks. For example, status meetings should be tasks in the project plan in order to account for the time spent on the tasks, but do not have any specific deliverables as a result of the activity. The project plan should not be a to-do list of every activity needed, nor should tasks last much more than 2 weeks in duration. The level and number of tasks is guided by the project manager’s style and the degree of control needed to effectively manage the project.

Once tasks with resources and duration are listed, the project manager needs to identify any predecessors and/ or links between tasks. For example, usually software needs to be loaded before specific project or site modifications can be made. This would make loading the software task a predecessor of the modify software task. Some tasks can be done simultaneously, that is, they are not dependent on each other to be completed. For example, training preparation tasks can be worked during the same time as testing tasks.

When tasks with known durations are aligned in a project plan with specific predecessors, it is possible to determine the shortest possible duration of the entire project. To find this duration, the project manager can review each series of sequential tasks and find the series with the longest overall duration, which is also known as the critical path. In the example PERT chart (See Fig. 16.8), the project has a total of 6 tasks (A, B, C, D, E, and F). Each task has a fixed duration, but it’s possible for some tasks to occur concurrently. For example, Tasks A, B, and C can start at the same time. However, other tasks cannot start until others finish, as indicated by the arrows. In the path A-D-F, Task D cannot be started until Task A is complete, and Task F cannot be started until Task D is complete. By counting up the total duration of these tasks (1 + 2 + 4), the project manager can determine that this particular series of tasks will take 7 days to complete. However, there are other paths through the project, including B-E and C-E. By adding up those paths, the project manager finds that B-E will take 9 days (7 + 2), and C-E will take 7 days (5 + 2). The critical path for the project is the longest of these series, or the B-E path. If either Task B or Task E take longer than expected, the entire duration of the project will be extended. Conversely, tasks that are not on the critical path may have more flexibility. For example, if Task A takes 2 days to complete, it will have no impact on the overall duration of the project because Task F will still finish a day before Task E. If, however, Task A takes 5 days to complete, the critical path shifts to the A-D-F series (5 + 2 + 4 = 11 days).

Fig. 16.8

Example of a PERT chart used to determine the critical path, which determines the shortest possible duration for a given project

Another way to demonstrate these linked tasks is by developing a Gantt chart. A Gantt chart displays the same information as the PERT chart, but in a more linear fashion, aligned against a timeline (see Fig. 16.9). In this view, it can be much easier to find tasks occurring concurrently on a day-to-day basis. The Gantt chart also shows the predecessor/successor relationship between each of the tasks. Gantt charts can be quickly created, viewed, and analyzed via various types of project management software.

Fig. 16.9

Example of a Gantt chart highlighting dependencies and the critical path

Project management software can help to add and manage these types of links. At the most basic level, project management products will help manage projects from start to finish, help keep costs down, especially in large, complex project and allow employees at different levels to have an input into the process. Project management applications can also help with task scheduling, cost control and budget management, resource allocation, collaboration, communication, quality management and documentation or administration. Once all the tasks and resources are added to the project plan, the project should be baselined. Baselining a project creates a view of the project before the work starts so that it can be compared throughout the project and help determine where any issues may occur.

Many project managers view the project plan as the most difficult part of project management. Although some of the tools available are complicated, a simple timeline with activities, due dates, and person responsible may be sufficient to run many projects. Using software specifically developed for managing projects, however, can help manage tasks that are linked together, generate reports and identify the critical path of a project. A critical path is the longest path or set of tasks through the project. This path or set of tasks drive the project duration; that is, the project cannot be completed any sooner than the last task in the critical path. Understanding and carefully tracking the tasks in the critical path will increase the likelihood of an on time project. Project management software can also help to adjust a project plan if needed due to delays or changes in scope. Tasks can be linked to start one after another or at the same time when using predecessors and links. By linking tasks together, the project manager can more easily see how a change to one task can impact others. For example, if testing is a predecessor to training users, and a delay occurs with testing, there also needs to be a delay in training tasks.

Project Management Office

To help navigate a project through all the process groups, a project manager may rely on the standards set forth from their organization’s Project Management Office. According to PMI, “a project management office (PMO) is a management structure that standardizes the project-related governance processes and facilitates the sharing of resources, methodologies, tools and techniques” ([9], p. 9). While PMOs have been around for a while in other industries, they are still fairly new in healthcare. In addition, to creating a standard methodology, the PMO mission and objectives usually includes consulting, mentoring, and training project team members and organizational leadership [18]. Having experienced project managers who follow standard processes and use consistent tools to set expectations on how a project will be managed serves the ongoing success of organization. The focus of a PMO is to have “centralized and coordinated management of an organization’s projects, programs or a combination of both” ([19], p. 11).

Utilizing standard tools within the PMO helps to monitor work across all projects. For example, using a standard tool such as Microsoft Project Enterprise (Redmond, WA, USA) or Solution Q Project Portfolio Management (Toronto, ON, Canada) to define the project work and required resources could allow the project manager to understand the resource availability. Evaluating the demand for resources against their capacity for projects helps with planning individual projects and identifying resource related risks across the portfolio of projects. This is also beneficial when reviewing and scheduling new project requests while ensuring the right resources are available. Standard project portfolio tools provide the ability to review all project requests along with ongoing projects and their associated details. This allows for the ability to look at the inter-project dependencies and risks as well as providing early clues to potential issues that may cause delays in other projects.

In healthcare organizations, there are a variety of options for the reporting structure of the PMO. Since many of the activities identified as projects are related to IT, the PMO often reports to the CIO and focuses on IT projects. In other organizations, the PMO reports to clinical or business leadership or the CEO. In larger organizations, there may be an overarching PMO at the corporate level with project managers or remote PMOs at the local level. The location of the PMO does not impact the value it provides to the organization as long as standards are created and followed.

Communication Plan

Once the project planning (project charter, WBS, etc.) is complete, the project manager will spend most of their time during the project communicating with the team and the stakeholders. The main purpose of communication is to get the right information to the right people at the right time and in a useful format. In many ways communication is selling and reselling the project throughout its duration. The project manager needs to determine who needs what information in order to continue to support the project and complete the required tasks. Good communication can increase the chances of project success, whereas limited or bad communication can lead to project failure. The basic assumption in any communication plan should start with ‘no surprises’. Communication should flow from the team to the project manager, from the project manager to the team and from the project manager to the sponsor or committee overseeing the work and the stakeholders. Team members should provide the project manager with detailed status which the project manager can then roll-up into status for the stakeholders. The project sponsor and stakeholders do not need every detail about the project; rather they need to know about issues and risks that will impact the timeline, scope, resources or deliverables.

The duration of the project often drives the frequency of communication, but no matter the duration, communication should be regular and scheduled. For example, during long projects (more than 6 months) it may be enough to report status monthly. For shorter projects and during major milestone events or issues in larger projects, weekly or even daily status may be needed. For example, during the training phase of a project, daily reports on the number of users trained can help to focus leadership on getting all the users to a scheduled training class prior to the end of the phase. Basic status reports include information about:

• What was accomplished since the last reporting period?

• What are the planned activities by the next reporting period?

• Are there any priority issues and risks that need to be escalated?

Stakeholder status reports should include more information about the project’s well-being. For formal communication with stakeholders, using a dashboard style report is often very well received by stakeholders to enhance the details. Dashboards can include the following:

• Project progress toward milestone completion (% complete)

• Overall status (using red-yellow-green highlights)

• Key issues

• Key risks with any available mitigation plans

• Upcoming milestones

Keeping the team and stakeholders up to date on the project timeline, risks and likelihood of successful completion will assist the project manager to complete the project as planned.

Risk Management Plan

Assessing risk is another key task that the project manager needs to focus on throughout the project. Most of the team members and stakeholders are focused on the ‘now’ during the project; that is, the tasks that are currently in progress. The project manager, however, needs to also focus on the next planned tasks or milestones to determine the probability of those occurring as planned. PMI defines risk as “project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives such as scope, schedule, cost, and quality ([9], p. 314). Lewis further describes a risk as “something that can happen” ([17], p. 197). Issues, on the other hand, are something that has happened and need to be managed.

Once identified, risks can be mitigated, avoided or transferred to another party. Risks can be prevented if identified and managed early enough in the project. Risks should be assessed throughout the project, but two key times to focus on risks is while the business case and project management plan for the project is created and key milestones during the implementation of the project. When creating the business case, risks can be identified based on the maturity of the proposed solution. New software, for example, is more risky than using established software. This is also true with inexperienced staff or the use of new contractors. Identifying these risks during the business case can help to reduce the likelihood of their occurrence or avoid their negative impact to the project. For example, if new software is being developed as part of the project, extending the expected timeline and adding additional tasks to test the software may mitigate the risks.

During the implementation phase of the project, reviewing the progress of the project and issues can help the project manager identify risks and potentially avoid them. Questions the project should ask to identify risks include:

• What could go wrong?

• What kinds of threats exist?

• What other competing initiatives may impact this project?

Once risks are identified, they should be assigned a probability and severity ranking. This will help to prioritize a strategy to prevent the risk from occurring. Probability ranking is a simple assessment of the likelihood of the risk from becoming an issue, from not likely to very likely. Creating a numeric probably ranking from 1 to 5, with 5 being the most likely will help to rank the risks. Risk severity takes into account the impact to the project if the risk were to occur. Again, a 1–5 risk severity scale can be used with 5 describing a risk that could have a major impact to the project schedule, costs, and/or deliverables. Adding together each risk’s probably and severity score will help to determine which risks have the potential to most adversely impact the project (See Table 16.2). Risks with high scores (i.e. 7, 8, 9 or 10) should have a detailed mitigation plan reviewed and approved by the stakeholders. In addition, these risks should be included in status reports and dashboards so the decision makers are aware of them throughout the project.

Table 16.2 Risk assessment

Resource Allocation

Human resources are often the most costly and difficult to manage on a project. Project staff and stakeholders usually come from various departments, business (or clinical) units, or companies and need to quickly come together as a team. In addition, stakeholders to whom the team members report have competing priorities that may impact the ability of the team member to fully commit to the project tasks and timeline. Estimating the time it takes to complete complex tasks on a project is often dependent on the skill of the team member, their understanding of the complexity of tasks that are assigned to them and their knowledge of and belief in the project outcomes. During the business case process, it is necessary to identify resource skills and estimates of the number and type of resources needed. Assumptions are made about the availability and skill set of each team member expected on the team prior to the project approval. These assumptions are often carried into the project and can impact project success as estimates become reality. Task completion estimates are often done by skilled individuals or subject matter experts, but the tasks may not be completed by these same experts. This may cause durations to be underestimated and may adversely impact the project.

Project managers must manage and skillfully allocate resources to successfully complete the project as planned. Often this takes some knowledge of the team members’ skills and work style, as well as the culture of the organization. From a project perspective, team members are expected to complete tasks on time and with excellent quality. It is possible, however, that other important activities may take precedence over the project’s tasks, especially if the team member does not directly report to the project manager. In addition, team members may not fully understand the urgency of the tasks they have been assigned and may allow them to get behind unless correctly managed.

Projects are made up of people doing tasks. In order to successfully complete the project, however, individuals must become a team with a common goal; that is, success of the project including completing tasks on time and budget while meeting agreed upon expectations. Katzenbach & Smith investigated what made some teams high performing and discovered that teams are not just groups working together, but are groups with individual and mutual accountability and discipline [20]. The most significant step to achieve this mutual accountability and discipline in a project is a common purpose that the team has helped to shape [20]. This common purpose should be the project goal, which in turn should be tied to the organization’s strategic objective. The team members need to understand how their activities on the project will help to meet or not meet that goal. Having team members articulate their role in the project goal can help with their commitment. For example, a report writer that does not participate in patient care may not see him or herself as being able to directly impact a goal of reducing medication errors on a project. Reminding team members of their contribution to the overall project goal throughout the project and looking at issues and successes based on how their individual successes or failures impact the project will guide their behavior within the project.

Identifying Human Resources

Often, projects are planned with specific individuals in mind. These individuals are, however, often are not fully available to the project at the time the project needs them due to the nature of projects. Instead of identifying individuals during the planning process, the project manager should instead identify the skills required to successfully complete the project. Perhaps multiple people have those skills or can partially contribute to the project. In addition, since most projects are made up of temporary teams, team members need to be able to work together, so work style is also important to assess. For a project creating reports to reduce medication errors, analytical skills and the ability to mine data are needed. For a project to improve physician adoption of a new order set, some medical experience and informal authority may be needed in addition to technical build abilities. Teams rarely have all the required skills at the onset, but can learn them through the project with as they determine exactly what is needed.

As the project progresses and more work is identified or work is behind, many project managers will add additional team members in order to meet the planned deadlines. A principle called Brook’s Law states that ‘adding people to an already late project may only make it later” so careful consideration of the impact to adding new people to a project needs to be assessed ([17], p. 20). There are times when two people can get twice as much work done at the same time and others when they will just get in each other’s way. The project manager needs to assess this prior to adding additional resources to the project. Often, team members who are assigned to the project for a specific amount of time are not actually working on the project for the expected time. This may be due to competing activities, time off, and/ or other duties as assigned. Project management tools such as Microsoft Project (Redmond, WA, USA) help to define the amount of time an individual is working on a task (i.e. full time, 20 %, etc.), but this is often not used during estimating and not always used to its fullest during a project. A simple way to estimate is to assume that a full time resource will only dedicate 30–35 h to a project rather 40 h as they will have other tasks they are responsible for. In addition, identifying holidays and time off at the beginning of a project can also help to correctly estimate resource time commitment to a project.

Identifying Non-human Resources

In addition to human resources, project resources include inputs to the project like software, construction or machinery. Estimates and assumptions on the availability of these non-human resources is also part of the project manager’s task before and during a project. Teams may need workspace or tools to support virtual team activities. Often resources need access to new software, issues management tools or collaboration tools such as Microsoft SharePoint (Redmond, WA, USA). During the business case and planning phase these additional resource needs should be identified.

Some standard questions can help the project manager identify non-human resources. These questions include, but are not limited to:

• Where will the team work?

• How will the team share documents and knowledge objects?

• Is the software available or does it need to be purchased or developed?

• If additional software is needed, what hardware is required to support it?

• If a new application is being implemented, do end-users require additional tools (i.e. laptops, tablets, etc.) to access it?

• Is there sufficient storage, bandwidth or power available for the project deliverables or application?

• Is construction needed to accommodate new technology or staff?

• Are any services needed to support the project (i.e. computer assisted training development, technical writers, contractors, etc.)?

Not all of this information may be known during the business case planning, but adding time and tasks to identify the details and estimates on costs is necessary. Specific details can be added during the planning phase.

Identifying Financial Impacts

Once task duration and the resources needed on a project have been identified, the project manager can create the project budget. Starting at the lowest level of the WBS or project plan and estimating the costs for each category including personnel, equipment, software, travel, training, supplies, space, construction, etc. and working through each level of tasks until all the tasks are estimated, will create the most complete budget possible. Many facilities add a contingency to project budgets to plan for changes in scope, projects that span multiple fiscal years and other unplanned costs. This contingency can be 5–20 % of the total estimated costs, for example, although few healthcare projects allow for high contingencies.

Budgets, however, are still just estimates of the costs and will need to be managed throughout the project duration. Labor costs, also known as the budgeted cost of work or planned value, are often the most difficult to manage and can take a project beyond budget quickly [17]. In addition to tracking task and milestone completion, the project manager will also need to track resource hours and time reported to the project. Many healthcare project managers need to track both employees (owned resources) and contractor hours, but are rarely responsible for the actual contracting. In addition, owned resources don’t always report time per project. In order to manage a project budget, however, owned resources should be expected to report hours work on the project to the project manager with every status report. Contractors usually report their billable hours monthly and the project manager needs to review their budgeted hours against their reported hours and expected milestones. Reporting on the project budget should include comparing planned value (budgeted hours) against actual cost of work performed along with any non-human resource costs. Any actual or expected overages should be included in the project managers status report to the sponsor and stakeholders. Any additions to the budget, human or non-human resources or durations, should follow the standard change management process and approval.

Informatics Project Challenges

Even the best project manager with the most comprehensive project management plan and in the most efficient organization with the highest-caliber employees will run into issues on a project. Issues and risks are bound to happen on any size project, and a project manager should be prepared to meet these challenges head-on to be successful. This section will describe several areas to be monitored at the project level, organization level, and external to the project and organization.

Issues, Risks and Resources

At the project level, issues are more prevalent, but fortunately, are usually better anticipated and certainly more under the project manager’s control. One particular area of concern is based on the project work activities, and the information gathered during project initiating and planning. The majority of project managers acknowledge that unclear requirements are a top challenge for their projects [21]. Oftentimes, it can be difficult for a stakeholder to adequately describe what they really need, sight-unseen, and it can take a specialized skill set to be able to elicit clear requirements. To help mitigate this challenge, assumptions, constraints, and risks should be clearly documented and communicated to the team and stakeholder. The entire team should provide input to these areas to ensure a comprehensive analysis of requirements. Even with clear requirements, it’s possible that critical requirements are still missed. Since every requirement takes time, effort, and money to complete, it’s important to stress to stakeholders that if something is not documented, it’s not going to be done. Completing work that was not part of an approved plan not only may add unnecessary time and cost to a project, but it may also introduce legal and contractual violations, as well.

If requirements are clear and complete, other challenges around work effort may still cause problems, such as incorrect and insufficient work assignments, or poor cost and schedule estimations. Obtaining the correct human resources on a project is crucial to success. After all, these are the people that will be performing the majority of the work against the project scope and requirements. Just as with any organization, however, challenges with individuals can cause problems on projects. This may include personality conflicts between team members, health issues, and general morale and motivation to get the job done. A good project manager should monitor resources for issues in these areas and take appropriate action, which may include escalation to the individual’s supervisor or removal from the project team. Additionally, it’s important for team members to have the right skills to accomplish their work. IT projects often involve the implementation of new software and hardware that may be unfamiliar to project staff. Thus, the project manager should review skill sets during project planning and determine if training or subcontracting is necessary. If a project requires support from external resources (human or non-human) via a contract, this could introduce other challenges around procurement, communication, and legal matters. The project manager must stay engaged with the team to ensure they are staying on schedule with their tasks and action items and remain on contract.

Organization Attributes

When analyzing potential risks and issues beyond the project itself, a project manager should be cognizant of organizational attributes that could impact the project. The growth in the healthcare industry has generated a large number of supporting IT systems for every aspect of patient care and research. There is a need to ensure that disparate systems are integrated or interfaced with each other, which introduces a new level of dependency between applications, and thereby, projects. A seemingly simple change or upgrade to a single system may impact several others, and a project manager needs to consider those dependencies when planning a project. If an organization is fortunate enough to have a PMO, that group can assist with documenting dependencies between systems. Otherwise, the project manager will need to collaborate with other managers and system owners to define dependencies [21].

Other organizational attributes that could impact a project include lack of support from upper management, conflicting business objectives and agendas, quality of available non-human resources, poor stakeholder management, and an insufficient infrastructure or working conditions. In competitive industries, the challenge to get a product to market is even more intense. If deadlines are not met, there is a risk that stakeholders will look elsewhere for products and services or skip needed projects because they do not get the job done [13].

External Factors

If a project manager is able to successfully navigate the challenges within the project and organization, there are still external factors to consider. These usually have less predictability and control, such as natural disasters or power outages, but ensuring that backups and alternate plans are available is still the responsibility of the project manager. Other areas to consider include local, state, and federal constraints. Healthcare IT solutions are often governed by legal and regulatory constraints, which may specify certain types of permits or registrations that are required to operate a given product. Or, the product itself may be subject to policies, such as IT accessibility, as defined by Section 508 of the Rehabilitation Act (29 U.S.C. 794d). Since the number of challenges an informatics project may face are countless, project managers must be prepared to handle any given situation and any given time by using standard methodology, status reports and change control processes.

Healthcare project management is also challenging because project managers are not only managing projects within their facility’s policies, business processes and culture, but also within the larger, quickly changing healthcare landscape subject to federal and state regulations. Government regulations such as the Health Information Technology for Economic and Clinical Health (HITECH) Act enacted as part of the American Recovery and Reinvestment Act of 2009, Centers for Medicare & Medicaid Services (CMS) regulations, and even the Affordable Care Act impact healthcare projects. Software vendors are responsible for keeping their software up-to-date with any government requirements, and so their priorities are also driven by these regulations. Project managers need to understand these and other regulations to help both prioritize and manage projects. Refer to Chap. 3 for additional discussion about these policies.

Scope Creep

One challenge that seems to present itself on any given project is the concept of scope creep. Scope creep is a term that is generally given to increasing amounts of work that was not in an original plan. However, more specifically, scope creep is the unauthorized addition of tasks, objectives, or requirements to a project plan. Scope creep should never occur and is “directly related to requirements and their mismanagement” ([22], p. 82). Once the project management plan is finalized, it is never acceptable for a project manager to allow work to be done against the project that was not defined to be done. Oftentimes, scope creep has its roots in small tweaks and changes to requirements, requested by the stakeholder, either because they were unclear or missing at the start. To satisfy the needs of the stakeholder, the project manager may consider allowing the work to proceed as a good gesture. However, these requests may grow in number and complexity, and by the time a project manager tries to stop the flow of unauthorized changes, it may be too late, and the stakeholder may just expect the work to continue to be added, not understanding the impact to the project plan of even small changes. Therefore, it is critical to establish good change control processes at the start of the project. It does not mean a change to scope or requirements cannot proceed; it simply means it must be evaluated and approved first. A good change control process must be in place and communicated at the start of every project. Change control involves “developing and maintaining processes that define each step required to perform an activity correctly and efficiently” before it is done ([13], p. 243). The primary purpose of this change control is to:

• gather data,

• define the need for the change,

• identify all impacted resources, timelines, systems, and other projects,

• propose the change to stakeholders, and

• ensure validation and authorization.

These items should be documented in a change request form and presented to an authorizing body to approve. In larger projects, a steering committee is usually formed to help make decisions on these efforts with the project sponsor as the chair, and in smaller projects, the project sponsor would make final determinations. If a change is authorized to proceed, the project manager should make sure the change is communicated to all impacted parties, which may include stakeholders beyond the project team, such as other project managers, who may have to wait before starting an activity on their project, or system owners, who may need to make a change to their application to accommodate the change request. Finally, once the change has been approved, it should be added to the project plan, which should then be re-baselined to serve as the new master plan.

Managing Expectations

The expectations of a sponsor or stakeholder may vary from project to project, although there are several common expectations across all stakeholders. Common expectations, include easy access to services and team members, first-time resolution to requests for assistance, evidence that the organization, project manager, and team cares about the project, and perhaps most importantly, no unpleasant surprises [23]. One of the best ways a project manager can manage expectations appropriately is by having frequent, clear, concise, and honest conversations with stakeholders. Any policies that the project manager will follow, particularly around change management, should be discussed early in the project during the planning phase. Conversations around project assumptions, constraints, risks, and issues should be ongoing, with status reports to demonstrate that the project manager is working to complete the objectives of the originally defined project. Setting expectations beyond what was originally planned is dangerous and may fall into the area of scope creep as previously discussed.

Project managers need to be cautious in these communications, however. It may not be necessary for stakeholders to be aware of every issue on a project, else they will risk that the stakeholder may become frustrated by a seemingly never-ending list of problems. This could lead to early project cancellations or a loss of confidence and support from leadership. Thus, while it is important to convey the status of the project, a project manager should be judicial in determining the items, both positive and negative, that are most likely going to impact the stakeholder.

Although the project manager will make every effort to meet the needs of stakeholders, there is still a possibility that expectations will not be met. Thus, a project manager must have appropriate soft skills to deal with these circumstances. It is quite possible that a project was completed successfully, meeting all objectives and requirements, but stakeholders still feel that the project was a failure because the end product or service does not perform as well as expected, or user interfaces may not be as intuitive as hoped. It is easy for a project manager to become defensive, reiterating that the project met all requirements, although there must also be some level of compassion. Project managers can use reflective listening skills to paraphrase issues back to the stakeholder, providing evidence that the situation was understood [23]. The project manager can also offer to escalate the issue through his or her chain of command, or provide comparable alternative options, perhaps via a separate project or changes to the existing system through the organization’s configuration management practices. And in some cases, a simple apology without accepting blame may be sufficient, with promises to document the issue as part of lessons learned to help reduce the possibility of future occurrences.

Balancing Competing Priorities

Every project manager will need to balance competing priorities, whether that involves multiple assigned projects, or working amongst other manager’s competing projects and operations work. Just because these varying priorities exist does not necessarily indicate a problem in an organization. For example, if one project manager is deploying a Patient Portal, while another is implementing Barcode Medication Administration using some of the same human resources, it’s difficult to argue that one solution is better than the other. Rather, it’s important to understand that these priorities exist and determine strategies for managing them.

To help determine the most appropriate strategy, a project manager should understand where the competition exists. For example, if the situation is with over-allocated human resources, the project manager should assess whether any work can be rescheduled or reassigned without impacting the project timeline or if any work being duplicated across projects could be consolidated.

If there is no way to avoid the conflict, and it is going to impact one or more projects, a decision will need to be made on which item has the higher priority. One effective way to determine priority is by creating an urgent-important matrix across projects. This matrix can divide projects and operation work into one of four categories:

• 1. Urgent and important,

• 2. Not urgent but important,

• 3. Urgent but not important, or

• 4. Not urgent and not important.

This matrix will help bring to light where different projects fall across this spectrum [24].

If there are still competing priorities, however, the project manager can elect to create a decision or options document for a project sponsor to review, which should present the trade-offs, as well as the positive and negative consequences of a given decision. From there, the sponsor, in collaboration with other business stakeholders, can make an informed decision on how to best prioritize work. Some organizations may also benefit from having a project governance body that can help set project priorities, either by a voting or scoring technique.

Regardless of the competing priority, it remains the project manager’s responsibility to ensure project objectives and requirements are met in accordance with the defined processes and procedures documented in the project management plan, and the organization’s project management practices.

Implementation vs. Development Projects

Oftentimes, healthcare projects will involve the implementation of IT components, such as software and hardware. As healthcare projects have increased, so have the number of options available for commercial off-the-shelf (COTS) products that can be procured from external vendors. However, the unique circumstances of an organization may require the implementation of a custom-developed solution, either in-house or via a third party contractor. Either solution may serve to benefit the organization, but each also has unique challenges that must be considered by the project manager and stakeholders.

If the requirements of the organization can be met with an existing product, the implementation of a COTS solution may appear to be beneficial for several reasons:

• 1. Other similar organizations may have already deployed the product, so the project manager and organization may be able to acquire the lessons learned of other implementations.

• 2. Since the solution already exists in some capacity, it may be able to be implemented faster using experiences staff or pre-defined project plans.

• 3. The work to maintain and support the system could be outsourced directly to the software’s vendor in the form of a maintenance agreement.

Implementing a COTS system, however, has several drawbacks, particularly as it relates to meeting any unique needs of the organization. In order to keep the system as standardized as possible, the implementation of new requirements or feature requests will usually be analyzed across all of the vendor’s clients. If the request does not benefit the overall business of the vendor or the product itself, it may be difficult or impossible for an organization’s unique needs to be met. Or, if the software allows for minor customizations, they could be time-intensive and costly with little support in future software versions. Additionally, as a COTS system grows in size and complexity, an organization has fewer options for future replacement. The replacement of an EHR, for example, could cost millions, if not billions of dollars and take several years to complete. Thus, it’s critical that during the procurement process, all of an organization’s requirements are well-defined and communicated early.

If a project manager is assigned a COTS implementation, the following should be reviewed during project planning:

• 1. Required training for the staff that will use or configure the system, and who will provide that training.

• 2. The gap analysis between the COTS product and organizational process workflows and requirements.

• 3. Software testing and criteria for software acceptance.

• 4. Roles and responsibilities between the organization and the vendor, particularly for installation, configuration, implementation, and ongoing maintenance.

For some organizations, given the limitations of a COTS product, it may seem that a custom solution may provide a greater benefit for unique requirements. Some benefits of custom development include:

• 1. A product that meets the specific objectives of the organization.

• 2. The flexibility to add or remove specific features in the future in shorter time intervals, based on the changing needs of the organization.

• 3. Direct access to the human resources that developed the software.

• 4. Ability to control the software related to when and how to update the system.

However, custom developed software may also incur larger short-term costs with fewer of the ‘bells and whistles’ that may be pre-packaged in a COTS product. The most important consideration of a custom developed product is the collection of complete and comprehensive requirements from stakeholders. Business analysts, system designers, and programmers are critical roles to include on the project, as they will work together to develop the software [25]. The work may be outsourced to a software development contractor, but these roles will still be needed at some level. Some of the tasks involved with custom development include:

• 1. Development of specific and testable software requirements and business rules.

• 2. Design of the software, which may include prototypes and mockups for a stakeholder to review. It’s possible that the stakeholder may want to add additional features upon first seeing the system, but it’s important for the project manager to maintain strict change control, just as with any other project. Changes can always be deferred until future versions.

• 3. Development of a comprehensive testing plan against every stated requirement. Given that the software was developed fresh, the emphasis on testing and quality is even more critical than on COTS systems.

• 4. Determination of allocation of build resources for post-project support. It’s possible that the human resources that developed the tool may be the same resources to provide post-live operations and maintenance, but this should be determined early, especially if the work was completed by a contractor.

Regardless of the implementation of a COTS or custom development solution, upon closure of the project, the project manager is no longer the point of contact for the software, so a complete transition to a support team should be part of any project plan.

Emerging Trends

A 2014 PMI research study finds that project managers are facing an increasingly complex and challenging environment [26]. Organizations will need to be more innovative and more efficient to be competitive. The emerging trends in project management all have the goal of helping project managers meet the challenges of today and to deliver successful projects meeting the expectations of the diverse stakeholders.

Distributed Project Teams

Project teams are spreading out and usually do not work or meet face to face regularly. They are becoming more dispersed within different buildings in the same organization, or different states, or across multiple countries and have increased availability of teleworking. As this trend continues there may be ongoing challenges with time zones as well as keeping the team engaged [27]. This trend will also test project managers to find creative solutions to keep stakeholders involved and informed. As communication tools become more widely available, connecting with team members and other stakeholders will become less of a challenge. New audio, video and instant messaging tools continue to decrease the need for email and provide more synchronous communication. These varied communication methods need to be incorporated into the communication plan. The project manager needs to define when each type of communication can be used as well as how often, if at all, the team should meet face to face.

Cloud Based Collaboration Tools

One tool that assists with diversified teams is the emergence of the Cloud. The cloud is revolutionizing the way documents and schedules are shared [28]. Keeping project documentation in a centralized location is not new, but expanding access beyond the use of shared server drives expands accessibility. Cloud collaboration can allow team members to work on a single document, or comment on others’ work, simultaneously [27]. These tools also provide improved communication with stakeholders. Teams need to understand and participate in these tools, rather than keep data on their personal hard drives. Depending on the tool, project sponsors, and other stakeholders, may be able view the status of any project in real-time. This could provide a method to augment or complement the regular weekly or monthly status reports.

The increased use of mobile technology, such as smartphones or tablets, can also give team members the flexibility they crave [29]. Many cloud-based tools provide access through mobile applications and more will be providing this access as the use of these devices continue to increase. Cloud storage improves sharing and communication across devices and locations [28]. One concern with Cloud based tools, however, is data security and privacy. While this is beginning to be addressed, many organizations continue to be cautious about putting project documentation being stored in the cloud where it can be hacked or they have no control over the security controls. Cloud-based tool vendors will need to continue working on demonstrating the security of their products for adoption by some organizations.

Compressed Project Work Cycles

Organizations are becoming more aware of return on investment and want to see the outcome from their expenditures sooner. This leads to an increased demand to compress the project work cycle and produce deliverables quicker. There are multiple techniques for this purpose, but many are focused on applications that are custom developed rather than purchased from a vendor. Iterative prototyping and agile approaches will have an increasing important role in reducing time to market for the custom developed applications [27]. These tend to be more difficult to use for projects that include COTS applications.

Healthcare organizations tend to focus on implementing COTS applications since the government is providing incentives for meaningful use of Electronic Medical Records Systems (EMRs) and the emergence of Personal Health Records (PHRs). Few healthcare organizations have the skill set or the desire to build their own EMR or PHR system. For these projects, there are fewer opportunities for a compressed work cycles. Implementing in phases, when possible, allows the functionality to be delivered in smaller ‘pieces’ and with shorter turnaround time for the stakeholders to see a return on their investment. Using a vendor developed model can also help to reduce cycle time.

Whatever method the organization adopts to help compress the schedule, having a defined process that is consistently followed will continue to be key to successful projects. The majority of organizations create their own project management methodology to match their unique needs and culture [30].

Project Management Skills

With the changes occurring in how projects are managed, the skills of the project manager will need to change as well. There will continue to be a need for soft skills and with some of the expected trends, these may become more important. The project manager will need to adjust their communication styles to include new tools and to adjust to the distributed teams or the use of outsourcing. They will also have to learn new ways to coach, mentor and motivate project team members. Project managers will need to run projects and manage the teams and to have more leadership skills than ever before [28]. Refer to Chap. 14 for additional discussion on leadership skills.

With the changing role of project management employers are looking for project managers who have project management experience, making it difficult to enter the profession [27]. Many are requiring project management certification for any open position as proof of experience. Being able to manage multiple projects at the same time is a skill that will be setting project managers apart and will be highly valued for future employers [28]. Project managers need to continuously learn as trends change. Only 52 % of organizations have a formal process for developing the competencies of project managers. These organizations report a significantly higher percent of projects meeting project goals, business intent and completing on budget and on time [30]. The use of virtual learning is will become more valuable as they are less likely to be able to get away to attend offsite education or have budget constraints. Skills will need to grow and expand as the role changes and organizations need to be able to provide support, and time, for this to occur.

Governance

A study by PMI shows that only 42 % of organizations have high alignment of their projects and their organizational strategies [26]. This lack of alignment contributes to the report that 44 % of strategic initiatives are unsuccessful [26]. It is important that projects are evaluated based on defined criteria, one of which is alignment with the organization’s goals and strategic plan. The development of a governance committee to review project requests is one method of verifying the projects that move forward are those that deliver the most benefit to the organization. Defined criteria that are applied consistently across all requests ensure priorities are set not only for project approvals but also in what order they should be started. This helps to avoid the impression of favoritism and ensures the right projects are approved expending the available resources in the right place.

Emerging trends can be just what is needed to mature an organization, but they can also be a distraction. Effective project managers should focus on the skills and tools to deliver successful projects. Stakeholders value the deliverables and final outcome. Each new trend, concept, or tool should be evaluated with an eye to improving your processes and situation.

Summary

Healthcare will continue to change and projects are everywhere. Strong project management processes can help reduce the risk of project failure. The defined process groups, from the Project Management Institute, can be used to help define the specific steps that are best practices for a project to go through from Initiation to Closure. Each step has defined activities and deliverables that feed into the next. Many tools were also discussed along with how they fit into the project management process. These tools, such as the project charter, WBS and communication plan, all help define the project and how it will be completed. Each of these tools can be tailored to meet the specific need or organization, but their purpose and benefit will stay the same.

Managing resources, human and non-human is a skill that all project managers should have. They are often called upon to manage the competing priorities of the project team to ensure the project schedule is not delayed. The future trend of distributed teams will require the project manager to look deep into their toolkit to find new ways to manage the project team and ensure solid communication. Stakeholder expectations are always a challenge, but taking the time to complete a stakeholder analysis will help to define how to manage the different groups. A strong project management process, with defined tools and experienced project managers, can help to ensure project is completed successfully, on time, on budget, meeting requirements and stakeholder expectations.

Clinical Informaticists are often called upon to fill many roles during a project from end user, to team member or even project sponsor depending on their position within the organization. They may even be called upon to be the project manager whether they have prior experience or not. This chapter touches on the skills, tools and expectations of a project manager from planning, facilitation, communication and management.

Questions for Discussion

• 1. Have you been involved with any projects that have gone particularly well (or not so well), and what do you think was the underlying reason as to why?

• 2. Identify at least five potential projects that may be undertaken by a healthcare organization, and define what work may be undertaken in each of the project process groups.

• 3. What are some common challenges that may be faced on Healthcare IT projects?

• 4. What is the purpose of a project charter?

• 5. How does a work breakdown structure (WBS) help to create the project plan?

• 6. As a project manager, how can you best keep a stakeholder happy that has continually changing requirements, without sacrificing the scope of the project and risking scope creep?

• 7. If you were the sponsor of a project to implement a new system, but the end product did not meet expectations, what recourse would you expect from the project manager?

• 8. Identify at least three different potential collaboration tools that could be used with a distributed project team, and how they can improve communication.

• 9. What are the reasons why project managers need to expand their leadership skills more than ever before?