Curbside Consult with Dr. Jayne 11/13/23

One of my professional organizations has a forum for members to help us stay connected about hot topics. I got my chuckle of the day when one member referred to scope creep on federal information blocking rules by saying the content “has now metastasized” to a document that’s nearly 80 pages.

I’ve been in the consulting world for so long that I assume that scope creep will be part of nearly every project. However, when you think of scope creep in terms of being a cancerous growth, it reminds you just how insidious it can be. For those of us who have been around the informatics block for a while and have some implementations under our belt, we understand the phenomenon.

Sometimes scope creep happens because the initial project scoping wasn’t done properly. The “creep” represents efforts to try to get features or requirements added to the project that should have been there in the first place.

How did they get missed, you ask? In my experience, it tends to be combination of factors. Sometimes the right shareholders aren’t at the table when the project is being defined. I’ve seen that happen plenty of times when IT folks are tapped to run what are essentially clinical or operational projects. I think that organizations are getting better at this, however, forming dyads or triads of leaders to ensure that projects have the right people at the helm to deliver results.

You have to be careful with this approach, though, since the old adage of “too many cooks in the kitchen” can easily happen in healthcare technology projects. Having unclear leadership can also lead to problems with prioritization of work efforts and challenges when there are identified barriers that need to be addressed. I’m personally a big fan of formal project management documents that spell out the who, what, when, where, why, and how of a project. It’s essential to capture the goals of the project, expected outcomes, and the change control process if you want to avoid messes later. When you don’t have that kind of documentation, it’s easier for people to claim something was in scope when it wasn’t, or to claim that the project team didn’t deliver when the expectations weren’t well documented.

One of my favorite ways to combat scope creep is to make sure that project deliverables are tied to specific budget items, and that all of those items roll up into the master budget so that everyone can have clarity on how much a project is costing and where the money is coming from. This requires that the project includes people who have solid skills at estimating work accurately and who have a good understanding of their teams’ productivity. I’ve worked with managers who claim a project will be an 80-hour build when it really takes less than 10, which does the project a disservice. Conversely, people who underestimate the complexity of a task or who underestimate their teams’ ability to deliver can create havoc on a massive scale.

Even when a project is properly scoped and estimated, having strong documentation of these estimates and costs makes things easier to manage later when people ask for additions to the project. I’ve been known to ask them to estimate the work effort for their proposed addition, then hand them the budget and timeline documentation and ask them what they propose to alter in order to make their request a reality. Does your department want to pony up the money for us to hire contractors to build the additional content you didn’t mention during the original scoping meetings? Or do you want to give up some other content in exchange for what you now realize is a must-have? Those aren’t fun conversations by any means, but people tend to take them less personally when there’s data in front of them than when it’s just the CMIO telling them no.

There is always going to be a certain amount of scope creep on a project, and usually I see that when the team uncovers an element that they weren’t expecting, or a key element of the project doesn’t work as planned. For example, on a big EHR project I was brought into when there was a lot of leadership infighting, we discovered that laboratory interfaces had been deliberately excluded from the scope due to budget constraints. It’s ridiculous to try to do an inpatient EHR project without laboratories, so we had to add them in, of course after educating the steering committee why they shouldn’t have allowed them to be excluded in the first place. That’s a bigger miss than you typically see on a project like that, but a good example of why at least some percentage of contingency overhead should be included in every project.

When there’s an excessive amount of scope creep, or when organizational politics become too big of a distraction for the project team, I’ve been known to suggest that the project be put on hold while it is re-scoped. Sometimes that approach is the proverbial shot across the bow that people need to get their attention, or to get them to understand how big of a concern it is to handle requests for changes to a project that’s already in flight. Especially in organizations where there are dozens of projects running in parallel, it’s understandable that people might be having trouble keeping track of which elements are part of a given project and which might be included as a separate but parallel effort.

That illustrates why communication plans are so important, so that it’s easier for people to understand what is in our out of scope or to find the information if they generally don’t know. Making sure people understand project timelines and budgets is a key part of this. I’ve found it’s harder for people to ask that new requirements be added to the scope when they can clearly see that the project calendar is running in a yellow/orange status, or that the budget is squarely in the red zone. Sometimes the people who ask for additions aren’t in the weeds with a project, and being able to quickly show them where things stand is key.

I’m working with some relatively new clinical informaticists who are honestly some of the smartest people I’ve ever met. However, most of them don’t have a tremendous amount of experience in project management or the sausage-making that happens when you try to bring a new project live with actual healthcare organizations. I’m trying to teach them as much as I can about the behind-the-scenes work that makes the difference between a project that feels like a slog and one that just flows. Some of that you just have to learn through experience, though, and I don’t envy them the knocks that they’ll undoubtedly take as they move forward in their careers. There’s a certain level of “been there, done that” that we all have to reach, but I’m glad I can help them when the going gets tough.

What’s the worst scope creep you’ve ever seen in a project? Leave a comment or email me.

Email Dr. Jayne.