Anticlue

Risk Management & Healthcare IT

Surprisingly, it is simply amazing how essential the practice of risk management is in Healthcare IT projects and how often this practice is abandoned. As organizations mature and grow from a reactionary mode of operations to a proactive mode, risk management is often utilized in proactive organizations. However, when it is most needed in reactionary status, the organization isn't sophisticated enough to follow this practice.

For example, suppose you are a newly anointed project manager in an integrated delivery network, a local hospital system with a new practice structure. Project Management is a fledging practice. Organizationally, there is no work authorization practice. Requested Work is kept on individual lists for the application managers, (finance, revenue, clinical), application director, and the technology directors. Additionally the nuts and bolts of technology are outsourced, and technology managers (networking, telecom, desktop, client server) also have their own listing. Your morning visits to the local coffee shop are plagued with follow-ups in requests lost or misinterpreted on one of too many lists. The IT investment of the day goes to the business partner with the largest voice. Organizationally, the interpretation of the bottleneck is of not having project managers to manage the projects, not the lack of resources to do the projects. Often, project manager end up running the project, but also designing, constructing, testing, and deploying the solution. These considerations are constantly on your mind. After all, it's the technology investments of the organization you are responsible for delivering with your project sponsor.

You and the project team can easily manage some of the possible problems. These just need a quick tweak to a technical design or modification of workflow when the problem occurs. For example, there is no need to have an elaborate plan in place to add a field or two to an interface. Any technical pm worth their mustard should know how to handle that one and act accordingly.

However, it is obvious that there are graver risks, which are going to require some serious planning in advance. Resources being overloaded and pulled for other projects is such a risk. You should be aware that at any time, those who control the resources would pull the resources back to handle a fire, or support a higher priority project from their concern. In order to prevent such an occurrence, you need to do a significant amount of due diligence, including finding out other initiatives for resources needed for the critical path. Possibly even evaluating contract work for the integration work, and having the vendor solution analyst work with the sponsor as much as possible. There are many different routes to handle this risk although they all will require additional money.

The actual occurrence of a resource extraction will be invisible when it first happens. There aren't a lot of gates for the development of the interfaces, so you need to put in place and monitor some kind of control to highlight when a resource isn't dedicated to the project. You decide to note, that the team mates participation in the weekly meetings, and a stagnant status for a week are your indicators to enact an outside consultant. You choose to have the resources managers report status of the interface builds in a weekly review meeting. You also get outside estimates for how long a billing interface should take to build for a system with this level of customization.

Realizing resource extraction is only one of the risks requiring advanced forethought; you call a meeting with your project sponsor, executive sponsor, and key stakeholders. You review the potential problem with them, suggesting having a risk-discovery brainstorm, and develop a definitive list of potential problems, which need to be managed.

This is the ideal, however it is a good exercise to start the process of risk management. A risk is a potential problem. Once the risk occurs, it is not a problem. The point at which the risk materializes is the moment of risk transition. Once transition occurs, the project manager should act upon the plans to mitigate the risk. For every risk there is a transition indicator. For our risk above it is the lack of movement on the weekly status.

However, remember to educate and coach the organization. Persistants also helps to bring enlightenment.