Not long ago I read an article who's name was "The Iceberg Effect." You may be thinking that this article pertained to the aftermath of the Titanic ocean-liner incident, but in fact it was an article about the dangers of unbridled customer expectations.
In essence the article argues that it is necessary to ensure that the customer only "sees so much" -- as with an Iceberg which has as much as 90% of its mass below the water, and therefore is not readily visible -- so that the customer does not expect that just because she sees the UI elements in place that the functionality has been built to support it.
At Webglimmer, we tend to use a partially compartmentalized approach to developing our customer solutions. We'll take the database development, and the UI/UX development, and allow two separate teams to perform the required tasks. The DBA works with the project manager and sometimes the customer to develop a solid schema, and the UXE (User eXperience Expert) works with the project manager and again, the customer, to develop the proper UI and experience.
We then rely on the third team (which consists in part of the same people) to perform the development required to lash the two together. This buys us a loosely coupled solution with the ability to flex each piece as requirements change. They always do.
Now this brings us back to my ride on the back of the original author of "The Iceberg Effect." To use the above approach requires a significant investment by the customer, the project manager, the DBA, the UXE, and so on. Use cases, requirements and the entire experience should be documented as rigorously as possible up front to eliminate the dreaded scope creep that has killed so many projects or at least the deadlines of past.
The problem is that during development you will invariably need to make adjustments in your designs, strategy and approach -- usually because the customer changes his or her mind, or even more frequently heard is, "Wow! Now can we make it do this?" How do we avoid letting the inevitable customer drive to change from causing the dangerous 2 steps forward, 1 step back scenario?
First, learn to be psychic. Or at least, start learning to intuit the changes that you EXPECT customers to make. Plan them in. Then move on to deciding what changes YOU would make. Plan them in. Try to think of yourself standing and walking in the customer's shoes while never losing your ability to filter those features, and requests through your expertise. You may have built many solutions that bear a resemblance to the current project, even when a customer says that they don't want something -- if you've built it for 4 out of 5 other customers -- again, plan it in. Make sure that what you do is best for the client -- ultimately when told that their solution can't do something later, no matter how hard your try to explain that it was because of a decision that they made during development, they will blame you.
Next, learn to say NO! Okay, maybe your highest paying client will not take kindly to such a response, but saying something like, "Yes, but not now," will probably suit the bill. Explain to customers that you are thinking of the deadline, the bottom line and reassure them that because of the extensible (don't use that word) way in which you are designing their solution, this is something that you will be easily able to add later.
The Iceberg effect that I am referring to is in a word the "opposite" of the one described by the original author. By looking at a project without getting under the surface you may find yourself later wondering, "how did I miss 90% of this work when planning?" The Iceberg Effect.
Kudos to our original author who's name I cannot find for drawing such a astute metaphor.