Home » Discover » successful web development

Commercial web development has been around for more than 10 years. As an industry, we are still fairly young when you consider others that have been around for centuries. But our relative youth as an industry is no excuse for not doing better. From the number of sites that have been rebuilt for clients, it's clear that there is still a lot of poor quality work being done and this affects us all. It means clients are more wary and less trustful of web developers. Anything that tarnishes our industry can tarnish all of us individually. This leads to the obvious question - what's the answer? Having tried, trusted and standard approach would go a long way to helping avoid the mistakes we see over and over again. Ie. a web methodology. However, finding a methodology that works for web development is not easy and making it work is even harder.

Back in the heady dotcom days as the Development Manager for a team of 20, this was exactly the dilemma I faced. This article covers the issues that arose and how we as a team went about trying to resolve them. What came out of this was the successful adaptation of an existing methodology for web development.

The Symptoms
There were a number of factors that combined to force me to make a change in the way we did things.

First and foremost, projects were constantly going over time. There wasn't a specific reason for this, each project seemed to have it's own particular issues. For some it was the client changing their minds, for some it was us interpreting the requirements differently to what the client expected, for others it was a simple underestimation of the work required. Regardless of the reason, the end result was the same. Projects that go over time go over budget unless the client is willing to pay more. It also impacts new projects.

The more this happened, the worse things got until we had a situation where almost every project became high risk and suffered from scope creep, low morale and unrealistic deadlines.

The answer was pretty simple, we needed a better way of doing things, ie. proven way of delivering projects on time, on budget that met client's needs AND would fit in with our culture.

We needed a methodology.

Adopt, Adapt or Build Your Own
Once the decision had been made to find a better way of doing things, there were three paths we could take.
adopt an existing methodology
adapt from an existing methodology
build our own

The development team were divided on this issue. Some believe we should make it up ourselves, others said we should avoid re-inventing the wheel. It was clear we had to do some research to work out which was the best path for us.

The development team were divided on this issue. Some believe we should make it up ourselves, others said we should avoid re-inventing the wheel. It was clear we had to do some research to work out which was the best path for us.

At the time, there were no recognised web methodologies (although from recent research the situation hasn't changed much). So, for adopting or adapting, we had little choice but to look at the existing software methodologies