Web projects don't iterate, they use the waterfall method
In The Bottom-line of Prototyping and Usability Testing, How user-centred design techniques can make a cost effective workflow, Henrik Olsen commits blasphemy. He says that most web projects don't follow an iterative development process. Everyone talks about iterative development these days. How could Olsen say such things?! Yet Henrik's points ring true for me. I've talked to many web development professionals, and rarely do I hear stories about projects involving refinement and iteration of a product. Usually, projects are "greenfields", creating something new, or they involve a wholesale redesign, completely re-doing the application or site.

My own experience is that larger initiatives like ecommerce sites, extranets, and portals tend to follow a more iterative development cycle, but the more common basic web sites and smaller applications tend to follow a waterfall or mud-throwing type of process.

Olsen summed it up best when he said
"The majority of Web projects employ what we could call a no-nonsense approach to product development, where none but the most obvious steps from idea to the finished product are taken."
Many business people would say this "no-nonsense approach" makes perfect sense. Who needs extra steps anyway? The problem is that, generally, projects blow their whole budget and timeline in release one. They don't budget time or money for iterations (e.g. multiple prototypes) within release one. They don't have plans or budget for a release two.

In one of my presentations for development teams I advise them to listen for a warning sign related to project iteration that might indicate a product or project is ill-fated:

If the client says: “We’re going to put something out there and then get feedback.” you should ask the following questions to help assess project risk:

Q: How and when will they gather feedback?
If they're not sure or if they're just going to monitor complaints, then you're in trouble. Have they budgeted and planned for appropriate "feedback gathering" activities?

Q: Is there budget for the next iteration? Two iterations? Three iterations?
No budget often means no next iteration. So even if you get user feedback, you might not be able to do anything about it.

Q: When will the next iteration or phase start?
No timeline equals no real plans to fix anything. Clients rarely expect to find problems, so they don't plan on fixing anything. They see fixes as exceptions to handle if necessary.

Q: How long can users suffer if good usability isn’t there? What if it's really bad? What if the help desk gets a lot of calls?
If you can't move to the next iteration quickly, you could end up creating a lot of headaches for yourself -- not to mention negative brand impact, extra support costs and resistance to use the product in the future.

Q: How about just developing a paper prototype and getting feedback on it?
Rather than iterate product releases, which is costly, why not iterate within your release? Get user feedback on prototypes to accelerate your overall process and deliver a better product right from the start.

"Getting something out there and getting feedback" is often just an excuse for cutting corners on the User-Centered Design (UCD) process. Don't let your clients fool themselves into thinking they're being "iterative" when they're really heading for a waterfall.

Related:
- Joel on Software: Picking a Ship Date -- an excellent, realistic approach to managing software releases. If you're faced with "timeboxing" a project, you might want to consider Joel's thoughts on release schedules. It also applies if you're really and truly following an iterative lifecycle.

- BusinessWeek: IBM.com Looks for Big Improvements from Some Subtle Design Tweaks -- Quotes: "As we built a user experience map we decided we needed to focus on top to bottom information architecture," and "You can run into the trap of subjectively tweaking versus objectively tweaking,"

- UIWeb.com: Why Good Design Comes from Bad Design

[via Elegant Hack]