Building Bridges

I have often used the analogy of building a bridge to explain to business colleagues the difference between Rapid Application Development (RAD) and Waterfall.

Lets say that we are in the middle ages and the Mayor of Kingston-upon-Thames is evaluating whether or not to build a bridge over the river to the north side, to replace the current ferry. The whole area has been growing rapidly and a bridge at Kingston should give his town a lead against competing local towns like Ham and Richmond (who also have their own ferries).

However, building a bridge presents problems. Firstly, the bedrock north and south of the river are very different. Secondly, the river is still tidal at this point and its path continues to vary across the floodplain. Finally and perhaps most importantly there is no guarantee that the projected growth in cross-river traffic will indeed materialise or that people will wish to cross at this precise point, rather than further up, or down, river. A new bridge could prove an expensive white elephant and divert much-needed town resources away from other projects. The increased local taxes required could also scare the very businesses he is hoping to attract away to other local towns.

Option 1 - Waterfall

Waterfall, as a methodology, is all about building reliable systems. At each stage of the lifecycle, the results are correct. The Mayors engineer believes that - when building a bridge - the result needs to be safe, sound and capable of lasting for decades. He recommends a design phase, which includes thoroughly testing the bedrock by driving piles and developing ways to limit the future variance of the rivers course. During the build phase, the bridge would be tested to ensure it can take the loads that will be placed upon it and to deal with high winds or flood conditions. The engineer confirms that each stage would only start once the previous stage had been proved correct beyond reasonable doubt. The stone bridge will take five whole years to build (with a high upfront cost commitment). If the project were ever stopped, the value tied up in phases to date would be lost. The engineer reminds the Mayor that a collapsed bridge would not help his place in history!

Option 2 - RAD

RAD, as a methodology is all about building relevant systems. The argument runs that it is better to be there quickly with 80% of the functionality in 20% of the time, so as to take full advantage of the business opportunity. The Mayors political advisors recommend the RAD option; to lay a pontoon bridge first alongside the existing ferry. This can be achieved in just three months, using a series of boats with a makeshift road surface and swing bridge lock for river vessels to navigate. The pontoon bridge allows the business model to be tested very quickly; If the expected benefits materialise, then further iterations of the bridge can be constructed later on. Sounds good, but of course (overall) the costs will be higher than waterfall if a full, stone bridge is ultimately required. In the meantime, if the river changes course, or floods impact the area, then the pontoon bridge will be washed away. His chief advisor reminds him that a bridge five years from now would not help his re-election prospects two years hence!

The Mayors selected option

Hmm. Interesting, isnt it. Not a clear-cut decision. There are good arguments for either approach. The Mayors decision will ultimately depend on (a) how sure he is of his own vision, (b) his financial and time constraints and (c) how changeable these factors are likely to be over time. In short, he has a trade-off decision of relevance vs. reliability.

Turning the analogy onto Intranet Projects

In the Development Methodology chapter of my (free to access) Intranet Portal Guide, I explore these concepts in a bit more depth.

However put simply the answer for you will depend largely on how sure you are of your vision, the support of stakeholders, the availability of resources and the degree of change in your organisation and its requirements.

If you are operating in a stable business environment and are well funded and supported, then waterfall offers real benefits. You could establish an Intranet Portal that is well founded, scalable and secure. If not, then RAD could offer you the means to make some progress now at low cost and use the results of your early work to build a stronger case for future investment. It also allows you to vary the approach or begin again should circumstances or requirements change.

Most Intranet evangelists will find themselves perhaps in a mixed situation, where there is support and funding but there is also the risk of rapid changes to the underlying business environment and requirements. Here, I would recommend a mixed approach: Use a waterfall project to establish the underlying portal infrastructure (as this platform will be the bedrock on which you will build and needs to stand the test of time). Then use a RAD method to build the content and applications (developing solutions that are timely and relevant to businesses operating in a fast-moving and competitive environment).