Newfangled works with independent agencies to create lead development web platforms for their clients.

Newfangled works with independent agencies to create lead development web platforms for their clients.

Why Scope Creep is Your Fault (and What You Can Do to Prevent It)



I want to talk to you about scope creep.

No, not the wait, we never talked about e-commerce! kind of scope creep. Too much is said about that variety of scope violation, and frankly, I'm not convinced that it actually qualifies as creep anyway. Most of the time, when that big-but-not-included-feature comes up, we can simply say, "that's not in scope," and explain why and what it might take to add it if necessary. That kind of thing should never be allowed to throw a project off course. This is what "phase two" lists are all about; they exist to catch all those features that are not feasible to do now, but could be manageable later. Under their own budget, of course.

But like I said, that's not exactly scope creep.

Scope creep is the kind of thing that accumulates so slowly and subtly that you don't realize it's happening until it's too late, like when you've already promised it or, worse, when you're already building it. Scope creep is like slowly loading up your plate with little portions of everything on the buffet until you realize man, this plate is getting heavy and omigod I can't eat all of this, what was I thinking! Except, for the metaphor to work in our case, we have to imagine escorting our clients to the buffet and willingly loading up their plate with every single thing they want knowing full well that they have no hope of eating it all (and that price-per-pound buffets always win by betting on big appetites).

The only way for that to happen is if we—not our clients—let it happen. That is the kind of scope creep I want to talk about. The kind that, though we may want to blame our clients, is really our responsibility.

 

Taking Orders is for Scope Creeps

First, the most important thing to remember is this: your client is paying you to lead them, not to take their order. Leadership involves helping them navigate decisions on the basis of a core goal that can serve as a rubric—for instance, will this feature help them attract, inform, and engage prospects and, ultimately, grow their business? On the other hand, order-taking easily leads to scope creep because it's so inert. When our contribution is simply taking down a list dictated to us, we are not activating our critical thinking. That tends to result in interactions like this:

"We need a slideshow..."

"Ok."

"...and we'll need to be able to add images to it..."

"No problem."

"...and control the speed of the slides, of course..."

"Cool, cool."

"...and their sort order…"

"Uh huh."

"...oh, and can we overlay text on each one?"

"Sure."

"Great, we're thinking like 15 to 20 slides for each slideshow…"

"Each?"

"Right, we need one of these on every page."

"Oook."

"Oh, and it should show a different slide each time a user comes back to the page…"

"Well..."

"…so we'll need some kind of cookie or something-right, cookie?-to keep track of which images the user has seen…"

"Wait, what?"

Sound familiar?

 

It's Just a...!

Our developers call this a "just-a." They've summed up dialogues like this one with that phrase plenty, and no matter how many times it's been said in the last fifteen years or so, it always causes them to erupt into laughter. Whenever anything is thrown in, they'll say (often in unison), "it's-just-a!" But just so we're clear, they're not satirizing the client. No, they're satirizing us—the designers, account managers, project leads—the people supposedly managing the process. Why? Because they know that scope creep always gets by with a little help from its friends. And they're absolutely right. They know about dialogues like the one I included above. We who do not think critically are scope creep's friends.

sentences1.png

You Owe it to Your Clients to be Critical of their Ideas

So back to my first point: we are here to lead our clients, not to take their order. That requires being critical. Not critical in the sense of making value judgements (e.g. "that's a dumb idea") but in the sense of deconstructing ideas in order to justify them. We've got to get comfortable with challenging our clients' requests by asking: Why? What is it for? How will it work? Who does it benefit? What does it cost? We can do this gently and kindly, by the way. I'm certainly not suggesting that we assault our clients with some kind of 3rd degree treatment. Our job is to help them make decisions, keeping in mind that there are priorities to consider with every possible feature: the purpose of it, the user experience, the content management experience, and of course, the cost—not necessarily of that specific thing, though that can be an issue, but of all these little features in the aggregate. In the end, managing the little things is the most powerful means of avoiding scope creep we have.

