Managing Scope Creep – 3 Warning Signs and Solutions

Several products I’ve managed over the years have run into a very common problem. The end result exceeded the intended design goals agreed upon at inception. “Scope creep” made its way into the product development process and, as time went by, we got a different outcome.

Scope creep is common, especially in ventures seeking to disrupt the market, because suddenly every feature under the sun is necessary to drive the disruption. DO NOT let this happen to your venture! The impact on an ever-increasing set of requirements or features has on the team working on the product can be devastating. Worse yet, it can negatively impact your entire venture.

Here are 3 early warning signs that your product efforts may be heading toward scope creep and how you can nip it in the bud.

1. The Never-Ending Design Phase  

Products are typically designed and specifications are identified during the Design Phase early on in the venture. When this design phase goes beyond a pre-defined period of time, this can result in scope creep.

The rationale here is simple, when you look at it from a distance. If the design phase is extended this allows more time for discovery and analysis. The newly elongated discovery phase often leads to additional areas of improvement and enhancements for the product based on the very righteous point of view of making the product better for customers and users, which is exactly what a design phase is intended to do.

However, when a design phase extends much beyond 20% of a products development cycle, then your product development process may be headed for disaster. In general, the more time designers get to look at a problem, they more problems they will come up with to solve related to your product.

Anything and everything taken to excess is toxic. The same is true for the design or specification phase of your product development lifecycle. The way to address this challenge is fairly straightforward but not painless. It requires getting all of the key stakeholders together —  the product owner, the venture leader or their direct reports — to reiterate the product design goals, guide rails and criteria for the whole team. I recommend that you provide pre-reading ahead of your meeting if these are lengthy.

When they leave the room, the team will need to agree to bring to an end the design phase of the product. Walk through all of the items on the list for implementation and make the hard call of what needs to come off the plate to get the product out the door. Finally, and most importantly is to drive the program towards a final sign-off on all of the design elements of the product.

I’ve often found that getting an actual physical sign-off in live ink at the meeting by circulating the final design document – much like a contract – is a great way to get this resolved once and for all. This sign-off on the design phase requirements ensures that the product team is aligned and focused on a common, agreed-upon result.

2. The Regularly-Moving Launch Date

Products under development and the teams driving them need to be date or goal driven. One common form of scope creep occurs when a product’s dates keep moving. Often the reasoning and rationale for these product delays can be explained when the macro-economic (big picture) factors for the venture are taken into consideration; for example, it’s not the right time to launch the product.

However, from the product development team’s perspective, these factors be damned, their date moved! These changes have a negative psychological impact on the team that is gearing up for a launch. Often the perception is that they should be happy because now have more time and aren’t so rushed.

But actually, here’s what happens. Every product group I’ve worked with elevates its game to the highest level possible towards the end of a product development cycle to ensure that they get everything right, at the right time, and with the right features. Moving the product ship date is like having the rug ripped out from under them.

That being said, sometimes the need to change dates arises, regardless of best intentions and efforts, due to external factors. When this happens, this is the best way to address it. Begin by gathering all of the necessary scheduling information and identify the new firm and immovable launch date. It’s very important to gather evidence to support your decision so that the team will have confidence in this new date. You need to sell the product team on the new and final product timeline.

Even with your best effort, the team may face this new “final” product launch date with a certain amount of skepticism. It is important to discuss the factors that caused the launch date to slip, so that the team can understands “how we got here” and “why this is the new launch date”.

A final word of caution on this front — much like the little boy who cried wolf, you cannot change the date more often than once or twice, or you will lose your credibility and the support of your product team.

3. The Last-Minute Requests… That Just Keep Coming

Most products have a defined set of specifications, a time-frame and a resource allocation for their completion. However, market dynamics or changing venture needs that often arise between the start of product development and completion can produce an insidious form of scope creep — the last minute change request. These can be as simple as a color palette change, actually not as simple as it sounds, to a more complex complete overhaul of a section of the product or a user experience.

No matter how well you plan your product development efforts it’s almost impossible to avoid this scenario. The key to solving this type of scope creep is to manage and “box” it in effectively so that it doesn’t massively disrupt your overall product launch efforts. Begin by pulling together all of the key stakeholders agitating for this change or affected by it.

During this meeting, hammer the suggested change out to the point where it is an unmovable, unambiguous, highly-detailed request, and ensure that it will be the last request from these stakeholders (which it may not eventually be) to give you credibility with your product development team. This agreement may serve as leverage in the future with these stakeholders when they come back with more requests, which my experience says they likely will.

Once you have the details nailed down from those pushing for the last minute change, work with your product development leaders to examine the request and determine the least amount of effort required to meet the request on a sliding scale. In other words, meet 80% of the change requested with 25% efforts, versus 100% of changes with 150% effort. Once the product team comes back with its assessment, then you have an ROI calculation on the change that you can share with everyone.

Now work with the stakeholders requesting the change to get them to understand the ROI equation and get them all nodding to that one change plan. The plan that is most beneficial and least disruptive based on the cost-benefit analysis. Ensure that you are all on the same page.

One possibility that may arise with this approach is your product team can come back with a “no go” or a “train wreck” assessment — meaning that making the change will jeopardize the entire product delivery effort. Now you have to have a very difficult conversation with your stakeholders. But hey, no one said your job was going to be easy! It’s better to have this conversation now, and with the data and ROI calculation in hand and to ensure that the product goes out the door, rather than make the change only to find that the product never actually makes it out the door. That is what we are trying to avoid… at all cost.

Not all of these observations on scope creep may be applicable, but if even one of these early warning indicators turn out to be true and you are able to proactively address them, then this knowledge could save your venture and your team a considerable amount of time and effort in their already challenging,  time-consuming effort.

 

If you have any questions, please drop me a note. I’d be happy to provide you with advice and guidance. Please read and share all of my blogs at LeadingVentures.com.

About this blog – The goal of this blog is to share my experiences, to capture and reveal valuable insights, and to draw from my serial entrepreneur-ship through 7 ventures over the past 20 years. I have encountered many impressive entrepreneurs along the way and I hope to share our collective experience with you to help teach and perhaps motivate you to launch your own B2B or B2C enterprise.

© Jitin Agarwal – All rights reserved. This blog is property of Jitin Agarwal and leadingventures.com. Unauthorized use and/or duplication of this material without express and written permission from this site’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Jitin Agarwal and leadingventures.com with appropriate and specific direction to the original content. For this blog, in instances where other previously copyrighted content, trademarks or brand references are used and noted as such, the author disavows any ownership claim, trademark, copyright or intellectual property ownership of these items and they remain the property of their respective and original owners, their inclusion in this blog is merely for illustrative example purposes only.