Beyond Medical Informatics

Note: Here’s the final cut of my talk at the eHealth 2009 conference. I usually draft my talk, create slides, then finalize both talk and slides. During the session, I have a printed copy as a guide. This should be very close to what I discussed that afternoon.

—

Good afternoon!

I’ve been in the field of Medical Informatics for 7 years now. And one of the things I’ve learned is that Medical Informatics and Project Management go hand in hand. Project management is an essential skill of the medical informatics professional. Both tasks can be overwhelming. But they can also be very fulfilling.

Right now, I work as the Medical Informatics Consultant for St. Luke’s Medical Center. Aside from doing long-term strategic planning for clinical applications, I also manage Healthcare IT projects for the hospital. Here is a list of projects I am involved in. In these projects, I am either the project manager, or I supervise the project managers.

I’ve learned a few things about project management along the way. I’ve decided to share 7 of what I think are the most relevant to eHealth projects.

Here they are:

1. Identify the problem.
2. Formulate the success criteria.
3. Get the right people.
4. Communicate.
5. Who does What by When.
6. Use checklists.
7. Do post-implementation reviews.

Let’s go through them one by one.

Before starting any project, the organization should ask itself: Why are we doing this project? What problems are we trying to solve? What opportunities are we trying to take?

This process helps identify the vision, goals and objectives of the project.

I’d also recommend coming up with a problem statement. The problem statement cannot be the absence of a specific IT system. You cannot say that the problem of the hospital is that it does not have an LIS. Identify the business need or opportunity you want to address by doing an IT project. Try to come up with a problem statement that does not have any IT terms in it.

This underscores the point that: The IT project is NOT the project. It is an integral component of a bigger, more comprehensive, organization-wide plan.

All eHealth projects should start with this point of view. Why? Because all eHealth projects are basically healthcare improvement projects that have a strong IT component. The final result, the final benefit of the project lies outside the IT system.

Once you know why you are doing the project, come up with the success criteria. This basically asks the question: how do we know if we’ve succeeded in implementing a solution to the identified problem.

The success criteria are measurable items that identify the project’s business value. This is important for management buy-in. Try to be as detailed as possible. That’s why it’s also important that the success criteria are specific to the organization based on resources, capabilities and people.

Just a quick note on IT vendors: Sometimes working with IT vendors can be tricky or problematic, but I’ve learned it best to treat them as partners. And as partners, both of you should come up with an acceptance criteria specific to the IT or product implementation. You cannot expect the product to solve all of the organizations problems. But you can expect the product to perform or deliver according to an agreed acceptance criteria.

The next one is getting the right people. The project will not move on its own. People move the project forward. And with the right people, success, though not guaranteed, is much easier achieved. So, get the right people assigned to the right positions. Give them the right responsibility according to their strengths. Get them involved. Get them trained.

Investing in the right people is an investment towards successful eHealth projects.

The 4th one is to communicate. Take note that I did not say "draft a communication plan". Communicate. Communicate. Communicate. Have the desire to communicate the vision, goals, objectives, success criteria to the right people. Your communication plan is only as good as your desire to communicate.

So use whatever means possible. Use direct communications. Meetings. Memos. Email. Text. Whatever. If you cannot communicate, you cannot manage. If you cannot manage, your project cannot succeed.

Communication is the key to better ideas, better collaboration and better cooperation.

Project management is nothing more than the concept of managing ‘Who does What by When’. That’s it. A project is a basically a series of activities. Activities are people doing specific tasks by a given deadline.

Now, once you truly understand this concept, you will realize that project management is nothing more than just plain management and leadership.

The problem with current project management methodologies is that there is just too much paperwork. But the paperwork is NOT the project. The project is not the Gantt chart, the WBS, the MS Project file, the monitoring tool, the weekly report or even the overall plan. The project is the series of “Who does What by When”. The project is the management of people doing specific tasks by a given deadline.

Paperwork can be reassuring. And you do need some paperwork (reports, charts and plans) to help manage the project. But all the paperwork in the world will not help a project manager who does not know how to manage his people. All the tools in the world will not help a project manager who does not manage his people.

Lesson 6 is a practical advice. Use checklists. This is something I learned very recently. I try to use checklists for almost every task in the project. Do not rely on a mental checklist. Write the checklist down and distribute. Share your checklists. This will help assure you that people are doing tasks correctly and that they do not miss anything. Use checklists for activities, for specific steps, for specific items that will be used for each step, and even for people who should be there in a specific activity.

The last lesson is to do post-implementation reviews. It is important to document and learn from what went right and what went wrong. Be gentle but be brutally honest with yourself and with your team.

In my post-implementation reviews, I try to practice Hansei. Hansei is a Japanese concept popularized by the Toyota Production System. It is one word that combines the process of acknowledging your mistakes and making a pledge to improve. The process of Hansei is not only to learn from your mistakes but also to make a decision to change your behavior, to act better, to be better next time. Continuous improvement only happens if you practice Hansei.

An important lesson in project management is that even if you’ve outlined all the steps you need to take, even if you planned for all scenarios, even if you said you’d only share 7 lessons, something else always comes up. So, lesson 8, expect the unexpected.

Keep an open mind for change. Change is constant. Always be ready. Remember, change is not the enemy. Unmanaged change is.

And the best way to manage change–is to initiate change.

Thank you.

—

References:
Getting Things Done (David Allen)
Effective Software Project Management (Robert Wysocki)
Manager Tools

—

I will elaborate on each item in the coming days. Comments, questions and feedback are welcome!

Related posts:

1. Talk on eHealth Project Management
2. eHealth & Telemedicine Philippines 2009
3. Medical Informatics: 3 Intersecting Circles