Healthcare Information Technology Research & Analysis : Coplan & Company : IT Procurement Management, Project Management, System Acquisition

Project management methodologies offer valuable theoretical frameworks. Unfortunately, a practitioner can spend more time deciphering these methodologies than putting them to practical use.

I had nine weeks to teach project management to mid-career clinicians. To be effective in this short period, I decided to teach my students the practical application of the theoretical methodology described in the Project Management Institute's Project Management Body of Knowledge (PMBOK).

As a 30-year practitioner of project management applied to information technology projects, I intuitively understand the difference between practical application and theory. However, teaching what I know intuitively is a challenge. Nonetheless, this is what I did:

• I never understood why it made sense to organize a project management course by each Knowledge Area found in PMBOK. Knowledge Areas are sets of skills project managers must know if they expect to manage projects effectively. For example, effective project managers must know how to manage scope, time and cost.

While project managers need to understand the Knowledge Areas, they must know how and when to apply them during a project. PMBOKs Process Groups organize projects into Initiation, Planning, Execution, Control and Closing. PMBOK states that Knowledge Areas and Process Groups interact, concurrently, throughout projects. Even an experienced project manager using PMBOK can get lost in individual Knowledge Areas and lose sight of how and when to apply them to the Process Groups or project lifecycle.

My solution was to turn PMBOK on its head and teach my class based on Process Groups, addressing Knowledge Areas as they occur throughout a project. This was a challenge, particularly since PMBOK fails to include an effective picture that conveys Knowledge Area and Process Group interaction throughout a project. I found that hypertext links on a Web page offered a pictorial solution that displays how Process Groups and Knowledge Areas fit together. As an example, click here.

• This also gave me an opportunity to address another issue. PMBOK describes Process Groups as re-occurring consecutively throughout a project. The sequential nature of Initiation, Planning, Execution, Control and Closing is confusing. I never felt comfortable with this sequence when applied to Execution and Control. When I see Execution and Control sequentially, it reminds me of driving a car without steering it. I addressed this last issue in my class by always displaying Execution and Control as concurrent Process Groups.

The feedback from the class was that these two ideas effectively communicated how to put a well-respected project management methodology into practice.

Below is a description of how I teach HIT project management. The feedback from my classes is that these ideas effectively communicate how to put HIT project management methodologies into practice.

PROCESS GROUPS VS. KNOWLEDGE AREAS

I never understood why it made sense to organize a project management course by the Knowledge Areas found in the Project Management Institute's (PMI) Project Management Body of Knowledge (PMBOK). Knowledge Areas are skill sets project managers must know if they expect to manage projects effectively. For example, effective project managers must know how to manage scope, time and cost.

While project managers need to understand the Knowledge Areas, they must know how and when to apply them during a project. PMBOK's Process Groups organize projects into Initiation, Planning, Execution, Control and Closing. PMBOK states that Knowledge Areas and Process Groups interact throughout projects. Even an experienced project manager using PMBOK can get lost in individual Knowledge Areas and lose sight of how and when to apply them to the Process Groups or the project lifecycle.

My approach to teaching project management turns PMBOK on its head by focusing on Process Groups and addressing Knowledge Areas as they occur throughout a project.

Teaching project management also gives me an opportunity to address another issue. PMBOK describes Process Groups as re-occurring throughout a project. The sequential appearance of Initiation, Planning, Execution, Control and Closing is confusing. I am uncomfortable with this sequence, particularly when applied to Execution and Control. When I see Execution and Control sequentially, it reminds me of driving a car without steering it. I address this issue by always teaching Execution and Control as concurrent Process Groups.

TECHNICAL VS. MANAGEMENT KNOWLEDGE AREAS

PMBOK includes Knowledge Areas that focus on management processes and outputs required for successful projects. For example, the Human Resource (HR) management Knowledge Area includes the process of preparing an HR plan. The output is the plan. While understanding management Knowledge Areas is sufficient for the success of many projects, Information Technology (IT) projects require additional technical expertise. To resolve this issue, my project management course combines PMBOK's Knowledge Areas, technical Knowledge Areas I created from Institute of Electrical and Electronics Engineers (IEEE) processes and plans, and my own IT project management experience. The exhibits show how I arrange these Knowledge Areas by PMI Process Group.

HIT VS. IT

There are few good textbooks on IT project management and even fewer that address HIT. This makes teaching HIT project management challenging because there are no available resources to address complexity, privacy, safety, regulatory and other health care issues. While it does not address HIT, I teach my class using Information Technology Project Management, fifth edition, by Kathy Schwalbe. I must rely on my 30 years of project management experience to teach nuances specific to HIT project management.

PRACTICAL VS. THEORETICAL

As a Project Management Professional (PMP) and HIT project manager, as well as a teacher, my classes:

• Balance project and technical management theory with its practical use,
• Apply project and technical management methodologies to actual IT projects in health care and other industries and
• Integrate project and technical management methodologies with:
• Address the likelihood of overlooking "soft" skills, or how we influence and interact with each other and
• Address the likelihood of overemphasizing "hard" skills, or concrete technical capabilities, like effective use of Microsoft Project software.

LONG-TERM ORGANIZATION VS. SHORT-TERM PROJECT SUCCESS

A project is often considered successful if completed within time, budget and quality constraints. However, a project, by definition, is only short-term. Health care organizations must make a long-term commitment if they expect to maximize HIT value after project completion.

