One of the first lessons I learned in business was never assume. This is great advice at any level of your career, but as I moved into management and helping oversee large IT projects and product development, I quickly learned how false assumptions are a leading cause of scope creep. And scope creep can be the death knoll for a project, especially large, complicated projects and technology deployments like software applications.

“Assumption is the mother of all screw-ups.”                                                                      (Wethern’s Law of Suspended Judgement) – Paul Duvall

And while product changes are not always a bad thing, especially if the team agrees that the changes beyond scope are the right ones for the right reasons, scope creep is still a leading cause of project failure. If it happens and you and your technology partner don’t manage it effectively, your profit, competitive edge and reputation will be at-risk. We know you’re busy running a business and that’s why you may someday choose to outsource technology design and development work. Consider this a simple need-to-know about what scope creep is, what causes it, and the impacts scope creep can have upon your project - so you can be more control of your project and product’s success.

What is Scope Creep?

It's when a team agrees to build a piece of software of a set scope for a certain investment in a given timeframe, and then after the project has started, new requirements and features are added that change the investment or timeframe.

“Add little to little and there will be a big pile.” - Ovid

It happens.

Because scope creep can put your project at-risk, I recommend thinking of any increase in project scope as a business decision, one where where considerations of cost, risk, schedule and market or business implications must be weighed, so it’s important to understand what it is and is not, along with the common causes.

How Do You Know It’s Scope Creep or a Reasonable Occurrence in Agile Development?

It IS Scope Creep If...

It's Not Scope Creep If...

...you want to swap new work for work already completed.

..it doesn’t create additional work for anyone.

...you want to replace something small with something big.

...it’s something that’s easily adapted into scope (in an agile project) without changing the time or investment.

...you want to add something entirely new that changes the time or investment.

...it doesn’t change the time or investment.


What Causes Scope Creep?

While there can be many causes of scope creep in software product development, here are my top five:

1. People

  • Weak or inexperienced project management leadership.
    • We recruit leaders with the right attitude and skill sets to manage the complexity of software development. We've previously written about these “T-shaped” leaders who provide a broad base of business and technical requirements knowledge to more effectively estimate and negotiate projects to mitigate scope creep from the get-go.
  • Allowing an “I’ll Know It When I See It” arrangement.
    • A business leader/product owner who doesn’t really understand his/her market, what she wants or how to get there. If a business leader only provides a vague idea of what they want, it will adversely impact the project.

2. Process

  • Not properly identifying and fully understanding the product’s users.
  • Lacking a process for managing changes.
    • We utilize an agile development process which includes backlog grooming meetings to break down and reprioritize all open items (both bugs and features) so the work and workflow are carefully managed. While you may not be running a similar process, it’s important to understand the importance of this ongoing step to your product’s success.

3. Assumption

  • Assuming both parties fully understand the details of the project, including business and technical goals from the beginning.
    • Not conducting a thorough discovery process can lead to poor requirements analysis and underestimating the complexity of a project. This is why our discovery process includes current and future state architecture, design and user research, product planning and project planning.
  • Assuming the customer understands every aspect of the detailed technical requirements and specs we’re building toward.
    • Since software development is inherently filled with technical language and jargon, we break down every aspect of the documentation and explain what each means. The last thing we want is a customer who is surprised when the first product milestone is revealed. 

“Tell me and I’ll forget, show me and I may remember, involve me and I’ll understand.”                 – Chinese Proverb

4. Poor Communication

  • Not having a formalized communication process.
    • Upfront, we work with the customer to determine the best way to work together, then we agree upon and ground rules on communication. We designate a customer point of contact for questions and agree to a timeframe in which answers must come. Finally, we agree to the consequences which include stopping work so we’re not burning time (and wasting the customer’s money, as a result).
  • Keeping the customer in the dark.
    • It’s not acceptable practice to meet at the beginning, create the 2,000 page document and go away for nine months developing. Our approach is to build software in iterative, small deliverables, then show the customer what we’ve built every two weeks. This includes constant communication during each sprint and leading up to the completion of each sprint. Especially with customers new to the software development process, we may be talking to the customer every other day to review features, review priorities and ensure both parties are on same page.

5. Accountability

  • Not owning the issue early-on.
    • When there is a possibility scope changes, we are upfront with the customer and transparent about the ramifications.
  • Being afraid to stop and reset to realign.
    • Sometimes, it just needs to happen. Otherwise, you risk missing milestones and wearing down both development team and customer.

What Can Be the Impact?

By now, you’ve probably realized that developing software can be challenging and risky but it doesn’t have to be painful, especially when bumps in the road occur. However, should you make the business decision to increase or make significant changes to the scope of a project, here are a few potential impacts to know going in:

  • Your product risks missing delivery date and market window, potentially impacting your competitive edge. Market timing is key to business these days.
  • Your product costs may rise. Time is money, and more unplanned development time costs money.
  • You can lose credibility. For the reasons above, every time there’s a large change, you are potentially impacting your commitments to your employer, investors, users and/or customers.
  • You wear down the design and development team. Change can be hard. It’s hard to build something and then throw it away. Imagine you are designing a house and you change the layout after the foundation is poured. There is now two weeks of jackhammer time and re-pouring the slab. The same thing happens in a software project, but it’s just harder to see the impact.

While choosing the right design and development partner is half the battle, there’s no question that you as a business leader play a critical role in reducing or eliminating the chance that scope creep will occur in your software development projects. Keeping scope changes to a minimum will help ensure that your commitments are maintained and your product hits the mark.

To learn more about how we approach problem-solving for our customers, including our software development process, click the image below.

Get Farther Faster with a free copy of our Guide to New Product Development Process for Software

 

Be in the know.

Sign up for updates.

The photo used in this post, "Perito Moreno glacier" by Matito, is licensed under (CC BY-SA 2.0)

Click to Comment