Implementation vs. Transformation

The concept of a “project” has been hammered hard into business. We have project plans, project managers, PMO’s, project tracking meetings, project status reports, project budgets, project resources, etc. There are more to projects, of course, but the odds are that you  have already had the opportunity to be directly involved with at least one of those project-related items. In fact, most of us have spent plenty of time working on projects.

Projects in healthcare are usually one of three kinds: patient care projects, construction projects, and system projects. Most hospitals have at least one of each of these types of projects going on at any given point in time, and often multiple projects in each category!

Patient care projects are special in a hospital, because of the universal focus that they receive from leadership and staff and because they can take on so many different looks – subjects like how a specific type of care is to be performed, improvements to code responses, or even instrument placement optimizations. Ultimately these projects are usually focused on taking some behavioral action and improving it. They are people-centric.

Construction and system projects, though, are not quite like that. They are not so much about people as they are about “things” – buildings or computer systems. And usually they involve putting in new “things,” upgrading “things,” or replacing old “things” with new “things.” (And you can substitute “buildings” or “computer systems” for “things” as appropriate for the project!) To contrast them with the patient care projects, these two categories of projects are thing-centric. And no, that’s not a word, but you get the idea…

Thing-centric projects require something known as a capital budget. If you are familiar with capital budgets, you can skip to the next paragraph. For the rest of us, a simple definition in context of healthcare projects is: A lump of money set aside to get new things or improve/replace existing things that does not come out of the day-to-day budget because it is BIG and is a one-time expense. The day-to-day budget is an operational budget and that’s where you plan for the expenses that happen on a regular basis.

So why is this important? Well, when it comes to a scheduling implementation, what type of project is it?

The popular thought is that it is a systems project and requires a capital budget to implement the scheduling system software. (Thus we use the term “implementation.”) Consequently, all of the project justification and preliminary work – approvals, planning, resourcing, involvement, etc. – are approached like any other systems project. The timeline revolves around the capital budget and project completion is determined when the implementation of the system is complete.

Does that sound familiar?

Here is the problem with that line of thinking: Scheduling implementations are people-centric. Sure, you may be implementing a scheduling system and have a capital budget, etc., but the goal of a scheduling implementation is more than rolling out a new software package. It is to create processes that enable your managers to balance labor productivity and give them a tool to execute those processes. In August, we talked about how a scheduling system should be the operational heartbeat of hospital. That means the focus of the implementation is behavioral and the scope should include transforming scheduling processes. The system rollout is just there to support the transformation.

We use the term “implementation” a lot, because we know the project involves implementing software. But in reality, what we are doing is more than implementing. We are transforming. We are introducing change that is specifically designed to make scheduling processes better, which affect patient care and labor costs.

The practical application of this terminology clarification is that we need to not treat our project as a systems project only. It needs to include aspects of a patient care project. And in a hospital, that gives a whole different level of focus and attention, as it should. For the scheduling implementation, it means that:

• It requires ownership from those providing direct patient care, not just the business units.

• It is not over when the system implementation is complete. The change is permanent and should be designed for continuous, on-going improvements.

During this roadmap series, we will continue to refer to the project as a scheduling “implementation,” because we know that you are reading this because you are interested in or have already implemented scheduling software. But when it comes to how your implementation is positioned internally within your hospital system, think in terms of a “transformation.” It will better convey the scope of the change and put you in a position to bring about the right kind of change and not just changing the system.