The creation of a web based application is often a sizable investment for any business. Its success or failure can have a major impact. In todays world, the website might be the business. How do the most successful websites and applications succeed? Why do others fail and disappear? How do we as web developers make sure our clients sites and applications are among those that are successful?

Let’s first take a look at a traditional approach to web application development. In this model the clients primary risk is their initial payment to the developer, to which they usually profess that they have too little resources to accomplish much. So after some back and forth you reach a consensus of what can be developed for a price that you can agree on. Then you begin the initial design, develop the application, deliver it, test it, and then maintain it. Regardless of how short or long this takes you get paid the same, except for out-of-scope items which you either (a) agree to do for free, (b) get paid for, (c) they get dropped. Once the system is developed the client could find that their business has changed or their requirements have changed and the system needs to be reworked. They may try to make this your fault or generally be upset about the success of the project. Either way, it doesn’t put you in the best of positions in terms of your relationship and future work and referrals.

Lets take a different approach, which follows a more evolutionary and rational path. One that puts you, the designer/developer, in greater control, but makes the client feel much more involved and appreciated throughout the process. It is more of a partnership relationship than a contract relationship. In this system you refocus the attention on the clients needs and business requirements more than on the technology and solution. You then setup and prioritize goals with the client. Based on the value of these goals to the client you outline the costs to setup the project, do the initial design, and complete the high priority value producing tasks that accomplish the goals. You then create the look and feel of the application/site in conjunction with producing the first component for the highest priority goal. At the end of this short cycle you produce a mini-application with this one feature that the client can start using immediately, while you go on to produce the next component. This way the client is constantly getting something they can use, provide feedback (good or bad), and see value in what you are producing sooner. This process is often called the agile method or more recently the evolutionary method. It enables you to early on in the cycle produce results, throw out what doesn’t work, and use what does work.

In subsequent articles I will go into more detail on each of the steps in this process. For now, though, think of your past projects. What process do you follow? How many times did requirements change during development? How much did you have to go back and “fix?” How much extra unpaid time did you end up spending during the sales, development, and testing phases?

Feel free to vent, comment, or share your ideas in the comments below.