See all Insights

How to Avoid Scope Creep

I wrote a piece for the Interaction column in this month’s issue of HOW Magazine all about avoiding scope creep. I’ve posted the text below, but I hope you can read this in print. Here’s the gist…

Scope is a powerful word. Mention it to any designer, developer, project manager or client, and you’re likely to provoke a mixture of emotional responses. Denial. Anger. Bargaining. Depression. OK, maybe it won’t be that dramatic. But you probably won’t get a smile.

In the beginning, scope is generous, spreading its arms wide, embracing all possibilities—especially the big things that have always been just out of reach—and inspires confidence that, yes, this thing will be all it can be.

But scope can turn on a dime, and it has the power to dash the very hope it created in us before. Scope creep is what we call the process of new requirements being added after we’ve reached an agreement on what we’re going to do, how long it’s going to take, and how much it will cost. These new requirements are often expected to be absorbed without changing the deadline or price. Frustrating? That’s an understatement.

It’s no wonder that scope creep is the bane of any designer’s existence: the object of constant vigilance, that thing we expect to be done to us. But scope creep as we typically think of it rarely happens; it is seldom manifest in that big, single “gotcha” feature. That scope creep is a red herring.

Instead, scope creep is typically a fine line crossed suddenly—by tallying up a long list of little things and finding resources and time wanting. More than any technical hurdle, gap in expertise, hiccup in schedule, lack of funds or even the “bad client,” this sort of scope creep—subtle as it is—is the most likely thing to threaten the success of your project. Rarely can this be blamed on an unreasonable client; we are often the co-authors of these lists. We know this—even if just at a subconscious level—and bearing partial responsibility undermines our authority and puts us on the defensive. Retreat at that point isn’t going to be easy. If only we’d been proactive.


What Happens

Ideation tends toward pushing boundaries rather than remaining within them. That’s not a problem in and of itself, especially as there ought to be some freedom to dream and explore in the early stages of any project. But it is a problem when that process doesn’t mature from a frenzied trip to the all-you-can-eat buffet to a thoughtfully considered, balanced meal.

Buffets produce variety at the expense of quality (never trust a meal that puts you in reaching distance of sushi and butterscotch pudding), not to mention the serious question of whether what has been piled on your plate can actually be consumed. They tend to provoke the survival instinct — I might want this later! — that makes adding just one more shrimp to the pile seem rational. But just-one-more-thing on top of the steak, salad, pasta, drumstick and pudding that’s already there is enough to make you sick.

Back at the ideation table, it sounds like this:

“Can we have a slideshow?”
“And can we have one on every page?”
“And can we add as many images to them as we want?”
“Of course!”
“And can we make it so users see new images each time?”
“Yes, definitely!”

That’s a lot of “ands.” It’s also a lot of “yesses”.


What Should Happen

It’s easy to call this crazy when our clients do it, but that’s unfair. We enable them. In fact, we’re often doing the piling because, in the absence of a good strategy, we fall back upon saying yes as often as possible. We think that “yes” sounds confident, though there’s nothing more bold than giving your clients the truth, especially when it’s “no” followed by a cogent explanation. Not “no” for no’s sake, but “no” in light of the bigger picture.

While the meal metaphor is helpful in pointing out the dangers of buffet-style decision making, it’s important to remember that it is not your job to wait upon your client. In “What Leaders Really Do,” John Kotter makes a point to distinguish leadership from management by defining leadership as “coping with change” and management as “coping with complexity.” Doing your job well requires both, but as the purpose of designing something new is to bring change, you must always begin with leadership.

Design leadership involves gaining an understanding of your client’s goals and helping them make good decisions by holding them accountable to those goals. Key questions you should be asking them to prompt useful web design ideation are, “What is this website for? How will it attract, inform, and engage its audience? How will we measure its success?” Every feature you discuss should be evaluated on the basis of the answers to those questions. If they pass the purpose test, you’re not done. You still owe it to your clients to be critical of their ideas.


Bad Idea Triage

You can be critical without making value judgements. Your client’s idea may be bad, but saying so may be more blunt than your relationship can bear. Instead, take a systematic approach to questioning the idea on the basis of the user’s needs first, then your client’s needs, and, as a last resort, your needs.

To demonstrate this process, we’ll need an example case. Since slideshows are features that tend to bloat easily, let’s use the one from the ideation dialog I mentioned earlier. Our client would like to display a unique slideshow on every landing page of their website. OK, that shouldn’t be a huge problem. But they also don’t want to be limited to a particular number of images per slideshow, and they’d like each one to display “fresh” images first — if a user has seen an image, it should be sent to the end of the line, so to speak. In other words, they want a more sophisticated slideshow tool that maximizes visual “freshness” based upon a user’s individual session. Sounds great, right?

Maybe. But now that we’ve explored it in more detail, this is certainly more than just a slideshow. Individually, it may not register on your scope-creep radar, but as one of many small but bloated features, it could easily tip the scales on this project from manageable to monster. To explain that to our client, we’re going to need to put their idea to the test.

1. Is it usable?

A slideshow could be a great way to convey unique messaging throughout the site, but whether users will pay attention to it long enough to make it worthwhile is up for debate. Our client specified that they didn’t want an image limit and preferred that fresh images appear to repeat visitors. So, for the sake of argument, let’s just say that they’re able to create five unique images per slideshow. Will all five ever be seen by a typical user? Probably not. In my experience looking at hundreds of analytics accounts, the likelihood of a user viewing just five pages total in their session is low enough, but the likelihood of a user returning to a particular page five times within a session is approaching zero. So why build a feature for a need the user doesn’t have?

2. Is it manageable?

If our client’s site is going to have a slideshow of five or more images on every landing page, managing this feature could be excessively time consuming. Hypothetically, if they have twenty landing pages, each with just five images, they’d need to create one-hundred unique images! They probably didn’t consider this when they made their initial request. But if we doubt that many users would ever see all these images, is it worth the effort to create them? Pointing this out will probably motivate our client to fall back upon re-using some of those images, but that undermines the whole keeping-it-fresh idea, doesn’t it? The client need efficiency, and this feature isn’t that.

3. Is it affordable?

Strategically speaking, I recommend keeping budget-focused arguments against minor functionality in reserve. Invoking budgetary concerns tends to provoke strong emotions, so use them as a last resort and only if user-focused arguments aren’t working.

But if we do go there, the question isn’t so much a matter of what this specific feature costs. Instead, we should ask whether the cost of this feature is in proportion with our overall budget. Generally, we can convert our budget to expected time, and in the same way, we can estimate how much time it will take to build this fancy slideshow. If our budget buys, say, sixty hours of development time, and we estimate six hours for the slideshow alone, we have to question whether a feature that is unlikely to be used and cumbersome to manage is truly worth a tenth of our total effort.

You could, of course, get more specific about the dollars and cents when it comes to prioritizing features. Do what makes sense for the kind of relationship you have, but make sure your need to be profitable is met.


Creativity vs. Practicality

…is a false dichotomy, so we don’t want to fall prey to the trap of thinking of scope-creep in those terms. Your job is lay a stable foundation for creativity by helping your clients set the right goals, make decisions that are appropriate toward accomplishing those goals, and manage expectations throughout the process. Creativity — yours and your client’s — can thrive in those conditions. But without goal-focused accountability, creativity can only thrive temporarily until scope creep reveals how out of line it was to begin with.