With that in mind, I'd like to suggest a three-tiered system for evaluating any piece of functionality, no matter how small ("just-a") it may seem. Starting with the first and working our way down, we should evaluate functionality in terms of the user's needs, then the client's needs, and lastly, its cost. Strategically speaking, I find that cost as an arbitrator tends to provoke strong emotions and dissent—no matter how practical an argument it may present—whereas thoughtful, user-focused arguments are much harder to argue with. This is why I recommend keeping budget-focused arguments against minor functionality in reserve. Use them only if user-focused arguments don't convince your client.

To demonstrate this system, I'm going to use an example similar to the slideshow that was referenced earlier in the you + client dialogue. (For the record: If you're a client, this example is not about you. Scope creep of the it's-just-a-slideshow variety is probably the most common example of exactly the sort of lots-of-small-features scope creep this article is about. It comes up all the time. So, if you feel like I'm making a veiled reference to your project, don't worry, you're in good company ;-) )

 

Bad-Idea Triage

To review, here's the scenario: You're prototyping (or wireframing, if you're into that) a new web project with your client. They mention that they'd like to have the ability to include a slideshow on each page—one that can support an unspecified number of images (implied: unlimited). Instead of cycling through them, it would only show one of its many images per page load and, specifically, only an image that the user has not yet seen. The idea here is to consistently deliver a "fresh" visual experience to repeat visitors.

So, let's dissect the idea...

 

1. Does this feature meet the user's needs?

Another way to put this is, does this functionality enable a probable outcome? I would say no.

The client mentioned that they'd like this feature to not be limited to a certain number of images. From their perspective, that gives them the most freedom, which in and of itself is no problem. So let's say that they have the ability to create five unique images (per page, remember, but I'll come back to this in a moment). In order to make it possible for a repeat visitor to see a new image each time she returned to this page (well, really, only up to five times since that's the number of images we're working with, but sure, it could be ten or twenty or more) the site would have to place a cookie in that user's browser that kept track of which pages she has viewed and which images were displayed. It's not the most sophisticated tracking in the world, but it's an added layer of programming. But the question is, will this functionality actually get used? How likely is it for a user to return to the same page on a website five times? My hunch: Not very. In my experience looking at hundreds of analytics accounts, the likelihood of a user viewing 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. But just to be sure, I surveyed the analytics accounts of all of our active clients—which is a decent cross-section of business types including B2B and B2C—and discovered that the average number of pages per visit for all of them is 2.98. If the average user sees less than five pages across the entire site, how many could possibly see the same pageup to five times in their session? Little to none, that's how many. So, why build functionality for a scenario that—according to these statistics—will never happen?

In theory, something like this sounds neat and really wouldn't take that long to implement (one developer I asked estimated something like four hours), but the data shows that it's not likely to benefit many users, if any at all.

 

2. Is this feature manageable?

In other words, does this feature create more work for the site administrator than is necessary? This brings to mind that overloaded buffet diner's plate: It all may look delicious, but do you have room to eat it? Again, I think the answer is no.

There are two issues here. The first has to do with the content itself. If the client is imagining that this rotating image feature will appear on every page, then they're going to be very busy with image creation. For instance, if their website has just twenty pages (unlikely these days) and each page has only five images, they'd need to create one-hundred unique images. My guess is that skeptically pointing this out will cause the client to fall back upon re-using some of those images, but that undermines the whole keeping-it-fresh idea, right? But suppose the client says, "One-hundred images? I can do that in my sleep." In that case, on to the second issue...

The second issue has to do with the structure of this content behind the scenes—how it will be managed using a content management system (CMS). Rather than talking about content in the abstract, we tend to focus in on content "types." A type might be anything from a product to a case study to an employee bio. In general, if the website administrator is going to need to add content on their own moving forward—a new product, a new case study, or a new employee—then we build a type that can be scaled as far as need be. That way, the client can log-in to their CMS and simply choose "add new product." So, how might that work for this slideshow feature?

In addition to the page content types, for which there might be quite a large number, we could create a "slideshow" content type that the CMS user can add to the database as needed. She might name it something like "snazzy pictures 1." We would also need to create a "slide" content type, which would allow the CMS user to add individual images to the database. The workflow would probably look something like this: First, the CMS user would add a new slideshow, which would essentially just consist of naming and saving it. Then, she would create a new slide, uploading the image to the database, naming it, associating it with the slideshow, and saving it. She would repeat this procedure for each image she wanted to include in the slideshow. For a slideshow of only five images, this could potentially require around eighteen unique steps (adding, uploading, associating) just to get the material in place on the site. Then she would need to edit the page on which she wanted to display the slideshow and, using something we call a "picker," find it in the database and associate it with that page. Then, she would need to repeat this entire process for every page that needed to display a slideshow. Who knows how long this could take. With a good internet connection and some practice, perhaps just a matter of minutes. Probably not, though. Things always take longer than we expect. And of course, this is not including the time needed to create the images themselves. All in all, we're talking about a lot of work for just a little payoff.

But this could be simplified some. Let's say the client was willing to limit the slideshow to only five images. In that case, we could simplify the workflow greatly by just adding five upload slots to each page's edit screen. That cuts out the need to add a slideshow content type, associate it with the page, then add and associate each unique image. Instead of connecting that series of content types with some kind of display logic, we'd just write the display script to pull from the page's image slots. But, again, that's assuming the client is OK with limiting the feature to five images even though they started out by hoping to be able to include as many as they wanted.

What these two issues show is that "as many as you want" sounds great, but the question is really "how many will you be able to create?" The time it would take to manage a feature like this is excessive, but it's really only the tip of the iceberg. The other time to consider is the time it requires to create it, which is ALWAYS substantially more. Why would anyone spend this much time to create and manage imagery that, as I showed in the first section, is unlikely to ever be seen?

triage1.png

3. Is the cost of this feature out of proportion with the overall budget?

Unlike the others, this question should be pretty straightforward to answer. However, the amount of transparency you allow over the process of asking and/or answering it—as far as your client is concerned—is up to you. Generally, I think that alluding to the amount of time an individual feature might require relative to the overall budget is often as far as you need to go. For example, I mentioned earlier that one of our developers estimated that the more complex version of this hypothetical slideshow feature could take roughly four hours to build. Now, I'm completely against this feature and think that the other reasons for ditching it which I've already reviewed—that it anticipates an unrealistic user scenario and requires way too much work from a content management perspective—provide a persuasive enough argument upon which to rest my case. But, maybe the client won't agree. Maybe they don't fully get my user-focused point and are confident in their image creation and management skills such that my CMS point seems like over-thinking it. Fine. In that case, I'm probably going to be inclined to talk about money. Let's say that we've budgeted forty hours of development time for this project (way less than normal, but I'm just going for a round number here). I would then inform the client of the developer's estimate and suggest that I thought that a tenth of the overall budget going to just this one feature was probably out of proportion, especially if it was just one of many features like this that aren't ultimately essential to the website's purpose.

You could, of course, get more specific about the dollars and cents when it comes to prioritizing features. Do what makes sense for the relationship you have with your client.

Asking whether a feature benefits the user will always draw upon what we believe should be the guiding principles of any website: does it attract, inform, or engage the right audience? In the particular example I used here, that involved questioning whether the logic of the feature itself left any audience to experience it. Having analytics data to guide this type of decision is really helpful, but the case probably could have been made without it. While this first line of questioning should be your priority, don't hesitate to move on to the next one—which will show your client just how much work they're creating for themselves—if the user-focused argument isn't resonating. Buffet mentality is exceedingly common during website development projects, but it's typical for there to be only one site admin who inherits the overloaded plate once the site needs to be populated. Making a case for that person's workload is a powerful tool.

 

3 Steps to Scope Sanity

Though I've used a very particular example to describe the three core questions central to this method—is it usable, manageable, and affordable?—it can and should be applied to evaluate every possible feature. The slideshow (and a million variations thereof) is only one of many possible just-a's that we encounter over and over again. Off the top of my head, others include the overloaded employee profile template (the kind that believes you need to know Jennie's favorite color or Richard's top karaoke pick), the content taxonomy large enough to suit the library of congress (it really gives that blog room to breath), the three or four different hidden page templates (you know, just in case), the 30 different discount codes that have no business structures behind them and only came up because you asked, "what kinds of discounts will you need to offer online?," oh and of course, the live webcam of just about anywhere. There are plenty more, of course (feel free to share your favorites in the comments), the point being that any of these things could seem like a good idea or even an imperative in the absence of critical thinking. That's what makes scope creep possible.

As I'm confident you've experienced for yourself, scope creep really isn't the result of some surprise mega-function that is obviously out of scope. Instead, it almost always comes from an aggregate of little things that, individually, may seem like no big deal, but taken together, amount to an excessive plate of food that no one can eat and few can afford.





Comments

Renee McGivern | April 24, 2012 9:04 AM
Yes, my small business clients and I want leadership from a web developer. The order-takers are avoiding responsibility, and as a result, scope creep turns a simple four-month website project into a 12-month one. The project becomes dreadful.

The manageability of the site later is where I see the greatest misunderstanding. There are lingering assumptions among business owners that it's hard to add things later and also, that they'll pay for it all now and won't have to worry about the site again for several years. Guidance from a developer is especially helpful here.
Libby | April 24, 2012 9:09 AM
Great, GREAT, article.
Carol | April 24, 2012 9:36 AM
Bravo! You nailed it. Raise my hand and swear never to let it happen again. Promise.
New mantra: out of scope, out of scope, out of scope
Christopher Butler | April 24, 2012 10:17 AM
Renee: Exactly. I'm on a local town council for economic sustainability and heard a straight-up horror story the other day from one of my fellow board members. Her company hired a web designer/developer over two years ago to re-do their website. They got through the design stage (no prototyping or wire framing, btw) and into the build stage. There it languished for about an entire year! She has received several emails from her project manager at the development company describing how the project is twice as large as they'd expected and how they just don't have time to work on it right now, but they're *hoping* to get back into it in the next few months. Can you imagine?

Libby: Thanks!

Carol: The thing is, the method I'm suggesting should also lead the way to saying "yes" sometimes, not just "no." But I hear you—unfortunately, there are often far more opportunities to say "no" than there are those to say "yes." That's why talking about Phase Two is always a good move. It helps the client to not feel overly constricted to know that there is a plan to add in features later.
Jordan Kohl | April 24, 2012 10:59 AM
Great tip about informing the client what % of the budget a particular feature will require. Never thought about that.

I think a key to enforcing this, or any strategy, is being consistent. It is easy to say no to features as they come up in the planning stage, but often these little bits of scope creep happen much later in the process: typically when a client is reviewing a mock-up or prototype.
Eric Koby | April 24, 2012 12:03 PM
Loved this article. Thanks Chris!
Beth | April 24, 2012 1:23 PM
Love the visual metaphor of the empty -> full plate. Just one more tasty morsel!

This applies to any kind of project not just web design (we're remodeling our house - can you say scope catastrophe?). A little education goes a long way. Your google analytics comparison is great example of using statistics in a meaningful way.

Shifting responsibility away from the client is smart and probably the only way to keep creep in check! What has helped me keep it in check with my clients (from painful experience!) is billing. One, it's hard for me to figure out how to bill a project that descends into this kind of waistline abyss, especially if it is a set project rate; and two, clients hate footing the bill.

Thanks for the honest, full skirt reveal! :-)
david | April 24, 2012 6:39 PM
great great article. thanks for the perspective. I achieve leadership with most of my clients but some of them just know better.... :)
Tim Williams | April 24, 2012 7:53 PM
Chris -- great insights. As a result of my consulting work with agencies, I've come to believe that scope creep is by far the largest profit drain in the advertising/marketing business, followed closely by poor scope definition in the first place.

