You know them when you see them. Their stance is defiant, their passion palpable. They continue to fight for more and more features, drowning out the realists, chanting, “It will be better for the user!” 

This is the classic behavior of a Scope Creeper with Good Intentions (SCGI).

Maybe you’ve dealt with an SGCI on a recent launch. Or perhaps you are one yourself. SCGIs can come from anywhere, and none of us are immune. As they fight for more features, you imagine the passionate Freddie Mercury singing Queen’s “I Want It All” at the top of his lungs. 

We’ve got you if you need support dealing with an SCGI (or curing yourself). This article describes how to prepare a project and alleviate the need for the SCGI to break into song.

First, let’s acknowledge that IT and software projects have become complex. More applications need to be integrated, and more channels need to work together. A 2020 report from The Standish Group claims only 16% are successful, but large projects are the most at risk. The majority of the time, projects are over cost, over time, and low on functionality. This leaves over 30% of projects classified as failed, abandoned, or flat-out canceled. The reasons for failure are long, but some of the tops are scope creep, poor communication, and unclear goals and objectives.

How many initial planning meetings have you participated in where scope creep comes up continuously? Often, the capability or features being discussed are intended to ensure the customer gets a great experience. It seems as though these should never be out of scope. And truly, these features a SCGI suggests should be considered to ensure the scope was accurate and solves the problem. Many of the people who participate in these planning sessions appear to have ulterior motives and pummel the team with additional requirements. You will always have someone who plays this role but managing their demands as well as the SCGI can be handled with well-defined pre-planning, regular customer testing, and communication.  

Pre-plan using a strong problem statement

Have you ever been part of a project where somewhere in the process, you realize you have a completely different understanding of the objective compared to another person on the project? Or when you look at the requirements that were approved, it doesn’t seem like a solution to any problems?  

You were probably not the only one. Projects are started with such speed and aggressive timelines that this important piece of pre-planning work is often forgotten or omitted.  

So, what does it mean to pre-plan? It means that you take the time before a project launches to ensure you define the problem or opportunity, pre-establish an evaluation method for requirements, and share it broadly.

There are a number of ways to write a problem/opportunity statement. Some key ingredients can include a description of the problem you are trying to solve, the people you are solving it for, and what impact the solution will have. Even better is putting that problem in the customer’s perspective. Include the problem statement at the beginning of every agenda and meeting deck to ensure it is seen and reviewed often. Refer back to it to test requirements to ensure the project remains on track. 

Even with an impeccable problem statement, almost everything in the planning phase is a guess or assumption as to what will be needed, how long it will take, and how to do it. Therefore, in the pre-planning phase, you need a method for evaluating any changes that might arise. There are plenty of options, including forming lists of must-haves, should-haves, and could-haves – or the Eisenhower Matrix.  Whatever method you choose, make sure it is clearly understood and explained to the project team. Knowing that something has to prioritize down a level and fall off the requirements list can cause any SCGI to pause and reconsider.

Though this step is completed early in the project, it should be revisited and re-evaluated throughout. Some of the reasons for re-evaluation may be a result of a user test or other user input. An SCGI will be happy to re-evaluate the requirements when you have more information to help ensure the project is adjusting appropriately to meet customer needs. 

Repeatedly gain customer input  

SCGIs love proof and evidence that customers agree with the proposed solution. You want to avoid being on that list of all the million-dollar projects that failed because the user was never asked if the project had any value to them or solved their problem. 

There are infinite ways to keep a customer involved, such as forming a panel, having a customer representative participate in discovery and design and qualitative and quantitative research. Even if time is restrictive, you can create a rapid test. Not only does this ensure you are actually solving the problem correctly, you validate the project as adding value for your customer. If you can prove you are doing that, the SCGI will have a hard time arguing. And you reduce your chances of having your project added to a running list of failures.

Communicate and empathize

Lastly, another way to ensure the SCGI is happy (as well as stakeholders and other team members) is to be completely transparent with issues, changes, and anything that might arise.  

Remember that everyone has a common goal to see the project succeed. Everyone may have a different motivation, but in the end, everyone is successful when the project succeeds.  

So much in projects is unknown and really just an educated guess.  We need to keep room for graciousness and understanding that what is originally assumed may need to change. As long as everyone is informed and the changes are focused on the customer’s best interest, some of the SCGI impacts on the project will be mitigated.

To all the SCGIs out there, remember that your team is trying their best, and even if your ideas are backlogged today, they may be re-evaluated tomorrow. Hopefully, project success statistics will improve as we create greater value for our customers without having an annoying SCGI on the project.