Tripping Over the Waterfall

Many designers, when they get a strong business process around their studio practice, like to stick to the waterfall. There are clear boundaries for how each deliverable is presented, the client has a set amount of time to respond with feedback, and everything hums along on its merry way until the final piece is printed, goes live, etc. For trivial projects, the waterfall is just fine.

Then there are the rest of your projects: the ones that seem to veer off cliff after cliff of unconsidered demands. The projects that strain, and very often break, the carefully laid schedules and plans that protect you and your client from late work and overbilled projects. Waiter, did I order the scope creep du jour?

Most often, I've been watching these situations arise because the actual deliverables -- the Web site we were tasked to create -- was simplified into a list of pages. Such an itemized list showed a fundamental misunderstanding about what we were tasked to create. Not a Web site. A Web system.

Web site, as previously defined: a collection of static pages, i.e. brochureware. Web sites today: Web systems. From this day forward, we should be talking about every Web project we initiate like we're creating software. We should just be calling it the World Wide Desktop, everyone will get thin clients, and we'll all be leaning on our DSL connections for extra bandwidth for those 28 megapixel JPGs as our background images.

But, wait: did you get into the design business to create systems? At first, you may have wanted to simply design on the surface level. But now, instead of skinning pages -- which is much akin to thinking about how you'd craft a series of posters -- we're creating little custom applications that people use on the Web. These little organisms live, breathe, and evolve at an exponential rate. Soon, they'll be set up to write our blog posts and brush our teeth. People in the UX and Web design and development community have been living this reality for some time, especially with those big transactional systems that are the future of the Web's next iteration. It's just that until now, the smaller-scale marketers of the world have been shielded from it. (I don't think you need to convince Amazon.com or Google about this reality. Most major corporations wrestle with these issues on an hourly basis, as they start to drink the Cloud Services Kool-Aid.)

I've been having conversations about this fundamental shift in lower-tier Web design shops so often, with all stripes of designer and project manager, and with such passionate force -- since any designer who's lived through these kinds of projects has the battle scars and nervous twitchiness to prove it -- that I feel like there's some sort of secret society layered beneath our aesthetic graphic design culture, waiting to admit you with open arms and a Heineken. This subculture is limned by war-torn heroes ravaged by shifting browser targets and the never-ending salvos tossed in the the PHP / ASP.NET Wars.

We should get special badges, or pins. I do like those tiny lacquered pins.

But I digress. What I really meant to talk about was tripping over the waterfall.

I'm using that term to mean: Thinking that you can accomplish a project using a waterfall approach, and discovering through painful and expensive iteration of business strategy, functional scope, and user experience input, that you can't even get past square one. By the time you've failed hard out of the project, and often at the cost of losing the client, there's nothing tangible because you never got past design phase. Call this Big Design Up Front with No Code to Show (BDUFNC2S). You bounce back and forth between design and requirements, with no real progress forward. Your clients iterate their thinking through your process instead of your process narrowing their thinking to a build-ready result. There's so much complexity in the system, they can't even begin to articulate it except when you begin to break it down into digestible chunks. Then the chunks get thrown up and re-digested, over and over again.

How do you avoid this dreaded tangle of a scenario, especially when you're creating a small-scale Web system / marketing application? Here's a few methods I've used or observed colleagues using that seemed to work pretty well:

1. Scope your discovery, user experience work, and technical specs independent of design and development. Do the planning work in an iterative manner, but build your site within a controlled waterfall schedule on a separate budget and estimate.

Many clients like to make apples-to-apples comparisons of Web design and development estimates, based on a list of requirements or "features", to then select their vendor. This is dangerous, because you don't know if what you scoped as features will hold, time- and cost-wise, once they're shaped into the right user experience recommendation.

So, sell your clients on working out most major user experience details before you even touch front-end design and development. This will allow you to accomplish a number of scope-controlling activities in a feedback loop with your clients, iteratively, without the risk of bringing UI design into pure user experience design considerations.

This approach also puts you in a much stronger position to enforce change orders for major scope creep past your approved wireframes, and ensure that your estimate for design and development isn't wildly divergent from the real hours necessary to build the system.

I think it's tough to sell a client on this scenario until you've given them a taste of what strong UX thinking is... but once they see the value in it, they generally go all the way. Besides, if they like the UX but want to go somewhere else to do the design and development, you won't get hosed. Asking for a price up front on a large-scale Web system, instead of a ballpark estimate with enough wiggle room to control any major scope creep, is just plain irresponsible.

2. Or, on a smaller project, don't do the above. Set up your budget so your client works out their every last whim and vision against one design, while rapidly prototyping the last few comps in a functional build.

When working on smaller projects, it can make sense to iterate the design work straight into the functioning site, as long as you have boundaries in the project estimate that specifically quantify what the client gets. Some of my colleagues at the local firm Design Commission take a long-form, single-concept design approach to their interactive projects; they start with one comp and work with the client over a series of rapidly developed screen design changes to evolve their work into the final result.

This process makes a ton of sense, as long as you can stand going through a large round of changes collaboratively, with a client closely in tow.

3. Your approach?

I'd love to hear some tips from your experience of how you've been able to bring agile methods into your work, and provide them to your client in a way that doesn't hose your sanity and budget. Especially of interest to me: ways that you can attempt to get more agile about developing Flash applications and other large-scale systems without bouncing your clients into scope questions when you're too far down the path, triggering snowball effects that can crash your timeline and budget.

Comments

[PM Hut]

Blaming the waterfall method for all the evil in this world is typical these days...

I read on a lot of blogs on how Agile projects are the antidote against Scope Creep, simply because they're iterative.

I believe that the reason for a scope creep is unclear requirements, mainly because of an informed/uneducated client and/or a bad Project Manager that doesn't communicate well. Methodologies are really not the solution.

[David Sherwin]

Hello PM Hut:

Check out this great piece in the most recent A List Apart issue about how Agile methods are become more appropriate for designers creating Web systems:

http://www.alistapart.com/articles/gettingrealaboutagiledesign

Also, read this article for working designers/developers on managing scope creep: http://sixrevisions.com/project-management/eight-tips-on-how-to-manage-feature-creep

Their tip #1: Accept that scope creep will always happen. Tip #2: Plan the project well and observe the client's level of understanding of the process you're about to go through.

The comment string on that article is also very valuable.