In 2018, more than 50 percent of the projects completed by 5,400 project managers experienced scope creep, according to a report from the Project Management Institute.
As projects change, scope creep can be created by team members, stakeholders and even users, who unexpectedly — or intentionally — expand a project’s scope. But tech professionals across Colorado say that scope creep can be managed, and even accounted for, when teams plan effectively.
“One of the most common reasons for scope creep is working on an initiative that’s not fully fleshed out during the design, planning or delivery process,” GigSmart VP of Engineering Chris Downard said.
That planning can take the form of story-grooming sessions where the dev team ensures that engineers are in alignment long before any code is written, or weekly roadmapping sessions with stakeholders across the business.
Developers at PAIRIN regularly meet with a project’s stakeholders during the development stage to prevent unwanted scope creep by ensuring every party is fully aligned. Product Director Jacob Shanesy said his team leaves some wiggle room in their production timeline to address additional features.
But when unexpected challenges arise, it’s critical to flag an issue early and correct it quickly. To keep projects on track, Stephen Smith, software development manager at Procare Software, said his team pulls devs from lower priority features to collectively tackle the extra work.
Downard said feature production teams should only allow scope creep if the new development work will tangibly enhance a project’s outcome. Teams should communicate proactively about managing scope creep, and features that aren’t vital likely don’t require immediate attention and can be addressed at a later time.
What proactive measures does your team take to limit or prevent scope creep?
We fully vet, plan and discuss features and initiatives prior to development. Our features go through a robust process prior to writing the first line of code. The process includes creating detailed wireframes, conducting market research, creating prototypes for usability testing and rolling out feature introductions with the product delivery team. We conduct architecture reviews and host multiple meetings with the development team delivering the feature. All these processes ensure we have planned to the best of our abilities. We see one of the most common reasons for scope creep is working on an initiative that’s not fully fleshed out during the design, planning or delivery process.
Consistent and quick releases also reduce the temptation of scope creep.”
When scope creep does occur, how does your team handle it?
When scope creep occurs, the first thing we do is stop and acknowledge that we are introducing scope creep into the initiative. This awareness leads to discussing the necessity of the scope creep. If deemed necessary, target delivery dates are revised and communicated.
If target delivery dates cannot be adjusted, then the team discusses ways we can potentially reduce scope in other areas of the project. We review options for parallelization of effort and look into whether there are additional team members we can pull onto the project to keep it on track.
What advice do you have for developers looking to better manage scope creep?
Try not to panic or get upset when scope creep happens. It’s not always the product team’s fault, and shared ownership and early feedback reduce its impact. Potential impact to a project will be lessened if a developer with concerns about a feature voices them early.
Scope creep should arise out of necessity, not from forcing more features into an initiative. If we have to add scope to have a more positive delivery outcome, then it should be added. But if scope is being added because something is a “nice-to-have,” then it can, and should, wait.
Consistent and quick releases also reduce the temptation of scope creep. Releasing features whenever they’re ready reduces pressure, which ultimately leads to more on-time releases.
Start with the basics. Shanesy works closely with developers and stakeholders early on to map a project’s most essential features. If planning goes well, the fundamentals are often all that’s necessary for delivery.
What proactive measures does your team take to limit or prevent scope creep?
We have many strategies to ensure scope creep doesn’t become an issue, like delivering in rapid iterations, defining phases upfront and having a clear system for stakeholders to track when requests will be addressed and put into the roadmap. Our stakeholders include our clients and teams such as customer success, marketing, leadership, engineering, design and product. We also have a weekly roadmap meeting that ensures everyone knows what is and, maybe more importantly, what isn’t included in each release.
Facilitate consistent, clear and concise communication between stakeholders and developers.”
When scope creep does occur, how does your team handle it?
At the beginning of each project, we clearly identify the development phases and seek to understand the user’s needs, which can differ from those of the individuals paying the invoices. This understanding allows the team to make decisions centered around data. Typically, we build a bare-bones first iteration, and more often than not, we find that we don’t need to add a ton more for our stakeholders to realize value.
What advice do you have for developers looking to better manage scope creep?
Scope creep is the result of mismatched communication between your development team and stakeholders. As a product manager, I find it key to facilitate consistent, clear and concise communication between stakeholders and developers. Additionally, working at an early-stage growth company, it’s important to architect and design with a sense of flexibility. When things are built correctly, we find that features and requests that normally could be considered scope creep are actually fairly easy problems to solve because we built for flexibility from the start.
Urgency is a key part of product development, especially when applied to managing scope creep. When unexpected work presents itself that might delay production, Smith and his team meet to discuss an immediate plan of attack. Occasionally, that plan requires a joint development effort in which engineers work in tandem to hit deadlines.
What proactive measures does your team take to limit or prevent scope creep?
Scope creep affects us the most when it’s unclear what the scope of a story is. Or when a developer wants to develop the story a certain way without buy-in from the rest of the team. So we have story-grooming sessions early where the dev team analyzes a story and plans out what it would take to complete it. We won’t move on until the team is comfortable with what needs to be done and how it will be accomplished. Sessions involve dev team members as well as the product owner to provide product clarity.
Communication is the key to managing scope creep issues as they come up.”
When scope creep does occur, how does your team handle it?
Even if early planning and estimation are done correctly, scope creep can still happen when running into unexpected things in the code or if priorities change mid-stream. In this case, we immediately talk about it as a team and start working around the issue. People working on a lower priority feature may pause their work and swarm on the item that is unexpectedly taking more time.
What advice do you have for developers looking to better manage scope creep?
Communication is the key to managing scope creep issues as they come up. It’s vital to immediately talk to the team if something is starting to take longer than was planned or if more work is necessary to accomplish a task. People can be stopped from going down rabbit holes if there’s good communication, and they can be pulled up before they get too deep.