You're giving some very sage advice here -- keep up the great work.

Tim Williams
Ignition Consulting Group
Matt | April 25, 2012 7:28 AM
Great article. And excellent points you make. I think in the example given, you have even been very optimistic about the time/costs. The programmer might need 4 hours to build the feature. But what about:
- the time spend discussing this with the client
- instructing the clients how to work with the images
- maybe putting up the first images yourself as an example
- in a few months time the client has forgotten how to work with the feature and mails a question. Expecting to get an answer for free, since it's just "a quick question". But you have dozens of clients, each sending "quick questions", so you almost need to hire someone specifically to answer all those support questions
- etc
All in all, this "simple" slideshow will take at least 10-20 hours of your teams' time. That's about 1-2k in costs, depending on your rate.

And of course the first arguments (users needs and manageability) remain and could be enough reason alone to not do the feature.

In my experience, "small things" only are small when both parties have done the same thing before a couple of times. Say the client sends you a request for "a similar slideshow as the other ones you build for us". And the client sends with it exactly the pictures and text needed to build the feature. And trust you to build it the right way. And doesn't come with any change requests. Then for you as the developer, you can work quickly and there's little "overhead".
Christopher Butler | April 25, 2012 8:58 AM
Jordan: You're absolutely right about consistency. It's necessary for two big reasons: First, it gives your client reassurance. If it becomes clear to them—either by insight on their part or by explanation from you—that you have a procedure for just about everything, they will feel much more secure in their relationship with you and assured of the outcomes you've promised (especially when it comes to pricing, but more on that in a moment when I respond to Matt's comment). Second, it provides a means for you to learn from your own experience. If you're meticulous about timekeeping, then you'll be able to measure every project you do and, from that data, ensure that your pricing and scheduling are as accurate as possible. Without that kind of scientific approach, it's pretty likely that your planning is inadequate.

