DEV Community

Dvir Segal
Dvir Segal

Posted on • Originally published at Medium on

How to deal with the kitchen sink syndrome

Photo by Scott Umstattd on Unsplash

But I’m a (scope) creep…what the hell am I doin’ here?

Here is a situation that I am pretty sure every team or individual contributor has encountered throughout his career. You get well-defined requirements, review them, ask questions, adjust them with your product owner, and prepared one heck of SW design. Soon after, the implementation phase begins, and a few hours or days before the end of the story, the business calls and asks for an extra feature (or change) to be implemented. WHAT?!

Why now? — src

Usually, the project manager\product owner is responsible for filtering out these requests as “must-haves” or “nice to have”, but there are cases where the business wants to squeeze all these features into a release. This is the case of scope creep  — or the kitchen sink syndrome .

Its roots come from poor change control, lack of proper initial project objectives, weak project management, poor communication, and lack of initial product versatility. This situation is a risk in most projects, often results in unexpected incurred costs (budget overrun), and has a significant effect on the team’s motivation, on the project’s timeline by introducing complex change late in the release plan and enforcing retest on impacted areas too.

How to manage it?

“It is impossible to control scope creep, so always work on the highest-priority features.” (Bleiweiss, A., Bupp, J., Johnson, D., Meister, J., Murphy, B., Temchin, M., & Oldfield, P, 2009)

Now that been said, other activities that can be done:

Try to establish a change request process before the project begins. Say something to the effect of “Here’s what we’re going to deliver. If you want something else added, you can write it down, submit it, then we’ll figure out how much it’ll cost you, and you can decide whether you really want it.”

Ensure everyone understands the “cost” of requesting additional changes after committing to initial work. For each request, provide (every time) a revised due date, cost in time estimation, and what is going to be delayed\dropped to squeeze this latest request. Making sure that this request has consequences is fundamentally the way to go. The motif is to do more by doing less.

Please add more features — src

Invest in requirements gathering , be sure to ask questions, raise any concerns and try to address them with all stakeholders reaching well-defined requirements. Keep in mind that you should be flexible for changes, knowing that many unknowns can be found along the way.

For addressing weak project management, get them highly involved. Define project scope with them, provide regular communication. It might be a short mail summarizing what’s done this week or a weekly check-in meeting. Share with them just enough information to empower them to take decisions, but not so much that they are overwhelmed.

Can you add a few changes — src

As for communication, I’ve written a post about it in the past. Everyone working on the project must be on the same page. Expectations and the work that needs to be done must be articulated clearly to have a mutual understanding of responsibilities, boundaries, and timelines.

Use tools to manage the project’s schedule, needs, and documented requirements. It allows each task to be clearly defined, prioritized, and assigned. To keep track, define a check-in meeting on the cadence that meets the team’s preferences. It is excellent for keeping track of things, remind people that they are part of a team with a shared vision that supports each other.

To wrap it up

A healthy respect for boundaries and clear communication are a few of the things you and your team need upfront to avoid scope creep. Making these priorities upfront will save you a lot of time, energy, money, and stomach aches along the way.

Top comments (2)

lifelongthinker profile image

Yep, exactly! This sums it up nicely. EVERY decision in software dev is a trade-off. Managing expectations is the way to go.

Clients cannot and do not understand what feature or change requests mean for a given project timeline. They have to be made aware of the consequences. Not everything is doable. Every advantage comes at the price of a disadvantage.

There are no free feature/change requests, least of all in the final stage of a project.

dejavo profile image
Dvir Segal

Thank you for your feedback and for sharing your insights!