Comments on In Defense of Scope Creep

33 Reader Comments

Back to the Article
  1. . . . we can rapidly go through the discovery (a.k.a. scope creep) process, taking successive passes at arriving at a finished prototype—one that looks identical to what the application will look like.
    [ EMP. ADDED: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^]
    Once we arrive at that point, where both the client and we agree that discovery is complete, we “freeze”? the prototype—meaning that no other changes can be made (at least for this version). . . . With these tools and techniques, we know when to start writing markup and code (when the prototype is frozen) and—just as importantly—when to stop (when the prototype “runs”?).

    Bah! NO, you’ve only captured (at best) the part of the requirements that can be conveyed by the _static_ appearance of prototype. For systems with non-trivial dynamics (i.e. anything more complex than a simple brochure-ware site or anything that looks like an application), you’re missing a whole bunch of ESSENTIAL stuff:
    - field-level validation
    - form-level validation
    - text formats (input and display)
    - dynamic form behavior (i.e., enabling/disabling other controls depending on, say, a radio button selection).
    - conditionalization of page-page navigation (go to page X if A is true, else go to page Y)
    - business rules
    - animation
    - dynamic widgets (i.e., sortable table column headers).

    Yes, you can end up programming half the eventual application/site if you try to portray too much of this stuff in the prototype, but you do have to document it *somewhere, somehow*.

    As far as knowing when to stop modeling and start coding, a better way to do this is to have your users (or people who look like them) try to perform key Use Cases with the prototype. If they can successfully perform each key Use Case and they (or your subject matter expert) agree the the prototype fully covers the task(s) at hand, then you’re ready to proceed.

    Copy & paste the code below to embed this comment.
  2. I’ve been making use of Hal’s Wireframe Tool for a little while, and DevNotes for much longer. I have to say, while I find Wireframing useful for me, it’s been a complete bust for using with non-techies. I think for many clients, the abstraction required to visualise your non-existent site as essentially logic gates is too much, They don’t get it. Hell, my project manager on most projects, who’s seen me wireframe at least a dozen projects now, claims to never get a feel for the site from the wireframe. So I use it for myself, mostly to test use-case scenarios, but it’s been no help at all in terms of setting scope to me. Perhaps if my contacts with clients were all CTOs. But they’re not. I think tellingly, the only client I’ve had who found wireframes useful was, like me, in her early 20s and had been using computers since she was wee. The average client, in her late 30s or 40s, who got online since 1996 seems to need to see visuals.
    So I’m not at all convinced that wireframing embraces scope creep. Hal seems to be using it as another way to prevent scope creep once the real work has started, by making sure it’s all been accounted for previously. In many ways, embracing scope creep seems a pie-in-the-sky fantasy: by its definition, it is impossible to budget for scope creep in a fixed-fee project.

    Copy & paste the code below to embed this comment.
  3. He mentions a PHP version of the Wireframe Builder which I’m having trouble finding and the demo at doesn’t seem to be working. Anyone know where to find the PHP version or see a working demo? Thanks.

    Copy & paste the code below to embed this comment.
  4. Hal, great article… I am glad someone finally wrote about this issue. I do, however, have a few problems with this article:

    “Scope creep is the pejorative name we give to the natural process by which clients discover what they really want.”

    Why is it that the client’s are the ones determining what they want? From my years of experience I would have to say that the developer/designers are responsible for determining what the site or application should entail, the client is the one that brings the goals of the site or application. The actual end result is the “user” defines what is needed by way of use cases, user testing, focus groups and more.

    Basically if the client wants a 3D spinning logo with fire on it, fine, but I don’t think the actual user wants to see that (obviously depending on the focus of the site and intended target audience). Don’t design for the client, design for the user but meet the client’s goals.

    Also, a word about wireframing: I use them as often as possible, however I would never deliver them to a client. Clients don’t “get” what a wireframe is no matter how many times you explain it to them…. “Is this what it’s going to look like?”, “Will there be lines and boxes like this?”, “Where is all the color?”, “I don’t see the logo”, etc. A wireframe is an internal deliverable. A mockup is an external deliverable.

    In addition, I want to mention that while scope creep may not be avidable, it should always come with a cost to the client. Yes, I agree it is good to make changes to the master plan to accomodate the user’s need, but I don’t believe the web designers or developers should be made to take the brunt of tight schedules and projects that are over budget. Kelly Goto has a great book that covers some of these kinds of things… she focuses on workflow so it covers a lot of ground, but scope creep is in there to some extent.

    Lastly, if you are developing or designing complex sites or applications the amount of work that goes before a single HTML tag is typed should be approximately 1/3 of the time and costs of the overall schedule and budget. Anything less is cheating the client from what would otherwise be a good web site or application. The code should be “written” (in text) before it is programmed this way it ensures a detailed understanding of how it will function and what it should look like. This is why there are technical specs, functional specs, style guides and IA deliverables.

    I think that it would be a good thing to have a part 2 to this article that addresses effective methodologies for avoiding scope creep (not that it’s really avoidable).

    - Nick

    Copy & paste the code below to embed this comment.
  5. When engaging a client in a project, I always develop a specification. The larger the project, the more detailed the spec. The spec is the reference for the project. It is the beginning and the end. All development is done according to the spec, as well as progress evaluations. When anyone proposes a new feature or questions the design, I refer them to the spec. Sometimes the spec can be tweaked, and sometimes the customer request threatens the projects foundation.

    Every time I’ve had a problem with feature creep, it’s because the spec wasn’t detailed enough or non-existent. True enough, customers *hate* ccollaborating on specs—-they don’t know what they want and don’t want to waste time and money talking about it.

    Write better specs and this problem will cease to exist.

    Copy & paste the code below to embed this comment.
  6. Robby: I would strongly disagree with the statement that pre-build specs are the answer to getting through a project without scope-creep. In the hundreds of projects I’ve worked on, the most satisfying for me and my clients have always been the ones with a short, focused, feature-driven development cycle.

    Extensive scoping with Specs is great for *me* as a person with a background in web development, but for most of my clients (Marketing, sales, and managers) the specs are just words on paper, and they often have little correlation to what they actually want. Let me rephrase that: “The specs have little correlation to what the clients *FIND OUT* they want.”

    This comes back to reducing scope creep (which I think this article didn’t actually covered) by reducing the size of the development cycle. The longer the loop that the designers and developers have to go through before the client sees the results, the more likely that there will be changes to original specs, and the more likely that the end work of a loop will miss the mark of what the client actually wants.

    Right now I’m trying to move a client into a more ‘agile’ development cycle: results of small changes in weeks vs large changes in months. So far, the weekly cycle has been more effective for the client, their users and the support staff.

    Specs (IMHO) are a wonderful thing in theory, but Nature abhors a Detailed Spec. They rarely exist in Nature.

    Copy & paste the code below to embed this comment.
  7. Ross:

    Clents seem to *always* want features or changes we didn’t discuss originally. Specs just form a record of that original conversation, so that there can be no basis for argument.

    It sounds like we typically work with different kinds of clients. Most of the clients I work with expect to be able to rattle off their needs and meet up with me after a few weeks or months to see the (practically) finished project. I very rarely find that my clients willing discuss continued progress at each step of the way.

    Would I rather have a shorter, more “agile” development cycle as you describe? You bet. And it would reduce the amount of time and energy spent in building specs—-a sort of eXtreme Programming model for project execution. I’ve just not found clients willing to do that (perhaps I lack your expert negotiating skills), so the spec model works best for me.

    And most importantly, *all* of my experiences with scope creep come from ill-defined specs. Many consultants I know don’t develop good specs and just overbudget and overprice themselves to compensate for “slack time”. I think this is unfair to client and consultant. My advice to peers who complain about scope creep is to spec heavily——from now on I will also propose shorter development cycles based on your recommendations and experience.

    Copy & paste the code below to embed this comment.
  8. Robby:

    I completely agree with the idea that you and I may have different sets of clients. And I would add that perhaps different methodologies should be followed for different situations: I can say that an Agile cycle only works once you’ve reached a point where there’s a usable project. A Deep cycle would be a good name for the first release of the site I’m working on now. It took 11 months to develop the first release. It was certainly a Deep cycle. The first time the client really had some hands on with the final piece was 4 weeks before launch, far too late to make some changes they wanted.

    I guess it’s a bit like bridge construction vs building construction. You can build a building 1 floor at a time if you have too. Each floor can be a success unto itself and each floor can build upon the others. But a bridge has to be built all the way before it’s usable. Deep cycle = Bridges. Agile cycles = Floor by Floor buildings.

    You and I seem to agree on the idea of getting as close to reality as possible. I hope other project managers/creative directors/producers share that.

    Copy & paste the code below to embed this comment.
  9. just read the article last night, showed it to my back end girl,
    she installed it, and we set up a project i hope to sign tomorrow.

    so far its great for the two of us collaborating, we work remotely,
    and it really beats a huge thread of emails which never really present a
    final and collected project.

    i do have my reservations on how the client would feel, and i probably will not show it this time around. I think some very basic CSS positioning such as MENU: is aligned on the left and a HEADER bar would really help the client to visualize the project. oh, and REALLY large disclaimer stating “Design has not been addressed in these Wireframes”

    Copy & paste the code below to embed this comment.
  10. how many designers does it take to change a light bulb?

    f*(& you, im not changing anything!

    Copy & paste the code below to embed this comment.
  11. Walt, you can get the PHP Wireframe app at It’s down the bottom of the page. The demo link isn’t working, but the download link is.

    Copy & paste the code below to embed this comment.
  12. I did like the article on Scope Screep by Hal and was impressed w/ some of the “thoughts” behind the subject…

    That said I have one obvious comment—and this will surely get me stoned by CF’ers—“ahem, not everyone out there uses ColdFusion.”

    That also said, I can tell you from working w/ smaller, mom & pop clients, that as long as I’ve been fighting the use of templates and the like I’m finding more and more clients just point me to sites they like and say, “Can you do something like this that isn’t this exactly?”

    Hmmm, a lot like “...reinvent the wheel but make it look just like this wheel here but don’t do it exactly cause I want to be different…” Err, something like that I suppose is how it goes.

    Maybe I’m way off in left field here so I’m gonna shut up for the time being. Just wanted to say the article caused me to think and at the same time I realized that there are quite possibly a lot of others out there like me that lose a lot of time, and therefore money, when the client thinks they know what they like but doesn’t.

    Okay, now I’ve confused myself about what I wanted to say. Pardon the intrusion—your reguarly scheduled discussion will resume, already in progress.


    -_- D.

    Copy & paste the code below to embed this comment.
  13. Scope Creep never really disapears, it just changes into something else. Because once the client knows EXACTLY what he wants his site to look like and feature - he will start complaining about pixelwidths, non-standard fonts and the rest of Browser 3.X many faults.

    This is true for clients that are used to work with print. Meaning that they usussally have a pretty good idea what they want - and once that lightbulb goes on above their pointyhaired heads, they refuse to accept anything else. Try to explain why it won’t look the same in every browser; “it does in print”.

    I don’t think we can ever get around clients with little or no understanding for the diffrences between what they want, and what they need. Templates, wireframes, specifications, styleguides, contracts and note-taking will only go so far. And the expectations, or the understanding, from the client are never the same between projects. It seems futile… on a case to case basis.

    Copy & paste the code below to embed this comment.
  14. I work as an application engineer for a large dutch bank and our ICT dev. dept. recently adopted DSDM, Dynamic Systems Development Method. Some of the aspects mentioned in the ALA article are integral parts of DSDM, in fact the whole method might very well apply to web design as much as to software engineering.
    Check out for more information.

    Copy & paste the code below to embed this comment.
  15. Ronald mentioned DSDM ( As a consultant in business intelligence i’m used to work with the kind of clients who are described so vividly on the firts section of the article.

    I use DSDM techniques (or its principles perhaps) a lot and it gives very satisfactionary results.

    What you agree on is a fixed time and fixed amount of money for a development cycle, you prioritise needs, and then you try to get in as many ‘must have’ needs in that cycle. If time is left, you add some ‘should have’ priorities and then you deliver a working project at the end of the cycle.

    End-users are an integral part of the cycle, so the linking pin with the client is always there.

    In my experience as a consultant this avoids scope creep in its negative conotation, but is very helpful in formulating the real functional specifications along the way. The fixed time frame forces decisions.

    This is a very rudimentary description, for more information do check out http:/

    You can apply the same principles to web development projects, it is not about the development technique, but about giving answers to business needs that are hard to formulate for the client without seeing a working visualisation first.

    Copy & paste the code below to embed this comment.
  16. The version of the joke I heard was:

    Q. How many designers does it take to change a lightbulb?

    A. Does it have to be a lightbulb?

    Copy & paste the code below to embed this comment.
  17. It’s actually an old advertising joke.

    How many copywriters does it take to change a lightbulb?

    A: Does it have to be a lightbulb.

    How many art directors does it take to change a lightbulb?

    A: We’re not changing a damn thing.

    Copy & paste the code below to embed this comment.
  18. In my experience Project Management has a devil of a time integrating Scope Creep. I agree with the author: scope creep can and should be embraced because it is really nothing more than the evolution of an idea. How many of us have worked on a “side-project” with someone that hasn’t morphed/evolved into more than we initially dreamt about? Probably never.

    As we play with the softare we realize there are data connections and paths there that were not at all apparent when we informally scoped the project out. And I’m not convinced Business Requirements Documents are any more formal than informal discussions - they’re just written down in a document and signed off by the client and product/project manager.

    Cutting to the chase: has anyone been able to, or worked with Project Management software, than can adequately reflect the important role of scope creep and integrate that into the plan? We need project plans to keep us focused and measure progress: but they can become more damaging than scope creep because they can so easily invalidate good design ideas a “scope creep”.

    Seems to me we need a better model or paradigm of project management that embraces scope creep and redefines it as scheduled development.

    Copy & paste the code below to embed this comment.
  19. Why, oh why, is this craptastic forum still here?

    Copy & paste the code below to embed this comment.
  20. Rather a refreshing forum style if you ask me - with some intelligent, well thought out pontificating (as opposed to the above mouth-off!)

    What I actually wanted to say was more along the lines of agreeing that its the designers, (who are not always the developers, but usually are) who need to be more responsible for leading the client - once they have figured out the reason for the site in the first place. The designer has to keep asking - does this do what we the client/user wants it to do?

    As both a client and a designer, I have seen it from both sides.. my developer did not design enough (or talk to me) before he started coding, and then, well, it was too late to do any major structural changes.. hmmph. In fact I was still tying to negotiate exactly what we were going to do - I had only shown him a 2 page graphic mockup, when he had already gone down the code road!
    (Not to mention that I found him through elance - and his English wasn’t bad for a Ukranian!)

    Copy & paste the code below to embed this comment.
  21. This is fundamentally flawed. Inasmuch as change is a constant, creeping features are a fact of life. But embracing them as described results in a useful project that is years late (as opposed to a useless one delivered right on time).

    The correct way to handle alterations of scope is to reflect the change in your deadlines and costs. “We can give you new feature Foo if you want it, but it will take an additional X days and Y dollars—but if Z-Corp thinks it’s worth it, we can make it happen.”

    Don’t pander to their whims. Be open to change, but be honest about what impact their changes are having on the project—after all, they (the company employee[s]) is/are responsible for this project’s success to their manager, president, CEO, or Wall Street.

    Copy & paste the code below to embed this comment.
  22. I’m paraphrasing: If the clients knew what they wanted, would they need us?

    Sure. I might know what I want in a house, but I’m not gonna build the thing. The hardest part of scope creep is getting clients to pay for it, and we (where I work) haven’t gotten that down yet, either.

    The biggest rub seems to be flat-rate bidding vs. hourly. We say we will design a site for X amount of loot and it will include Y features. As we proceed, the scope creep kicks in and next thing you know, we might as well work for free. We’ve tried getting a grip on this by using change orders, but it’s not a perfect solution.

    My thought is, if we’re going to bid a flat rate, it should be high enough to cover scope creep. Bidding jobs at an hourly rate seems to freak out the client, so we rarely use that approach.

    When I was a photographer, even if I did bid the job at an hourly rate I pretty much summed up what the project would cost—how much time, film, etc., so the client knew what to expect. Even so, there were always those clients who wanted to push it. “Say, while you’re at it, could you shoot this and this and this?” As if the extra time and material meant nothing. My pat response was, “Sure, but it will cost this much extra.” Sometimes they said OK, sometimes not, but at least we knew where we stood: No free scope creep.

    Copy & paste the code below to embed this comment.
  23. This forum sucks ass

    Copy & paste the code below to embed this comment.
  24. yes it does suck ass!

    Copy & paste the code below to embed this comment.
  25. Kevin just ran out of the room His mom called

    Copy & paste the code below to embed this comment.
  26. This forum is like writing notes on a napkin and passing it around a table. It’s a mess, and someone needs to spill a drink on it quick.

    Oh, is there any reason this article isn’t in the list of previous articles?

    Copy & paste the code below to embed this comment.
  27. Hey…

    “Anonymous”, “Irritated beyond belief” and the like…

    Okay, great—we hear you think it sucks.

    We hear you think it’s a drink napkin.

    We hear you have tons of negativity.

    Great, now shut it or mention something constructive.

    What will make the “list” better? What would you like to see diff about it?

    Not my place to point this out, so I’ll move on BUT what’s your problem anyway?!

    You don’t like the list—LEAVE!

    -_- D.

    Copy & paste the code below to embed this comment.
  28. My apologies to the rest of the “List’ers” and to Zeldman and et. al.

    Silly me to get drawn into their “attention-grabbing” tricks.

    Love the site, love the work, love the thoughts and glad it is here!

    -_- D.

    Copy & paste the code below to embed this comment.
  29. ...this lightbulb is best changed using Right Hand 4.7 and stepladder 1200 x 600…

    Copy & paste the code below to embed this comment.
  30. I guess I missed this month-old article. Ah, well… if anyone’s reading…

    I agree with Frank Siraguso and Corporate Slave as to how to handle fixed-price bids and scope creep. One thing I *haven’t* seen mentioned - which may be due to general client unwillingness to accept such a thing - is a flexible scope and all that goes with it.

    That means you have to present the basics, and get them nailed down as much as possible - “here’s what you say you want… here’s what we know now… here’s what we’d suggest…” These are the fixed items. Put in a section saying “here are some things you may think about… here is some blank space for you to think (think scheduling here)... and here are our ‘final’ prices”.

    Those “final prices” follow the “final schedule” in that they’re both *ranges*. This worked VERY successfully on a number of projects that I’ve driven. It’s worked as an estimating tool where it was obvious that Holy Creep was going to be a factor. You have to account for your time and the client has to feel safe that they’re not going to be abused on cost and schedule. You have to let them know that X is going to cost Y and add Z to the schedule. BUT it’s all been factored in originally.

    One project showed just how good our estimating skills had gotten - came in dead center on the costs and scheduling. And that included creep. Something to consider.

    Copy & paste the code below to embed this comment.
  31. please help…
    what is the meaning of scope creep?

    Copy & paste the code below to embed this comment.
  32. x_ash,
    When getting clients who don’t know what they need to tell you
    what they need the result is ... scope creep

    Copy & paste the code below to embed this comment.
  33. “If the clients knew what they wanted, would they need us?”

    Copy & paste the code below to embed this comment.
  34. Sorry, commenting is closed on this article.