Eric: Glad to hear it! Thanks for taking a moment to let me know.

Beth: Yes! Planning and building a website is a lot like planning and building a new house. A lot like that. Lots of details, lots of people involved with different pieces of the overall expertise needed. Again, you bring up pricing, which is definitely an essential component to this scope issue—one that I intentionally downplayed because I wanted to explore this concept from a different angle. So, I was assuming financial stability, but more on that when I address Matt's comment.

David: Ha! First we have to lead ourselves. Then it will be natural enough for our clients to be convinced ;-)

Tim: Absolutely. You can really only price a project as accurately as you and your client-to-be are able to articulate its scope at the outset, which is why historical data is so essential. For us, we have standard pricing models that we begin with and then customize for each new engagement. But once that's in place, it certainly doesn't prevent project bloat, which is what this article was all about. Glad you enjoyed it, and thanks for reading!

Matt: You bring up a very important point, and you're absolutely right that the cost I estimated is not exactly accurate. Let me explain:

Our process includes a prototyping phase. It tends to take about 4-6 weeks, during which we build a functional (clickable, navigable) model of the website. When I wrote this article, I had this phase in mind—because prototyping is a scope-specifying procedure, it tends to be where most of this kind of scope creep occurs. I didn't note that I had this particular phase in mind because I do believe that the questions I'm recommending would be relevant to defining scope whenever that is happening, whether pre or post launch. Now, our prototyping phase has its own budget, which accounts for all the time we spend working with our client to define every last detail the developer needs—from general information architecture, to what specific information and functionality each page or content type will include. The resulting prototype serves as the blueprint for the developer. So, my developer's 4-hour estimate for the slideshow functionality was relative to the budget we would have for the programming after the prototype is approved. In that case, we're talking just about the developer's time (and again, we have a separate budget for programming). The time spent discussing the slideshow and how it will work would be covered by the prototype budget, the time spent training the client on how to use it will be covered by the programming phase budget (we include time for CMS training), and the time spent re-training the client later on will be covered by their monthly support fee. So, that's the background to my light estimate, but it only proves your point: All of this time is necessary, will be spent, and should be accounted for financially. And back to Tim's comment, we have standard pricing models which exist thanks to our historical timekeeping data. We know how much time/budget these phases require because we've closely measured our performance on them in the past.

