The term “scope creep” is often used in business and we all know what it is, but do we really? In my experience leading various process improvement activities or new project management initiatives, I have come across at least three different problems that are often grouped together and classified as “scope creep.” I want to discuss a different concept that I call “solution creep” as a way to rethink these distinct problems and give some insight on how your can prevent your solution from creeping.

# Scope Creep

I look at scope creep as when you have defined a problem, but have either not defined the parameters of solving it or you have not defined the parameters of the problem itself. Let’s briefly describe how these two are different before jumping into the idea of solution creep.

## Solution Parameters

With unlimited time and money, there are infinite ways to solve a problem, so to prevent having a never-ending project, you must define what your solution should and should not include. Carl Sagan once said, “If you wish to make an apple pie from scratch, you must first invent the universe.” Think of solution parameters as a way to prevent your solution including inventing the universe! An inadequate solution scope is bad because people spin their wheels finding the “perfect solution” or they get stuck in “analysis paralysis” evaluating the potential solutions.

## Problem Parameters

Problem parameters, on the other hand, do not really matter how the solution is scoped. You can have problem parameters with small or large solution parameters. What a problem parameter does is keeps more than one problem from being solved as part of the selected solution. I like to think of an example of a new piece of legislation being developed. One legislator has a problem they want to solve so they write-up a bill. In order to get more people to back their bill, they include some other items to solve other law makers’ problems so they will vote for it. So the scope of solving the original problem has not changed, it’s just the “solution” (the final bill or law) solves multiple problems now. This is not always bad, but sometimes it delays solving the original problem because you are trying to solve too many problems at once.

# Solution Creep

Now let’s talk about the third thing that I see during projects: solution creep. Solution creep occurs when you have an inadequately defined problem so your solution ends up solving a different problem then originally planned. Yes, you are solving a problem, but not the intended problem. So why is this a problem? At least you are solving problems, right? Well, not really. If the problem you ended up solving doesn’t move the business forward the same amount that would have if you solved the original problem, then you may have just wasted a lot of time and energy. This time and energy could have been used to solve another problem that might have been more important to the business than the one that ended up getting solved after “solution creeping.”

So let’s talk about how this happens. Most of the time this happens because the *perceived problem *is not fully or clearly defined. This means that you have a group of people working together with their own perceptions of the problem. As the group works through the problem, the solution is moving because the problem is not defined and therefore is moving also. Sometimes you may not even realize this has happened because you never defined the problem initially to compare the final solution to the defined problem. In my experience, people figure out they experienced solution creep because after all is said and done, they realize the problem still exists and they get frustrated figuring out why their solution “didn’t work.” The thing is, the solution probably *did* work…for a different problem, which you hadn’t defined!

Unfortunately some people mistake solution creep for continuous improvement. There is this false mentality that as long as you are solving problems, you are doing right for the business, but that is not true. Sometimes in these scenarios when you are working on a process improvement initiative, someone determines a proposed solution is not feasible (time or money constraints usually) so another “solution” is evaluated which takes the team down a new path. Even though this sounds like scope creep, if is not if the path you go down doesn’t solve the initial problem. If the new path solves a different problem, although maybe a similar or related problem, you just experienced solution creep.

# So What is Really the Difference?

With both forms of scope creep, you still end up solving the original problem, you just may have also solved additional problems with it or you may have solved the original problem in a less efficient way or more costly way. This is not the worst thing in the world if the solution to the original problem is solved and really does drive the business forward. Maybe next time the group could just be a little more effective with a better defined scope that way you get to your solutions faster and cheaper.

Solution creep though is dangerous because the original problem is not solved. With solution creep, *a problem *is still solved so people feel accomplished, but they may not have helped the business in the same way than if they had solved the original problem. Additionally, the business or customers may still be frustrated that the original problem still exists.

# What Can You do to Prevent Solution Creep?

I think there are three key remedies to the solution creep problem.

- Ensure you have a written, well-defined problem from the beginning of your project that everyone on the team, and
*especially your customer,*agrees to. The key is*written;*never inferred or assumed. - Take several time-outs throughout your initiative to compare the proposed solutions to the
*written*problem statement. This is critical to make sure the group isn’t accidentally (or purposefully, if an individual has a hidden agenda), solving a different problem. - If you are a leader, do not just measure process improvement initiatives. I’ve seen department leaders who have had yearly competitions for “number of process improvements implemented.” Such a measure creates
*major*solution creep in those departments because it was about quantity and not quality of the effort.

Always question yourself and others to make sure you are solving the original problem because fundamentally that is why the team was assembled in the first place. In future posts I will go into some deep dives about problem definition as it is paramount to solving any problem and preventing solution creep.

What do you think? Have you experienced solution creep and how have you prevented solving the wrong problem?

Very well articulated

LikeLike

Thank you very much for the feedback, it helps me in my future articles!

LikeLike