Setting Goals That Matter

Healthcare IT leadership is not always an easy career path - IT itself is a challenging field to work in these days since technology is at the heart of just about every business. When organizations embark on goal setting, IT is often asked to produce more - implement new technologies, upgrade or add applications, interface A to B, and so on. At the same time, IT is asked to produce goals that align with the business. It gets confusing. Should we (in IT) simply respond to business requests (or requirements) or should we develop our own goals? What's the most responsible path? What's the most effective approach?

There's no single answer that fits every scenario. However, here are some guidelines that may help.

Define the Problem

When you are handed a new project request from the organization because someone has requested it as part of some organizational goal, your first step should be to ask what problem the requester is trying to solve. Too often in IT, we are asked to implement a solution. Too often, that solution may not be exactly the right approach. When we try to implement a solution without really understanding the problem we're trying to solve, we are more than likely going to solve the wrong problem or solve nothing at all. In addition to understanding the problem clearly, asking what problem the user is trying to solve may give you the opportunity to better assess what technologies you may already have in place that could solve the problem (vs. buying or building new) as well as help you determine whether your actually NEED technology - chances are high your being asked to throw technology at a process problem.

Once you determine what the problem is and have agreement on the best way to solve it, you can undertake that project as a way to achieve a goal. It may not be an IT goal, but you can adopt it if it makes sense - such as "Improve end user access to all systems by reducing login time by 40%." The problem statement might be "It takes users up to 4 minutes to login to key systems, which causes delays in patient care, lower user productivity and higher user frustration." These are attributes that can be measured so that any solution generated can be measured to ensure it's actually fixing the problem.

Solve the Problem

Sometimes the organization doesn't ask you for a solution, but a problem may be very clear to you and your team. Take the slow user login example. Users may see it and feel the impact, but they may accept it (aka "it's always been slow as a dog, I just login and do something else until it's up.") Your team may see it and determine that if you could reduce login time by 1.5 minutes for every user, you would free up 1.5 hours per user per day. If you have 1,000 users, you'd have 1,500 hours per day of "savings" - pretty compelling. So, you may set as your goal "Reduce login time for all users by 1.5 minutes or more." How you go about doing that will take analysis. It might be process or technology. For example, suppose your Active Directory is a mess or your Group Policy management is non-existent. You may need to clean that up, develop standard work to ensure it remains clean going forward and measure results. That's process related to technology, but you haven't added or changed technology. This alone might improve login times to meet the goal. If not, you might do further analysis to determine login times are worst during shift change but are fine the rest of the time. You might determine that login times to some applications are fast and others are slow.

In other words, you'll need to uncover the root cause and solve the problem and that's a worthy goal even if the organization doesn't ask you to do so. Your jobs as a healthcare IT leader is to find ways to continuously improve the work your team(s) deliver through identifying things that impede the work of the organization or that are simply a waste -- of time, money or other resources.

Create the Future

The last area is, of course, the one we all want to focus on. New technologies, new ways to leverage technology, who doesn't want to create a new, future state? The challenge, of course, is that if (sticking with our example) user login is incredibly slow, it really doesn't matter if you implement a slick new technology. So, be wary of chasing after the new technology if you have fundamental problems to solve in your organization.

That said, even if you have some foundational projects you need to work on, most organizations are looking to IT to help envision the future state. In a conversation the other day with a CNO, I was again reminded of how differently we can sometimes see the world. I was talking about future state capabilities of patient monitoring systems (such as early warning systems) and how that could be interfaced with our wireless voice messaging system. I had drawn some interconnections on the white board to illustrate my thinking. She paused for a moment, stood up, grabbed a marker and drew a completely different picture. In essence, she drew a "tunnel" depicting a nurse's workflow or day and had arrows pointing at various places along the way indicating these were areas where technology intersected with the nurse's job.

I stopped and stared at the picture. She and I had just drawn our view of the world and it was incredibly helpful in understanding how we approach technology. I snapped a picture of the image she had drawn and I redrew it on my own white board in my office as a reminder that THIS is how nursing sees technology (well, one very experienced nurse's view of it anyway).

My takeaway? We can (and should) do research into the current and potential future capabilities of technology. Which systems can natively interface with others? Which ones can share data? Which ones require intermediate systems? Which ones have new capabilities we're not yet using? Which ones have promising futures but we're just not positioned to leverage them yet (and what would it take to get there?). And when we have completed drawing up our world view, we should sit down with our users and listen. We should get out of our offices and go see how the current state works in the world of our users. Armed with our knowledge of systems, technology, current state, constraints, pre-requisites, requirements, etc., we can be extraordinary partners in crafting a better environment for our users - but only if we understand and listen first.

Here's the bottom line: when you're setting goals, whether they are a set of requests from the organization or they are internal objectives you want to achieve,

Make sure that you are solving real problems,

that you're focusing on fundamentals instead of chasing shiny objects, and that you always, always, always understand the views of your customers before you leave the starting gate.