Promises Unkept

I l @ ve RuBoard

There are far too many Web development horror stories, and over the last seven years each of us has walked customers through some serious trust issues raised by a previous developer. This is not an easy process, but it is definitely worth it. Customer trust is everything, but in traditional web development methodologies, such as they were, it was difficult to cultivate. It was as if the best project managers were those who were best at lying to customers about the status of the project. In fact, the reverse should be true.

Keeping the customer out of the development process destroys trust.

Early Web projects would start with a honeymoon phase, when the developer was first hired . Then the customer would request changes to the project, content development would lag, and developers would begin to worry about their estimates and how much functionality was promised . As the project started to slip, disagreements would develop on what was and what wasn't included in the project.

Then would come the divorce, sometimes before project completion, often immediately after the Web site launch. This meant that either the developer would be stuck with outstanding work to complete or that the customer would have no support or maintenance for its site. Not surprisingly, customers rarely awarded any more contracts to that developer. If the developer did stick to completing what the customer perceived as outstanding work, this would generally bite deeply into any project profit. Nobody was happy.

The most likely reasons for the falling out between customer and developer were

• Financial and estimating problems

• Failure to deliver on time

• Poor quality of work or poor communication

Financial and Estimating Problems

As described in the following sections, money problems were a factor for three main reasons.

Competition

The Web development industry was incredibly competitive, with thousands of development companies springing up in basements everywhere, forcing down prices and project quotes. Beyond a handful of publicly traded, "million-dollar-minimum-project" companies, however, the rest competed on an even playing field, and customers could not see the quality differences between two developers in a basement and a seasoned team of 20. This situation is now improving, with customers who have had bad experiences beginning to understand why and realizing they were comparing apples to oranges.

Such a change in attitude is a slow process. During the fevered dot-com days, development conditions never improved because, despite the failures, salaries continued to increase. Indeed, there was a time when a programmer with six months' experience and a basic grasp of Visual Basic could demand and get $60K to $70K a year.

Bad Estimates

Web project estimates were horrendous because many Web developers were cowboys or heroes. Projects often depended on programmers running in at the end and saving the day by working crazy hours to finish. Unfortunately , many of them used this as the basis for all time estimates going forward. If you asked, "How long would it take to build an atomic bomb?" they would actually have an answer: "Oh, I could do it in a day or two if I had to." This misguided optimism obviously compounded the problem of estimating.

In the early days of Web programming, developers were asked to write code that created simple things like web counters or display of a list of products from a database. We just used simple tools and unfortunately got used to them, much like working with duct tape and glue. The problem was that many larger projects continued to use these same technologies in the belief that the large projects were more of the same thing, just bigger. The idea that complexity would grow the project exponentially took the industry too long to learn. Developers cut their own throats by quoting far less than the project was worth and didn't find out how badly off they were until three quarters of the way through.

Poorly Defined Requirements

Web project requirements were poorly defined. Some projects started with flimsy functional requirements at best, which caused many problems. Most customers agreed to a fixed price for a fixed deliverable ; however, most deliverables couldn't be defined up front, so the fixed price became less definite. Customers took the widest interpretation of the project scope and developers began to realize that they had to take the leanest interpretation to stay afloat. Customers were thus left out of the development process in an attempt to reduce change requests and only brought in for major milestones. This led to their devaluing the work that was being done by the developers.

Failure to Deliver

Not only were projects delivered late but they were often not what the customer wanted. Insufficient customer involvement meant that the development team was making crucial decisions, without customer input, about how things should work, what was important, and what things should look like. This often meant that the development team, not the customer, was essentially making business decisions with little or no understanding of the customer's business processes and goals. Customers were receiving their Web sites months late and what was delivered wasn't what they thought they had initially requested .

Poor Quality and Communications

Quality was difficult to measure, especially by customers. Customers rarely appreciated the quality that went into a well-built Web site because they couldn't see it. They couldn't see that the naming conventions were adhered to, that code was properly commented, or that functions had robust error-handling capabilities. Nor could they see that the designers had spent time reducing the file sizes of the graphics so that they would download faster or that the programmers had spent countless hours trying to ensure that the design of the Web site appeared consistent across multiple browsers.

Unfortunately, because the customer couldn't see the results of hours of high-quality development, it was often the first thing to be dropped from the project. However, poor quality wasn't hard for customers to see and they were not happy to pay for it. Even if they did pay for it, every battle they won for extra scope somewhere led to the developer secretly making up time by reducing quality somewhere else.

In time, customers would experience the effects of poor quality but their developer would refuse to offer maintenance contracts for ongoing changes. New developers would recommend rebuilding the Web site as this was most cost-effective solution, leading to the customer feeling betrayed by previous and current developers and resenting the money " wasted " on the Web site. This breakdown in communications was a clear recipe for disaster.

I l @ ve RuBoard