Big problems can arise even before the project starts, way back with the Request For Proposal (RFP) from the prospective client. If you're lucky, the hard-working folks in New Business Development solicited solid input from the right in-house resources and created a budget and schedule that are actually possible to achieve.

But did they get a technical assessment from the appropriate engineer? Have they really considered internal resource needs, the client's firm delivery dates, and budget constraints?

A proposal writer may know exactly what it takes to build a client its very first US$500,000 e-commerce site, but what to do with those clients who already have a site and now want the front end integrated with their fulfillment center's software? Or maybe their site was developed for a local branch, and they're looking to integrate their five remote offices - each with a different database - into one functional system. Are you really prepared to handle the client's unique set of problems? Has Business Development considered whether you have a uniform taxonomy? Do you have the equipment and software to actually tackle the job?

Perhaps the client simply wants a new look and feel. Seems pretty straightforward - except the whole site, including the navigational structure, is currently dynamically generated from a database. Is it possible to just change the visuals without changing the interaction and navigation? Unlikely. Does the client even understand the difference between information design and visual design? Even less likely.

Solution

Involve the right people early on. Get a producer, a lead engineer, and a senior visual or information designer to give the proposal a reality check, and make sure you understand any trade-offs. Remember the old equation: Clients can have it faster, cheaper, and better, but never all three at once. Two out of three is the most you can do.

In the case of a redesign, making something good into something better is often harder than transforming a bad site into something good or creating something great from scratch. Where do you start? You don't have the luxury of a clean slate, so you have to figure out what's working and keep it, then replace nonfunctional elements with something that not only works better, but integrates with existing elements.

Problem: Scheduling Mishaps

This problem, which I sometimes like to call "The Engineer on Crack," is often intertwined with the very earliest scoping troubles. Failure to solicit input from an engineer who has extensive experience with the exact type of system you need to build can lead to massive headaches. Suddenly, your engineers are implementing a 300-page database administration tool that takes five engineers six weeks to build, yet was only "scoped" as a five-day job.

Solution

Solve underestimation problems by using this simple equation at the outset. Ask an engineer, "How long would this take to spec and build?" Then ask, "Well, what if you weren't on the job? How long would it take some mediocre engineer to do it?" Then pose these questions to another engineer. When possible, apply a by-case fudge factor to each engineer's estimate, based on experience. For instance Bob's estimate plus 50 percent, Ted's plus 100 percent. Then take the average of all the results, add 10 percent, and cross your fingers. Note: This also works for visual designers!

Problem: Unrealistic Expectations

This problem, which first crops up in the Discovery phase and stretches right on in to the Concept and Planning phase, tends to appear when "pie in the sky" ideas - like the offhand remark, "Wouldn't streaming video be cool on this site?" - become mixed up with realistic goals of a feature set.

Solution

While clients may not get every last thing they want in this redesign, features that didn't make it into the final set can still be addressed ... later. Once a realistic feature set is defined and approved, I find the phrase "That's a great idea for phase two!" comes in handy.

A big part of setting achievable expectations is clearly defining your review cycles. Give the client enough time to give feedback, then make sure the designers have enough time to make changes. Be clear from the outset that you plan to listen and work with the client and act as their advocate. But after "X" date, a decision needs to be made or it will push back the schedule and effect the date of the final delivery.

I've actually had a client request they be "pre-wired" (their term, not mine). They wanted to know what they were going to see, the types of feedback they were expected to give, what the next step would be, and when everything was expected. I suspect this request stemmed from problems that cropped up with the previous design team's process. Working with gun-shy clients like this might mean a little extra work up front for you. The client may already be looking for signs that you don't know what you're doing, so it's up to you to earn back the trust and respect lost by the previous Web shop.