However, if the slideshow was being discussed after the site launches, then it would fall under the "maintenance" category. We handle this a bit differently. For any maintenance work, we follow a strict resourcing rubric that accounts for the time spent discussing the feature with the client, the time the developer will spend quoting for the work, the time the developer quotes, the time we expect the account team to spend coordinating it all (we have historical data showing how much that time tends to be, a Project Manager to Developer ratio), the time we expect for tweaks (again, a proportion derived from historical data), and even the time needed to invoice the work. So, if a developer quotes 4 hours, that gets plugged into an equation that accounts for all of that, factors in our hourly rate, and produces the final price. That doesn't mean we never get it wrong—sometimes things just take longer than we expect them to—but we mostly get it right with this approach. So, if I were to price this slideshow feature as a maintenance item using our rubric, it would actually come out to around $1,200—right within the range of what you estimated!

Thanks, everyone, for your comments!
Jordan Kohl | April 25, 2012 12:30 PM
Chris: do you use software to calculate your estimates as explained in your reply to Matt?
rj | April 25, 2012 8:39 PM
I've been a professional designer for over a decade now, and having experienced scope creep firsthand again and again, I can see how these approaches might help from time to time. However, my experience has been that clients carry a strong entitlement which is almost guaranteed to override any pro-client strategies like these. You've got a kind heart, and I don't want to be a killjoy here, but it's bordering on naive to think that you can always reason with your clients.
Christopher Butler | April 26, 2012 8:55 AM
Jordan: We use an admin system that we built in order to do our time tracking and generate reports based upon that time. But for pricing, we still do that the old-fashioned way. Lindsey handles our resourcing and provides pricing based upon the rubric I described. Keeping it human at that level is pretty important to us—it lets us question the pricing if we want to (i.e. raise or lower it, depending upon all kinds of factors that might not fit in to an algorithmic approach). For project pricing, we have a default pricing spreadsheet that we start with for any possible engagement and adjust as we go through the sales process.

