This article is initially available on our podcast. Click here to listen.

Scope creep can come into any software development. Scope creep depicts what you’re trying to accomplish in a project or a development and defines the boundaries for that so that you’re not boiling the entire ocean.

Scope creep describes unanticipated scenarios

For instance, if you’re working on your house, you might say, “Okay, the scope of this is we’re going to redo the bathroom.” Suddenly, you find yourself in a situation where you’re ripping out the plumbing in your bathroom, and you realize, “Well, the plumbing throughout the entire house is bad because it’s got old lead pipe or something.” Without warning, you’re trying to replace the plumbing throughout the entire house. That’s scope creep. That’s outside of the original scope of what you had specified or intended.

In software, this happens all the time in part because so many things spiderweb everywhere else. In that example, in the bathroom concerning a home rehab, you’ve got electrical running through that unit. You’ve got plumbing that runs throughout the house. Maybe, you’ve got flooring in the bathroom that runs across the doorway or something like that. So if you try to rip up the floor in the bathroom, abruptly you’ve got to do the hallway and everywhere else also.

Those types of things can happen in software as well. We recently ran into this with a client where we were implementing charge reconciliation. See our other podcasts about what charge reconciliation is in more detail. The short version is that charge reconciliation checks whether or not everything in the clinical system got entered into the billing system. Then ideally, “Is it all correct?,” “Did it get billed?” and so on. But, at the root, it’s just, “Did everything get entered? Did everything get across?”

This is so essential because, even if you have an interface, it doesn’t mean that everything made it across and into the billing system. Inevitably, something is not in there. Pretty much always. It’s just a question of what the quantity is and the percentage.

Review your requirements and your systems

After working with the client, we wrote up a specifications document to review their needs, what systems they’re using, what files, the fields, the structures, all these kinds of things, and mapped everything out. We put together a requirements document, send it off to the client. The client signed off on those requirements. It said, “Okay, this is what we’re going to bill. Anything other than this is not within scope.” It was really to identify missing records.

As we started to bill that, it became evident as we dove into the data. Before we even started billing, we began to see, “Ah, there are some issues where we’re not going to be able to look at missing. We’re going first to have to do things like look at whether or not there are duplicates.” If we have duplicates come over, then copies are defined. In this case, there are many different types of duplicates. 

Further, we’re talking about where a duplicate record is in the clinical system, where they enter the same patient visit twice. It’s not just in there twice, but some critical piece of information is different about the record. To illustrate, they enter a visit number or the patient number of the same patient with two different medical record numbers. So when that patient comes in, it gets double booked effectively.

Too many duplicate entries to manage effectively

We realized that we would have some false positives on the missing list because we hadn’t checked for duplicates. Suddenly, we have to add duplicates, and we have to run an analysis. The replication starts getting very complex because there are many records for the same patient encounter in the clinical system that are essentially duplicative to each other. 

In addition, we found that they ordered the same test multiple times for the same patient on the same data service. Numerous records exist for the same test with different order numbers in the system, including different encounter numbers in the system.

What you would typically expect to use is a unique key, something like the encounter number. We could not use it. We had to create a compound key using data service, patient ID, or medical record number and the charges, the CPT codes. Then, as we further got into it, we had to keep revising the specification, revising requirements, and we kept going until we found, “Okay, we’re going to have to look at changed records now.” 

What we found was that multiple tests were getting ordered. They weren’t changing from the original. New orders from the same data service bring complexity to explain until you dive into the data.

The more we dove into it, the more we realized, “Oh, okay, we’re not going to be able to accomplish the original.” It’s not even that, “Oh, we want a different floor in the bathroom as the lights won’t turn on. Nothing will function in the bathroom if we don’t go and rip up all the wiring in the entire house, essentially go and replace the junction box outside or something equivalent.”

Compounding issues

We found ourselves having scope creep after scope creep. Again, the client was very receptive and understanding because we weren’t going to accomplish the original objective without going through a detailed process. So we had to go through multiple rounds of revisions of the requirements document, and each time they signed off on it. As a result, we were doing way more than anticipated in this project.

Watch out for scope creep! The only natural way to essentially avoid this is to spend much time on the front end, where you dive in and effectively dig into the data and start piloting some things. Unquestionably, there’s no way to figure it all out until you get through because you can’t see the exceptions that come through until you run the analysis.

That’s really the issue we run into often, which is, even if you understand the structure, even if you’ve gone and spent much time in the client data, you’ve built out a pretty detailed 4, 5, and 6-page requirements document for a relatively small project, even then until you get the output and see, “Ah, the output that pops out of the analysis is wrong” or “Hey, here are these exceptions that kind of break the rule,” that frequently comes up and you need to prepare for those types of things and adapt to them. 

In summary

It would help if you said, “Okay, we’re going to deal with that at some later stage. We’re either going to ignore those and say, “Okay, it’s not a big problem. We don’t have to worry about it” or maybe quarantine those and say, “Hey, those will go off into a separate category, and someone will address those later.” On the other hand,  you can put it into phase 2 requirements, or you can deal with it upfront and expand the project and say, “Okay, it’s going to be a little more expensive than anticipated, but we’re going to address all of that now.”

Be prepared for scope creep! It’s part of life, unfortunately.