Maximizing HIT value requires continuous quality improvement. This can only occur in an organization whose leadership promotes a shared vision, culture and expectation that embraces and optimizes innovation associated with HIT. This subject is outside the scope of my project management course. However, my approach to teaching project management emphasizes the link between individual project requirements and organizational strategic objectives and associated measurable outcomes. Maintaining this link while managing a project contributes to the long-term value of an organization's HIT investment. Examples of long-term strategic objectives that link to HIT projects include the following:

• Focus on the patient first,
• Reduce wait time,
• Provide error-free medical care,
• Work without adding new personnel resources and
• Reduce waste.

 efore I taught a nine-week course on project management for health care IT, I contacted CIO’s of major hospitals and asked them what project management skills I should teach that most recruits are missing?

My students are mid-career clinicians that seek a role in IT project management. They want to manage health care IT projects to improve patient care and increase patient safety. For example, the Director of a Bone Marrow Transplant Unit and the Director of Clinical Operations each want to manage end users through all phases of an EMR project in their respective hospitals. After 10 to 15 years as clinicians, they are back in school in the Master of Science program on Clinical Informatics and Patient-Centered Technology at the University of Washington.

• The CIO’s responded to my question with the following list of skills:
• Leadership,
• Listening,
• Oral and written communications,
• Team building,
• Conflict resolution and management,
• Critical thinking and problem solving,
• Understanding and balancing priorities,</li>
• Balancing the big picture with attention to detail,</li>
• Understanding stakeholders' needs and</li>
• Change-readiness.

Responses emphasized the importance of "soft" skills, which tend to influence how people interact with each other. In contrast, there was significantly less emphasis on "hard" skills, i.e., more concrete technical capabilities, such as effective use of Microsoft Project software.

Everyone singled out the principle that the focus of projects is on how business changes, not on the technology used as a tool to support that change.

The most important tools and techniques identified included:

• Scheduling,
• Requirements definition,
• Issue tracking,
• Status reporting,
• Project costing and control, and
• Risk analysis and control.

Almost all of the CIO’s identified the need for a project management methodology flexible enough to meet the needs of their culture, for example a mix of Institute of Electrical and Electronics Engineers (IEEE), Software Engineering Institute (SEI) Capability Maturity Model Integration (CMMI) and Project Management Institute (PMI) best practices. No one cited strict adherence to a single methodology as a workable approach.

The majority considered the best project management background to include versatile individuals who have deep clinical/business knowledge that understand IT. One individual cited that an excellent source for a project manager is administrative operations where you have a detailed understanding of business processes required "to get the job done", e.g., managing central supply, purchasing or facilities management.

The response from the CIO’s did not surprise me. Most project management methodologies focus on the tangible because it is too easy to convey. The intangible, while less easy to express and learn, is just as important and requires equal time in the methodologies and while managing projects.

• Initiating
• Planning
• Executing
• Controlling
• Closing

I apply these process groups regardless of project type (e.g., healthcare IT, construction, event planning).

Product management is the "tangible result" of a project. I teach this using the Institute of Electrical and Electronics Engineers (IEEE) technical process groups focusing on:

• Planning
• Designing
• Developing
• Deploying
• Supporting
• Retiring

I apply these process groups based on product type. For HIT I use the Capability Maturity Model Integration for Acquisition (CMMI ACQ) standard.

Change management is how "people" transition from a current to a future state. Because there are no formal process groups, I teach this by focusing on:

• Vision - Defining the problem and identifying the endpoint at the project beginning
• Leadership - Communicating, demonstrating and motivating
• Consensus - Involving front-line and middle management in defining what the project includes and excludes and how they will get there
• Training - Creating individualized training, avoiding technical solutions to human problems, making the environment safe for emotional expression and learning from resistance
• Workflow Improvement - Providing improvement tools during and after the "project" is over

Change management applies to both projects and products.

Hoping future HIT project managers (and the projects they manage) will succeed by only teaching HIT project management is not enough. We must use an integrated approach that combines the disciplines of project, product and change management.

The Healthcare Information Systems Society (HIMSS) requested that I speak on Project Management: Ensuring HIT Sustainability Beyond "Go Live" at their 2009 Conference on April 4th. I am really excited about this opportunity to work with my co-presenters, including:

• Kim Brant-Lucich, PMP, 
Director of Process Redesign, St. Joseph Health System


• Charles Garrity, 
Senior Manager, Beacon Partners, Inc.

• Anil Jain, MD
, Managing Director, e-Research, eCleveland Clinic, Director, Quality and Research Informatics, Medicine Institute

I’ll focus on tying HIT project, technology and change management together. Kim will talk about process improvement, Chuck will tackle ROI and Anil will provide a clinician’s perspective.

I am also speaking solo on this topic for the Project Management Institute (PMI) Healthcare Special Interest Group at their March 5th Webinar.

I encourage my readers to attend these and other similar sessions to help advance these important topics and ultimately improve the success of HIT projects. Take a look at this draft and let me know what you think.

We've written a book! Dr. Dave Masuda a fellow instructor at UW Medicine and I just completed our book. McGraw-Hill will publish Project Management for Healthcare Information Technology (HIT) spring 2011!

The following individuals provided invaluable comments throughout the book:

• Florence Chang, CIO, Multicare, Tacoma, WA
• Robert Greenless, PhD, former CIO, Rancho Los Amigos National Rehabilitation Center, Los Angeles, CA
• Ernie Hood, CIO, Group Health Cooperative, Seattle, WA
• Beatha Johnson, Director Clinical Information Systems, Virginia Mason Medical Center, Seattle, WA
• Daniel Nigrin, MD, MS, CIO, Children's Hospital Boston, MA
• Michael Zaroukian, MD, PhD, FACP, FHIMSS, CMIO, Michigan State University, Lansing Michigan