rj: Gosh, I just cannot agree with that. The recurrence of scope creep is not a legitimate reason to conclude that scope creep is unavoidable—that's just another way of saying "I give up," isn't it? I wrote this because I know that scope creep seems unavoidable, but it's my belief that it is more often the result of our negligence to the strategic side of our practice than it is due to client irrationality. In fact, I'd challenge you to examine your attitude toward your clients—to assume they're irrational is irrational itself, not to mention condescending and solipsistic.
Lisa | April 27, 2012 4:59 PM
Love this article! I'll be sharing it around the office.
Elliott | April 30, 2012 12:01 PM
Great article... really, really good. Wish I had read this before I let a client end up a.nightmare...
Julie | April 30, 2012 1:00 PM
Great article I have passed it round the office, but really the stuff in this is aimed at me :)

Good to have some analogies to help support a more phased approach. We find that clients tend to think of their sites as one project that's never to be attended to again for several years, but they are slowly coming round to the fact that sites are always evolving, ideally for the better, and phases are good.

Nailing down those initial specs is crucial, no matter how long it takes to get right much better in the long run.
Jeff | May 1, 2012 8:54 AM
Just watched a 2 month project turn into a 6 month monster with tremedous scope creep. I'll pass this one along for sure.
Christopher Butler | May 1, 2012 9:55 AM
Lisa: Excellent! Thanks for letting me know.

Elliott: Glad to hear you found this useful. Good luck!

Julie: Analogies are really important. I've found that explaining some key principles to clients—particularly those related to time and budget requirements—is always easier and more effective when using some kind of analogy or comparison to something the client already knows well. Thanks for your comment!

Jeff: Yikes! Better luck next time…

Thanks for reading, everyone!
Richard | May 1, 2012 10:46 AM
My initial thought with the slideshow example was that this was not scope creep, but simply the client defining their desired requirements. Obviously the task of the good developer is to sprinkle a dose of reality across the requirements answering the big questions; is it needed, can it be done, is it worth it?

Out of this discussion should be a mutually agreed scope definition. Scope creep occurs when the client, after the scope has been agreed, starts adding in their "can you just.." items.
Jason | May 1, 2012 2:36 PM
Chris,

