Articles
Time & Materials over fixed scope/price for social web projects
Poorly predictable complexities
Sydney opera house, a beautiful piece of art, the Sydney's best known landmark and international symbol was started as a fixed-price, fixed-date project. Unfortunately, since it had no standard building time, it was impossible to estimate all the difficulties and complexities in advance. As a result, it took 13 years and 102 million Australian dollars to build, instead of 3 year and 7 million estimated – 330% time overrun and 1350% costs overrun!
In past the most common way of building web projects was a “waterfall model” with fixed price and fixed scope contracts. But in modern times, such methodology becomes too risky for a variety of new projects. In most cases, software development is not a mass production, but a new products development. It is rarely possible to build a system you've developed already for a new client or just clone some other system with all the same details. Of course, on a brand new projects (sometimes) you are able to copy existing approaches or and best practices, but it won't save you from dealing with something new or from scope changes. Requirements and scope changes – that is where agile development methods may help and save project from cost overruns or quality loss.
Agile software development methods are based on the assumption that any amount of upfront planning cannot predict all of the surprises that may happen along the way. In the IT industry there are always some unpredictable in advance technology limits you have to meet. Sometimes, developers spend more time on some features (even minor ones) than was expected and so by cutting down on the quality of other features (if it does not obey specs) in order to hit the overall deadlines. Usually, it is not possible to describe requirements on paper in such a ways that both the customer and developer will understand them in the same way. Even if we know the technology perfectly and the client is able to express their wishes in an extremely clear way, there is always the possibility of rapid and unpredicted changes in the market. Try to imagine, how new “cool” features of your business rivals may change the requirements of your project, or how requirements of some Internet projects changed after Apple released their iPhone or Youtube/Flickr/Facebook became popular: the market is really agile in modern days.
Agile methods based on “Time & Materials” contracts acknowledge the market and project uncertainties and try to adapt by building software in small and completely increments. Instead of one “big” project, you get number of iterations with a new build and a new project functionality/quality at the end of each. So therefore, the business could change the project’s direction up to the point of new efficiency at pretty much at any moment. Naturally, this approach is not very compatible with the idea of fixing everything upfront.
Misapprehensions about agile still run rampant in IT organizations: Agile teams do not plan. Agile teams skip design. Agile teams do not test. Agile means no documentation. It is actually not true and it is still possible to have quite an extensive planning phase, though agile methods recommend devoting it to prototyping more, than to thoroughly documented analysis. System design is not skipped but done in an incremental way, like a project is. Documentation is present and developed during all the development phases, so it reflects changing project requirements. Naturally, T&M (time and materials) is a most effective way for agile teams, but it requires some level of trust between the client and the implementer. However, some trust anyway needed when working in an area, where it is difficult to specify in advance, what is really needed. Fixed price/scope contracts might be able to protect a client from paying too much, but they are unlikely to help him get a system he really needs.
Sometimes the a good compromise may be to building a new system with a fixed scope/price contract for the first “prototype” and then go for T&M approach. However, it could be interpreted as the first iteration in the standard agile process.