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).