An excellent overview of the most common of development challenges, whether the clients are external or internal. The 3 steps you outline have always worked for me fairly well, and I agree wholeheartedly with the order you've got them in. Many times a client is quite convinced he's right on point #1, only to come up against a harsh reality with point #2. Probably the most recurrent example of that over my years of CMS implementations has been user permissions:

"We want to lock down some pages to be seen only be logged in users."

"Okay, no problem, we can do that already in our CMS."

"We have 300 users and maybe they should be in groups and actually, now that we think about it, maybe different branches of the site tree will have different access levels by user group."

"Who's going to define those groups, create those groups, enter the 300 employees, and then train all the different CMS managers and users?"

"Um."

"Since this site is outside your network, how will you handle things when an employee leaves, so he doesn't continue to have access to your protected data?"

"Oh, yeah, that's a good point. And if we have non-HTML files out there, are they secured from unauthorized download, too?"

"We can set up file management that way, too, but now you have to apply user and group level permissions to every single branch and page of your site as well as to every single folder and file in the file manager. Who's going to do that in your organization?"

"Oh. Maybe we've overthought this ..."
allie | May 1, 2012 11:15 PM
Wonderfull!
austin | May 2, 2012 1:48 PM
"your client is paying you to lead them, not to take their order."
this, and a lot of the article that follows, seems to be directed at freelance work where the person asking for the work is your CLIENT not your BOSS.

your boss in fact DOES pay you to take their order. and when you ask "why" for a feature they say "because im paying you"
under those circumstances, how do you prevent scope creep?
Thomas Vanderhoof | May 3, 2012 1:22 PM
For:

3. Is the cost of this feature out of proportion with the overall budget?

I like using a method called t-shirt sizing. You ask them on a scale 1 to 10 (100?) how important each feature is(in relation to the overall application) to have it built into the application. Their feedback goes in Column 1 of a spreadsheet. In Column 2, using the same scale, specify the complexity of that feature?
With this information, the client can determine if the feature (the shirt) fits the cost (the subject).
James Andrade | May 6, 2012 10:46 AM
Chris, excellent & insightful commentary, as well as great feedback from those posting comments. And I completely agree we are at fault in cases like these as much, if not more than the client, because we should know better.

The slideshow example is a classic because it happens all the time. Funny enough, we had a very similar experience with a client. Other examples of this type of subtle scope creep include adding or customizing a form; adding a secondary menu say a lateral one; adding social media integration or APIs; creating a different template for specifc interior pages; adding customized functionality for the Blog or the archives; and adding levels to dropdown menus.

I realize that some (or all) of these examples should have been defined in the scope build (requirements) phase (& some of these are not subtle scope creep items) but sometimes this doesn't happen for reasons such as the most common one I've found ie a client immersed in the project realizes he 'needs' these items as the project moves along.

We try to posit as many of these scenarios upfront to avoid this incessant slow-building type of scope creep & will often take more time (than the client would like) in the requirements phase.

Chris' approach is great advice & sometimes a client will back off a request for one or more of the reasons he explains; one outcome we haven't been able to easily resolve is when we end up implementing additonal tasks & even though the client will understand the need for and agree to pay additional fees, the project will take longer to complete and senior management & others on the client side will inevitably be unhappy as to why the project took longer than initially proposed. Explaining that additional work was implemented doesn't seem to justify the delay to these folks. It just seems to create a perception that we took longer than expected.
Christopher Butler | May 8, 2012 1:32 PM
Richard: I think it can be both. The example I used, which sometimes can come up at the planning stage, is often a scenario that happens later on in the game. The trouble with scope creep — for designers and developers — is that it often is heard as a pejorative term. That's because it frustrates us. But if we take into account the client's perspective, it's completely understandable, and as you say, is often the refining of requirements. But if a client refines requirements after we've agreed upon a scope of work or even started the work, then it's into change order territory, which we shouldn't subsidize.

Jason: Yes, this one is very familiar! Great example!

Allie: Thanks for reading!

