Risk management in healthcare information technology (HIT) projects
Health care information technology is on the brink of a paradigm shift. There is a push to implementing electronic medical records, and there are substantial risks associated with this critical initiative. These risks need to be identified and managed. Fortunately, project management is designed to manage risks. Project management methodology has a systematic approach to anticipating unknown risks, prioritizing known risks, and placing resources and attention toward those most likely to threaten the critical success of the project. There are, in effect, two types of risks associated with Health Care IT projects: project risks and organizational risks. These risks need to be managed meticulously in order for the organization to realize the business benefits and value of the project outcome. This paper will address both types of risks.
While there are many ways to approach risk, and these methods vary by culture and industry, these differences are being addressed in other forums. We will focus on the professional methods delineated by the Project Management Institute in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (PMI, 2003).
Risk is an uncertain event or condition that, if it materializes, can have a positive or a negative effect on project success. Risk includes both threats and opportunities. Risk management is a systematic approach to identifying, analyzing, and responding to risks, maximizing the probability and consequences of positive events, minimizing the probability and consequences of adverse events (PMI, 2003). With every risk there is an opportunity; if managed well, it can be used to the advantage of the project customer. Awareness of a potential problem is good, put it on the table, discuss it, plan for it, and manage it.
Information Technology is almost a new word in the healthcare industry. Traditionally, health professionals and the health care industry have put substantial emphasis on the practitioner's knowledge and skills and the practices of the individual expert. Collaborative use of information systems and systematic business management of critical health data is somewhat threatening to the traditions of medical practice.
There is a natural tension between the interests of the healthcare professional and the interests of the business executive. Business executives are concerned with the financial viability of the organization, the return on investment, and the revenue cycle, which are usually the drivers for information technology systems and initiatives. However, healthcare practitioners have to utilize these systems, assist in their implementation, and contribute to their optimization. There is big risk in not managing this organizational tension effectively. Without the acceptance and adoption of new information technology by practitioners, the benefits may never be realized. It is fundamental to the success of IT projects that they provide tangible benefits to the end user.
Utilizing information technology in the healthcare environment introduces change, and change generates resistance. However, change is not new to healthcare. Until the late 19th century, the medical profession was based on mythology and lacked a systematic approach to diagnosis and treatment. Then elements of science, scientific methods and empirical evidence were introduced to medicine, and the phenomenal progress since then has changed the course of history (Barry, 2005).
Regardless of our particular role in the healthcare industry or our professional antipathies, information technology is upon us. Let us manage it right!
What makes healthcare unique? The healthcare industry deals with human life; it operates 24 X 7 X 356. It is fast-paced, rooted in tradition, knowledge-oriented and skill-based, and utilizes highly educated and sophisticated professionals.
Information technology projects are also unique. They involve innovation. Many healthcare practitioners avoid innovation. There is a natural tension between tradition and innovation. Innovation introduces change, and change produces uncertainty. Information technology is very expensive; if not used well can be a waste of resources, both human, and financial. IT creates dependencies, dependencies on systems availability (for data retrieval), up time, speed of data processing, and data integrity, as well as dependency on other professionals to sustain the environment. There are common language issues, standardization issues, application integration issues, confidentiality and security issues, and myriad new rules and regulations that add complexity to the healthcare environment. Complexity brings added risk and uncertainty.
Project Management Methodology brings hope. Time-tested tools and techniques aid in defining, responding, and managing the risks created by these complexities. The systematic thinking inherent in the project management discipline brings order to chaos. The science and art of project management, the mix of hard-skills and soft-skills, setting “SMART” goals, and utilizing standard methods and a common lexicon add value to decision-making and problem solving. The Project Management Methodology, The PMBOK® Guide, and other publications provide guiding principles for risk management and risk response planning.
Managing risk is the systematic process of identifying, analyzing, prioritizing, and responding to risk. Managing risk is not new! We do it every day. Buying insurance is just one example. However, varying scales of situational complexity and potential risk impact deserve variation and flexibility in applying risk management strategies based on scale, probability, and order of magnitude.
Planning and Identification of Risk:
One sure way for planning and identifying project risks is to follow the project life cycle process (IPECC): (1) Initiate, (2) Plan, (3) Execute, (4) Control, and (5) Closeout. The caveat here is that many IT projects do not consciously separate the project life cycle from the product life cycle; there is an overlap. Not separating the project/product life cycles encourages confusion and misaligned expectations (Cooke & Tate, 2005). A project is formed to implement what can be effectively defined, planned and managed. If there are too many unknowns, the first project may be planning or just a feasibility study. It is recommended that the project life cycle be addressed separately from the life cycle of the product being developed (the outcome of the project). Defining scope means defining what stages of the product life cycle will be included in the project phases. It is worth noting that not all projects will include the entire life cycle of the product, since it will, for some part of its life cycle, be producing value for the customer.
The life cycle of the product in information technology is different from the project life cycle. The product life cycle usually comprises of, (1) Defining the concept or idea (2) Designing (process steps designed), (3) Building (test, validate, train), (4) Implementing (install, start-up), (5) Delivery (turn over to support), (6) Daily operations & maintenance (use standard processes), (7) Eventual replacement (refresh cycle of five to seven years is common practice.)
II. Qualitative and Quantitative Risk Assessment Techniques:
Risk assessment rating and analysis techniques help us better understand the magnitude of the risk and its potential consequences. The degree of severity of the risk's consequence is the driver to plan a response and be ready for action if the event actually happens.
Qualitative risk is a nonnumeric (subjective) estimate of the chance of a risk happening and an analysis of the best methods for countermeasures. The input to this method comes from the subject matter experts (SME), and from historical evidence found in documentation and lessons learned from previous engagements. The long-term value of this method comes from repeated measures and trending, which tends to give results that are more accurate.
Quantitative risk analysis focuses more on numeric methods and attempt to use repeated measures to derive estimates. Examples would be Monte Carlo simulation technique, decision tree analysis, and sensitivity analysis.
Quantitative risk analysis usually follows qualitative. The decision to use one method versus the other, or use both methods, depends on the need and the comfort level of the PM practitioner. The key element in these analyses is to be able to decide, with the team, on the risks faced, their potential impact, rank, and priority, then move on to plan the responses. It is important that the team do not dwell on these processes; however, it is important to revisit the issues and repeat the process at regular intervals. Once a quarter is often enough on a large project to stay current. Putting data in a table format is advisable. An example is provided in Appendix A. Templates and helpful examples in publications and books can be used as references (Cooke & Tate, 2005 and Mulcahy, 2003).
III. Risk Response Planning (RRP):
The main methods for risk response planning are:
- Risk Avoidance, such as changing the implementation methods, resources, or the project plan.
- Risk Acceptance, for example, having a contingency plan prepared as a back-up system.
- Risk Mitigation, for example, adding countermeasures to the project plan.
- Risk Transfer/Shifting risk, for example, by contracting externally or outsourcing.
IV. Risk Monitoring and Control in HIT Projects
|Sources of Risk||Risk Management Strategy|
|1||Planning Risks|| |
Avoid misunderstandings & scope creep, do SOW and WBS. Management commitment is critical, and needs to be built into the plan. If the project is too low in the management hierarchy, this task takes on added importance and takes more time as well.
Support infrastructure must be identified or built into the plan. Alignment of the existing infrastructure elements may be needed to incorporate the new features of the project outcome.
Reputation/credibility are important to earn trust of stakeholders; select and communicate credentials and track record.
Visibility has pros and cons; getting the organization involved is necessary for quality; tell them what to expect so they buy in.
Funding must be based on accurate estimates and realistic for the full scope of the product life cycle. Budget for close out.
Public relations are a part of the plan; a conflict management plan is less visible, but is part of good risk management. Put detractors into the risk management plan and assign someone to maintain relationships with each skeptic throughout the project.
|2||Initiation Risks|| |
Avoid grandiose goals. SMART goals are necessary to engage the best efforts of the team and to sustain credibility for the end results. If you cannot quantify it and manage the triple constraint, break it into smaller, sequential projects. Do not over promise; protect early estimates of time and cost from becoming set in stone. Estimates are based on operations that have already benefited from repetition and refinement.
|3||Scheduling Risks|| |
Delay: Seek out historical precedence from other IT projects in the past. What is the average delay, and typical causes?
Overrun: Calculate the average standard overrun of other projects and build that into conservative estimates of completion.
Crashing: Is it a habit? It is a risk? Is it a result of poor planning?
Inertia: Create a sense of urgency with realistic but firm due dates. Implications of inertia are that letting the project extend too long allows unknown crises to immerge. Over-analyzing issues is counterproductive; select project managers with a natural inclination to take action.
Deliverable/milestone tracking system
|4||Resources Risks|| |
Practitioner: Get the right expertise, protect their allocation by involving their management in the value proposition. Proper orientation, training, job roles and teamwork are a given. Delegate enough authority so they are empowered to do their job, and protect them from unwanted interference. Know when to escalate to their upper management to avoid stalling.
Middle Management: Focus on relationship skills as well as technology or business knowledge; do not underestimate the importance of meetings. It is not top down; it is middle up.*
Try weekly meetings to review priorities and backlogs.
Executive: Get and keep the right sponsorship at the right organizational level to run interference for the project on all fronts. Project governance needs to be set at the right organizational level to involve the key players in all departments.
Allocation: compare to other projects 100% allocation, not more to avoid burn-out, implement methods for retention.
Executive sponsor intervention…stealing staff
Lack/shortage – hire & retain the best and brightest
Access to qualified expertise
Contracting: if possible (pros/cons) feasibility (expand the role of the business analyst to incorporate the entire system. Hire business analysts who can sell the concept and negotiate the appropriate support or issue resolution.)
|5||Procurement Risks||Vendor Management |
Maturity level match of capabilities
|6||Quality Risks||Avoid compromises or Gold Plating |
Advocacy vs. collaborative decision making (quality process)
|7||Communication Risks|| |
Inadequate communication, more is better than less
Appropriate media for level of recipient and content/complexity of message
|8||Education/Training Risks||Type (educate versus train) |
Amount of training and its cost
Timing of training - Just in time training
Certifications periodically and ongoing
Value to delivery critical success factor
|9||Relationship Risks|| |
|10||Budgetary Risks|| |
|11||Critical Path failure risk|| |
|12||Technology Risks|| |
|13||Acts of God – Force |
Strategy for Professionalism:
Using an overall risk management strategy is a good practice; the following are examples:
- Create an environment that fosters success, i.e. position yourself for success, surround yourself with positive/successful people with a natural inclination for action, make sure you have supportive sponsors and executives (Welch, 2000; Collins, 2001).
- Guard against fantasy. Be realistic. Always have a baseline. Dig into the real state of affairs with courage. Do regular sanity checks. Make sure to address people issues, operational processes, and strategy, (Boosidy & Charan, 2002)
- Educate yourself (gain and apply knowledge and wisdom). In a learning organization, research the past and use the lessons learned. Trends of history in the organization are useful (Senge, 1990). “Knowledge is Power!”
- Build/craft coalitions and partnerships with key entities (constituencies and stakeholders.) Create nurses users group, physician users group, and work with them, listening to their needs and concerns (Deluca, 2002; Goldsmith 2002).
- Set strategic direction. Decide where you want to go and where you want to be in the future. Align with the business strategy of the organization and each of the affected groups, (doctors, nurses, administrators, educators, patient advocates, and all other users) (Glaser, 2003).
- Communicate – Communicate – Communicate: frequently, honestly, and succinctly using appropriate methods and all available media channels. A formula to remember is, communication channels = n * (n-1)/2.
Summary, Conclusions, & Recommendations:
The goal of this study is to share knowledge about risk management with the day-to-day practitioners, equip them with the tools to use on the job, and make them better project managers in risk assessment and documentation. We also, hope to instil confidence to use these techniques. We did not cover it all! This is a very dynamic field and information grows exponentially.
In summary, we have tried to describe the environment for healthcare information technology, the key players in this field, the critical issues, and industry experience.
The challenge is to introduce new concepts by using a holistic approach to managing risk. Taking into consideration the project as well as the organization, the software as well as the hardware, the programmer as well as the end user, consider partnering with your IT vendor. Plan and have a contingency plan. Involve your stakeholders and executives, and let them have a sense of ownership. Successful HIT projects are a collaborative effort, and working together is the only path to success.
Barry, J, M. (2005). The Great Influenza. London, UK: Penguin Books Limited.
Bossidy, L. & Charan, R. (2002). Execution – The Discipline of Getting Things Done. New York, NY.:Crown Business Press
Collins, J. (2001). From Good to Great – Why Some Companies Make the Leap…and Others Don't.: New York, NY: Harper Business Press
Cooke, H. & Tate, K. (2005). The McGraw-Hill 36-Hour Project Management Course. New York, NY: The McGraw-Hill Companies, Inc.
Deluca, J. & Enmark, R. (2002). The CEO's Guide to Health Care Information Systems. 2nd Ed. San Francisco, CA: Jossey-Bass, A Wiley Company
Drucker, P. (1992). Managing for the Future – 1990s and Beyond. New York, NY: TT/Dutton Press.
Glaser, J. (2002). The Strategic Application of Information Technology in Health Care Organizations. 2nd Edition. San Francisco, CA: Jossey-Bass, A Wiley Company.
Goldsmith, J. (2003). Digital Medicine -- Implications for Healthcare Leaders. ACHE Management Series. Chicago, IL: Health Administration Press
Haugan, G. (2002). Effective Work Breakdown Structures. Management Concepts: Vienna, Virginia, USA
Jacobs, B. (Publisher) & Wharton, A. (Editor). (2004). Health Care Technology: Enabling Collaboration between Payers and Providers. Volume 2. San Francisco, CA: Montgomery Research, www.HCTProject.com
Kerzner, H. (2001). Project Management – A Systems Approach to Planning, Scheduling, and Controlling. 7th Ed. New York, NY: Wiley & Sons
Mulcahy, R. (2003). Risk Management – Tricks of the Trade ® for Project Managers. RMC Publications, Inc. www.rmcprojct.com
PMI, (2004). A Guide to the Project Management Body of Knowledge (PMBOK® Guide). 3rd Edition. Newtown Square, Pennsylvania, USA: .Project Management Institute, Inc.
PMI, (2003). The PMI Compendium of Project Management Practices. Newtown Square, Pennsylvania, USA: .Project Management Institute, Inc.
PMI, (2003). Organizational Project Management Maturity Model (OPM3®) -- Knowledge Foundation. Newtown Square, Pennsylvania, USA: .Project Management Institute, Inc.
PMI, (2002). Project Manager Competency Development (PMCD) Framework. Newtown Square, Pennsylvania, USA: .Project Management Institute, Inc.
Senge, P. (1990). The Fifth Discipline – The Art & Practice of The Learning Organization. New York, NY: Doubleday Currency
Welch, J & Byrne, J. (2001). Jack: Straight from the Gut. New York, NY: Warner Books
Sample Template for Risk Analysis & Risk Presentment
Risk Impact: (1) Very low (3) Low (5) Moderate (7) High (10) Very High/Critical
Probability: is a continuous measure of the chance of an event actually occurring, from 0% to 100%
|No.||Sources/Types of Risk||Probability of the Risk Event||Impact of this Risk||Estimated Risk Score||Recommended Risk Response Action Plan||Person Responsible||Comments/ Status|
|1||Technical failure, e.g. server crashing||10%||10||100||Have a backup server as a contingency||Technology -- Server Specialist||Failure did occur; was managed as planned in RRP|
Appendix B – Diagram – Risk Mind Mapping
©2005 Laua Aziz andHelen
Originally published as a part of PMI Global Congress 205 Proceddings Edinburgh, Scotland