B
bs866806
I have often used the analogy of building a bridge to explain to
business colleagues the difference between Rapid Application
Development (RAD) and Waterfall.
Let's 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 Mayor's
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 river's
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 Mayor's 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 Mayor's selected option
Hmm. Interesting, isn't it. Not a clear-cut decision. There are good
arguments for either approach. The Mayor's 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 chapter 16 of my 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 it's 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).
http://cncarrental.cn/html/Internet/20060929/31828.html
business colleagues the difference between Rapid Application
Development (RAD) and Waterfall.
Let's 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 Mayor's
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 river's
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 Mayor's 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 Mayor's selected option
Hmm. Interesting, isn't it. Not a clear-cut decision. There are good
arguments for either approach. The Mayor's 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 chapter 16 of my 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 it's 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).
http://cncarrental.cn/html/Internet/20060929/31828.html