Austin: I wrote this article with designers who work for agencies in mind, though it certainly would also be relevant for freelancers AND — with the exception of the quote you pulled — in-house designers. My point about what the client is paying for is more of a business practice point, but if we abstract it, it's also true that the boss is paying the employee to do a certain job, which I certainly hope involves their best thought and advice. An employer/boss shouldn't evaluate employee performance just on the basis of thoughtless compliance. Likewise, am employee shouldn't fall into the trap of thinking that good job performance isn't just telling the boss what she wants to hear. So, in that scenario, I think an employee owes their boss the truth. If it's a bad idea, say so (diplomatically, of course) and why, and if it's a fine idea but would jeopardize schedule or budget, say so (diplomatically) and why.

Thomas: I like that idea, too. Thanks for that!

James: Those are all such common examples that I even toyed with using them as the basis of this article! I completely agree with your experience, too, that these kinds of things often don't come up until there is something built or designed that the client is responding to. Thanks for the input!
Freesharehere | May 11, 2012 8:49 AM
Hi Christopher butler. Great article you had written. I think everyone must read this article. This article not only sought out the problems in the web world but also in the normal life. Moreover as a designer i understand the importance of this article. Thanks for sharing this article. I really appreciate your work.
Joel | May 14, 2012 12:44 PM
Hello Chris! You continue to be a great source of information as I "attempt" to master the web development process. I appreciate your team's leadership in this area. Hoping to one day be able to contribute to the web world but for now I am happy to learn from you. + you actually take time to read the comment and respond to every one of them! What!
leandra | May 15, 2012 9:56 AM
Great article. I know for a fact that the occasional scope creep I deal with is mostly my fault as a designer who enjoys "throwing in a few extra features" if I am making good time with a project. But (there is always a but), I have gotten burned a few times so thanks for the guidelines that will (hopefully) stick in my brain the next time I feel the scope creep coming on. :)
Christopher Butler | May 15, 2012 10:11 AM
Joel: Thanks, Joel! It's always great to hear that this stuff is helpful. As for answering all the comments, it's my pleasure. I actually enjoy the discussions that develop around this stuff — they make the writing well worthwhile.

Leandra: I hope these pointers will help you out moving forward. But you raise an interesting point about trying to add value. I think that if we can add value, whether in the form of new features or more detail from a design perspective, without jeopardizing deadlines or budgets, we should definitely do that. That's what doing a good job is all about. But it's a fine line to tread, that's for sure! Thanks for reading!
Anonymous Coward | June 5, 2012 9:22 AM
"your client is paying you to lead them" - that's presumptuous.

The client often has already an idea of the solution, not just the problem - one that's usually wrong, at least to some extent. Your job, as a service provider, is to get reasonable requirements - and this involves getting the client to reason about his solution, recognize the problems, and yield to solutions you propose.

Assuming the client pays you to lead is dangerous - you might infer that the client pays you to (re)define business processes, which is something you should absolutely never do, because even if you need to understand the client's business, you'll never get an understanding so deep and thorough of it as the client already has.

In conclusion, you should not lead, you should collaborate.
Christopher Butler | June 5, 2012 9:49 AM
Anonymous: For some designers and developers, perhaps you're right. But that's not the position I'd want to be in. I'd argue that if you don't see your role as one of leadership, you're ultimately only in a position to offer implementation, which is, unfortunately, a commodity now.

I completely disagree that a designer or developer's job is to simply "get reasonable requirements." That leaves a tremendous amount of potential value on the floor — especially if you have a point of view and the expertise to manifest it in an effective solution for your client. In most cases, that is why they came to you: because they recognize they can't do it on their own. This, of course, doesn't mean that there isn't any room for collaboration; clients often have great ideas, and certainly wield information and experience that we need in order to serve them well.
Crystal | June 5, 2012 7:53 PM
Loved this article! Great application of scope-creep. I especially liked the idea of Bad-idea triage. What I've found to be most difficult are those clients that can't be convinced their idea, does not, in fact, make sense for their users. User profiles, and user testing help build a great case, but sometimes, the client seems too convinced their idea is the right one. Positioning yourself/your company as the experts, and maintaining that place can be a delicate thing. When this is off balance, 9x out of 10 scope creep has arrived!

↑ top