Web developers are a tough lot, willing to brave constantly changing technologies, competing “standards,” and tools that are often clumsy and dull. Yet brave as we are, two little words strike fear in the hearts of even the boldest of us, making us consider a change to a less stressful job-air traffic control, perhaps.
Scope creep threatens to undermine all our hard work, causing rewrite after rewrite of carefully crafted markup and code. In short, scope creep is evil. That’s the prevailing wisdom. But consider the results of four studies done over the last five years that show that as little as 20% of corporate software projects are successful. Prevailing, it may be, but is it wisdom?
Maybe what we need is a little heresy. Try this: scope creep is not only inevitable; it’s natural. As with other natural forces, when we resist it, it seems evil to us. It thwarts us, but scope creep is no more evil than gravity. Scope creep is the pejorative name we give to the natural process by which clients discover what they really want.
This puts our attempts at “requirements gathering” in a different light. Most project managers try their best to discover what clients want at the beginning of the project. They use meetings, questionnaires, personal interviews – and still, the most common experience for developers delivering a final product is customer dissatisfaction. It may come as a slap in the face – “this is no good” – or it may be couched in gentler terms – “you know what would be nice” – but the same message is being delivered: we aren’t giving clients what they want.
Maybe that’s natural, too – that failure to give clients what they want, a natural consequence of our failed conventional wisdom. So, let’s augment our heresy with a new claim: clients can’t tell us what they want until they see it. That’s why they don’t tell us what they want up front. They can’t! And if they could, would they really need us?
Are you starting to feel slightly more kindly towards those fumbling clients who can’t put their finger on what they want, although they can tell us quite nicely what they don’t like? These are the people who pay us to do what we love. And they need us. They need us to guide them from the foggy swamps of possibilities to the land of promise.
Fast prototypes#section2
Hmm…if clients aren’t to blame for the sorry state of software, that puts the blame uncomfortably close to…us. What’s wrong with the current picture is that as developers, we aren’t taking responsibility for successful software deployments. I’m convinced that this is not due to any apathy on our part, but rather a misunderstanding of our role. We are central to software development, no matter what clients think or our pointy-haired bosses say. We must create the system that reliably, predictably turns out software successes.
What system would that be? First, we need to recognize the inevitability – and even the desirability – of scope creep. Now, we must provide a safe environment for scope creep to occur in. A few simple tools can go a long way in providing an answer.
A “wireframe” is a simple, text-only skeletal version of the application. It is used as a sort of “booster rocket” to help us escape the leaden weight of our own assumptions about what clients want. Something magical happens when a client can click on a link. It stimulates their interest and engages their brain. Wireframes that do nothing but tell the client what this page will contain and has links to other pages is ridiculously effective, but wireframes can take lots of time to write and edit.
In the ColdFusion community, a “wireframe tool” is available for free download that takes simple text files that non-programmers can easily write and turns them into clickable wireframes. Setup is extremely simple, requiring only that you have ColdFusion Server running on a machine. There is also a PHP version of the tool freely available. The tool can be downloaded from www.bjork.net.
When I initially wrote the code for the wireframe tool, I only wanted it to help in the discovery phase of a project, but many have found that it is very effective as a sales tool. Because wireframes are fast and easy to create, they can be done in front of a customer. From our point of view, we’re taking the first step in discovering what the client wants; from the client’s point of view, we’re writing the application in front of them! If you do this with a prospect, you will definitely set yourself apart from your competition.
Improved communication#section3
Wireframes, helpful as they are, can only get us so far. Clients have to see the application in all its detail – and that means prototyping. Another tool (also free) can help us with this. The tool, called DevNotes, adds a simple, threaded messaging component to every prototype page. Using DevNotes, clients and developers can communicate with each other during the prototyping phase. Notes are saved into a database and are unique to each page. Here is a sample from a single page, showing how it can be used. (The two-letter abbreviations are user initials.)
HH: Where are we going to get the information on these products?
TC: I think Sue has a spreadsheet of all the product info. Is that right, Sue?
SD: Yes, but I get that from a database from the head office. You might want to use that.
HH: Sue, who could I speak with about getting that?
SD: Matt at X 125 can help.
Some notes we want to remain on the prototype. Others can be safely removed when the underlying issue has been dealt with. For example, if a client writes a note saying, “we’d like to see our logo in the upper left corner of every page,” you can remove that note once the change is made. A nice feature of DevNotes is that any removal only makes the notes disappear from the page; they remain in the database – something that is very useful in reconstructing how a decision was reached.
DevNotes is quite simple to set up and is available at my site, halhelms.com. There is also a version available at bjork.net that requires no database setup.
These two tools and techniques are remarkably effective. At very little cost to the client or us, 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.
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). The DevNotes are removed and the prototype forms the basis for our real application.
There’s an old story told about a little girl who is asked to spell the word, “banana.”
“I know how to spell it,” she explains. “I just don’t know when to stop.”
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”). Thus, we begin to craft a system that will make both client and developer successful.
[QUOTE] . . . 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”?).
[/QUOTE]
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.
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.
He mentions a PHP version of the Wireframe Builder which I’m having trouble finding and the demo at bjork.net doesn’t seem to be working. Anyone know where to find the PHP version or see a working demo? Thanks.
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
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.
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.
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.
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.
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”
😉
how many designers does it take to change a light bulb?
f*(& you, im not changing anything!
Walt, you can get the PHP Wireframe app at http://php-fusebox.sourceforge.net/index.php?fuseaction=downloads.main. It’s down the bottom of the page. The demo link isn’t working, but the download link is.
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.
Thx!
-_- D.
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.
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 http://www.dsdm.org for more information.
Ronald mentioned DSDM (http://www.alistapart.com/stories/scopecreep/discuss/#ala-951). 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:/www.dsdm.org
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.
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?
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.
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.
Why, oh why, is this craptastic forum still here?
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!)
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.
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.
This forum sucks ass
yes it does suck ass!
Kevin just ran out of the room His mom called
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?
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.
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.
…this lightbulb is best changed using Right Hand 4.7 and stepladder 1200 x 600…
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.
please help…
what is the meaning of scope creep?
x_ash,
When getting clients who don’t know what they need to tell you
what they need the result is … scope creep
“If the clients knew what they wanted, would they need us?”