Scope Creep And How To Successfully Manage The Various Forms

Whether you are the project sponsor, project leader, or a member of the development team, increasing the scope of a project can be frustrating. Beyond the initially estimated work, this increase in scope is often called “scope creep.” In many situations, scope creep results in extended timelines and additional financial investment for the project.

Scope Creep: Three Areas To Consider:

Some people see scope creep as an inevitable part of software development to meet users’ needs. Others see scope creep as something that must be rigorously managed to stay on time and budget. There is truth in both perspectives.

This article will explore how to manage changes in scope successfully.

When scope creep should be considered beneficial.

Managing scope creep and when to say "No!"

Questions to consider when changes occur.

Consideration #1
When Scope Creep Should Be Considered Beneficial
Software development is a creative process. It is more of an art than a science. We may think we can identify all requirements upfront and provide accurate estimates based on experience with similar types of work. In most cases, we are fooling ourselves because we are losing sight of the creative nature of software development and the importance of identifying improvements that may not have been visible before beginning the project.
Inevitably changes will happen as the development team works toward the deliverable goals. These may be minor changes, such as a developer finding an easier way to do the work than they had initially anticipated or a few test cases the team didn’t think about when estimating the job.
Changes like this may result in a few hours more or less of work for the development team. If these types of changes infrequently happen during a project, they may have minimal impact on the original timeline, scope, and budget.
However, when we think about scope creep, we often think about significant changes. These significant changes can be items such as the realization that new hardware is needed to support the performance requirements, or the original design that a previous resource may have started is flawed and must be redone.
When something like this occurs, panic can set in, and blame is tossed around. These are the instances when managing the change in scope is critical.
Any time scope changes during a project, consider the following items before labeling it good or bad. Why? Because if the scope creep falls into one of these categories, it should be considered beneficial:

      • When the changes are for the customer’s competitive advantage.
      • When the requirements are adjusted, or new requirements were added, after the working product has been reviewed during development and determined to be necessary.
      • When requirements changed after the customer/business partner had more time to think about the desired functionality.
      • Stakeholders’ changed their mind about the requirements after the initial estimates were provided and did not align with the feasibility study.
The purpose of software development is to create a product for specific customers. If the team or stakeholders discover improvements along the way, then these changes are better addressed before the product is finished.
Consideration #2
Managing scope creep and when to say “No!”
The problem comes when changes are made or requirements added to the existing pile of work and the effects on the budget and timeline are not considered and addressed. This is an example of how scope creep gets a bad reputation.
However, if this happens during development there are ways to manage the situation, that include:

      • Stop and reconfirm your ideal customer for this product.
      • Identify the specific features and functionality needed for you to begin making money with the product. Consider both customer facing functionality and back-end functionality needed to support those features, and tackle them first.
      • Diligently hone this list of features to the bare minimum.
      • Focus on completing the bare minimum features before adding “nice to have” features. Then, once you have your ideal customer using your product and paying you money for it, the “nice to have” features can be added.
      • Revisit and update this list as changes are discovered during the development and testing process.
      • Be willing to say “No” to some requests if they are not needed right away.
      • Always have open communication to present information and address issues immediately when the budget and timeline are impacted.
Saying “No, not right now” to your stakeholder or customer can be difficult. They may have a strong personality or be paying your company lots of money. But saying “Yes” to every new request or change will lead the project astray, and then scope creep is no longer a positive change, and that conversation will be even more difficult.
Consideration #3
Questions To Consider When Changes Occur
If you can’t justify the change in cost, time, or added functionality, then it’s OK to tell the requester, “No, not right now.” Clearly articulate the increased cost of development and testing involved with adding the requested feature. You may find it beneficial to do a cost/benefit analysis if the request requires more justification. The most important takeaway is that the change is identified and communicated to the customer, so there are no surprises later down the road.
To help guide this conversation, here are some questions to consider when changes in requirements or technical aspects occur:

      • What is the cost of this change in both time and money?
      • Is this change worth the cost?
      • What is the cost of delaying this change?
      • Is the product still usable without this change?
      • Will the product still meet the customer needs without this change?
      • Will this change make the project better for the customer in the long run?
      • What feature can be removed from the scope to add in this one, so you remain on time and budget?
      • Does this change make the product more scalable, stable, flexible for future enhancements? If so, how important are those factors right now?

NOTE 1: If you do have to say “No, not right now,” stand firm in that response and add the requested item to the product backlog for future consideration and prioritization. Saying “No” with a solid reason then caving in to pressure to absorb the requested change damages trust between you and the team.

NOTE 2: Consider what will likely happen if the budget and timeline are not adjusted while adding the requested work. In this case, the late decision will likely result in increased stress and frustration for everyone and potentially a product that may not align with the best practices due to time constraints. Giving in to pressure to add in the additional work after you’ve firmly said “No, not right now” also leaves the impression that you can and will change your mind with enough pressure. This can make the team, whether in-house or outsourced, uneasy.

STORY TO CONSIDER: I once worked for a client where I fell into the pattern of saying yes to small requests. During our regular product demos, the client often requested minimal changes. These changes were often only a few hours of work. I almost always said, “Sure, we can make that change”. Before long, I realized I had added days, which turned into weeks, of work for my team. Inadvertently I had trained the client that if they asked for something that seemed small, they would get it right away. I kept telling myself that I was serving the client well because I gave them what they wanted, meeting their product needs. In reality, they didn’t need most of the requested minor changes at that time. Had I instead captured those requests in a backlog and prioritized the backlog with the client, my team would have had been able to stay on schedule and meet the initial budget. While the client liked the small items we kept adding to the product, they did not appreciate us missing our deadlines and exceeding our project budget.


by: Stevie Borne

Scope creep is bad if it’s hidden or if it’s not done for the reasons described in this article. If you find yourself faced with scope creep, be sure it will benefit the customer and that it is imperative to be done now.

Consider if it’s needed to meet the minimum features to make money with the product or if the scope change can happen later. If you determine the scope change can and should wait, let your “No, not right now” answer be firm and backed with data. Then add that item to a backlog for future consideration.

While it’s never easy to have conversations telling a customer or stakeholder that they can’t have a feature right away, delivering a valuable product on time and budget will please them more than if you let the scope get out of control.


Discover All That Intertech Can Do For You!


Stevie Borne

Stevie has over 20 years of software development experience, with most of that being on Agile teams. From her first Agile project, she was hooked on the collaborative, customer-focused approach that enabled her teams to delight customers with incremental, valuable deliverables. After moving on from a developer role, she has held numerous roles, including Product Owner, Scrum Master, Project Manager, Coach, and Development Manager.


“I have had the opportunity to coach hundreds of Agile teams and leaders, from start-ups to Fortune 500 companies worldwide. During these engagements, I’ve guided leaders and team members alike to discover a practical approach to apply Agile values and principles successfully. Mentoring is one of my true passions. ”


Why Did You Choose This Field?

I don’t have a good answer for this….I fell into software development and along the way discovered I enjoy helping clients solve their problems with creative technical solutions while equipping their teams to do their best work.


Stevie is an international speaker, trainer, and professional life coach. She holds numerous Scrum, Agile, and coaching certifications. When not working with her software teams and leaders, you can find Stevie outside hiking, biking, and rock climbing.

Let’s Build Something Great!

Tell us what you need and we’ll get back with you ASAP!