Rope Your Scope: Reining in Scope Creep (Part I)

By Mary Gorman and Ellen Gottesdiener

Recently I worked with a project team developing a software product under grant from four entities, with a government agency as their ultimate customer. They called me in because, three months into a four-month project, they were desperately behind. Why? They’d been spinning in circles, trying to satisfy diverse stakeholders who had overlapping as well as conflicting requirements. The funding was split among several competitors, each with its own competencies, and there was a sense that the government agency was playing favorites based on its own preferences in the domain.

Some in the client organization felt that project team leadership was weak, and the head of the government agency was new to the job. The many features being requested would never fit into the mandated deadline and budget for the first release. What’s more, team members were distributed, and people in one remote team had concerns about architectural issues but couldn’t talk about it openly or challenge the others.

Over three intense days, we worked together to resolve the issues. We revised the vision, clarified the stakeholders and their value considerations, identified how the team would communicate and manage the requirements, pinned down the product’s risks and benefits, and analyzed which increments of the plethora of product needs (aka requirements) were to be completed by the November release.

A bit later I’ll explain the breakthrough that allowed the team to get back on track. For now, know this: one of the biggest problems for this team was scope—or rather, that they hadn’t understood and agreed on the scope of the product to be delivered.

Churn and Burn

On complex projects like this one, the team members naturally confront thousands of questions and decisions. When the scope isn’t clear, all questions seem to point back to the basic one: what are we doing here? Until you answer that question, you’ll suffer missed deadlines, blown budgets, quality problems, rework, team stress, and perhaps even project failure. It’s no wonder that scope creep—the unrestrained expansion of requirements as the project proceeds—is cited as one of the top project risk factors.

It’s easy to blame customers for not being clear on what they want or need. But that isn’t their job. It’s our job to help discover what they need, begin to build it, get feedback on it, and apply that learning to the next increment, release, or milestone. You expect scope to change over time. The key is to understand the difference between good scope creep—learning, blue skying, visioning, exploring, and discovering—and bad scope creep: churning, wallowing, delaying, postponing decisions, and analyzing your way into paralysis.

The difference is this: if you have scope reined in at the right time and at the right level of granularity, you’re following good practices to dramatically mitigate scope creep issues. You’ll deliver the right product in the first place, and you’ll build strong, trusting relationships on your project team.

Product Partners

A big error is to overlook a variety of stakeholder viewpoints from the product team.

Teams need to include partners from the business side of the organization, from the customer realm, and from the technical team. You need all three perspectives to gain a clear understanding of scope.

In our recent book, Discover to Deliver: Agile Product Planning and Analysis, we refer to the team as “product partners” to represent their relationship and responsibility. Calling stakeholders product partners also emphasizes the importance of the cooperation and collaboration essential to reaching a shared understanding of the product. It is necessary to take a close look at all the partners’ value considerations to make appropriate trade-off decisions for what will be in or out of scope.

Missing in Action

The most serious shortcoming I see? Product teams fail to address, early on, the project’s context—the big WHY of the project. This gap is deadly, because you need it to guide ongoing decisions as conditions change and questions arise.

Before you launch a project you must first develop a product vision, identify goals and objectives for the product, clarify the product partners’ value considerations, and understand project constraints (time, money, people, and other assets) and risks. In addition to clarifying the product’s scope, the vision gives you a concise, cohesive, coherent, and unifying basis for choosing among product options (requirements) as the project proceeds. The goals and objectives tell you in greater detail the product’s expected benefits. Value considerations help you explore both tangible and intangible values from different partner perspectives. And of course project constraints, too, help you define and manage scope.

The reason you need an explicit understanding of scope is that things change: markets go in a new direction, a recession occurs, new technology is developed, you learn more about your customers’ needs. Then you must revisit and reconsider the vision and perhaps redefine the scope. You can’t do that in a disciplined, deliberate way if you’re still unclear on the context of the project. I’ve worked on many projects where the teams were experiencing all kinds of unfortunate unintended consequences from a lack of clarity on the product’s vision. It’s OK to be unclear initially, but not OK to let ambiguity languish. Fuzzy, smudgy scope is an opportunity for learning, collaboration, and communication.

Another gap is that many project managers and teams rely on a few familiar ways to articulate scope. They may generate a list of requirements or draw some diagrams. Some of these tools, such as context diagrams, are useful, but to get a clearer picture of your work, you need variety.

And finally, teams let decision making itself become squishy. It’s crucial to identify how you will make scope decisions—who will decide, using what mechanisms.

The Breakthrough

So what happened with the client organization? A key practice we use with clients involves exploring and evaluating proposed product needs in terms of what we call the “7 Product Dimensions.” Product partners conduct structured conversations using an Options board to visualize possibilities for the dimensions.

When I used this technique with the client, something big happened when they looked at the User dimension. I facilitated an activity where they placed sticky “people” posts on the wall representing possible users and began to arrange them into a hierarchy (look at a photo in Image 1, here). Suddenly the discussion became animated. People referred to the list of value considerations they’d prepared and realized they needed this release to focus on one specific type of user; for now, they could ignore the others. This decision rippled through the other dimensions, reducing the data they’d have to provide in the product. Similar scoping issues were resolved in the same way and included limiting the release to only certain actions. Now that the scope was clear, things began to fall into place.

Stay Tuned

The kinds of remedies I’ve described—identifying project context and product content and making product decisions in a disciplined way—are embodied in good practices, artifacts, and plans. In my next blog post, I’ll describe these tools in more detail and explain how you can use them to manage scope in your projects.