Planning and Estimating for Web sites

Here at LevelTen we have a few book clubs going on. Right now, one of the books we are reading is Agile Estimation and Planning. LevelTen is in the process of implementing an iterative development process which seems to make great sense for small to mid-level Web projects. Web projects are strange beasts. There are out-of-the-box tools that provide a ton of value. Still small firms with small budgets often have need for custom development that is often prohibitively expensive. The tools to do great things cheaply and quickly just aren't there yet (but progress is being made rapidly). Complicating things further, even now nobody has a strong grasp of what a Web site should do for a company. More than a ten years after businesses seem to have universally accepted a need not only for a Web site but the need for a Web site to be an integral part of the business, nobody is clear-eyed on how best to use Web sites for businesses. Ideas like social media, many-to-many publishing, SEO, online branding and marketing are great but implementing these ideas correctly (i.e. a manner which yields measurable returns) for a particular client with a specific budget is hard. There are lots of great ideas and great things people are doing, but there is a lot of learning and experimenting to do still. The book mentions that 2/3 of tech projects significantly overrun cost estimates, more than half the features in a project are rarely used and the average project exceeds the schedule by 100%. Web dev companies face these problems all the time. The most successful ones are initially successful because of a White Whale, a single highly profitable client to offset the costs of poor planning and estimation on other projects. Companies that have funded IT projects are used to delays and overruns, however, firms that hire development of low and mid level Web sites are generally unfamiliar with the difficulty in delivering on-time, on-budget and working projects and they have very little tolerance for delays - even ones measured in days - or cost overruns measured in hours. The trouble then becomes that the client often has sky-high expectations, initially an unclear understanding of the value of the features provided, a low budget and no tolerance for delays and overruns. That's not a recipe for success, but like it or not, this is a common case. I'm beginning to really believe that the only way to keep developers from taking on unprofitable projects and allowing clients to only pay for features of value is to develop iteratively. Customers see returns of value each and every month instead of a large delivery at the end of a long cycle. By prioritizing features of value and deploying features iteratively, both the developers and clients (and the customers of clients) can focus on things that return the most value as soon as possible. The process of delivery by feature allows developers to assume significantly less risk of uncertainty and complexity up front. The promise is that this is a win-win process of development. This methodology has piqued my interest, the tools we develop in and the clients we have seem perfect for this kind of development. I'm looking forward to really immersing myself in this process.