| Working Within Waterfall | KEVIN RESCHENBERG
05-17-2006 |
Last week's post
talked a little about the Waterfall model for system development.
This model was introduced in 1970 by W.W. Royce, who
wrote that the basic model is "risky and invites failure."
This model was eagerly adopted by the IT profession.
Royce proposed fixes to the model, but those were largely
ignored in favor of the basic risky failure-inviter.
Even now, when some of the issues addressed by the 1970
model no longer exist, people still follow it. A few of
the many problems inherent in the model were listed last
week. But all is not lost. There are still ways of working
effectively within even a strict, basic Waterfall model.
First, as I'm sure you have noticed, there is wide variation
in levels of adherence to the model. You may find yourself
on a project that is scheduled using pure Waterfall principles,
but notice that they are not followed in practice.
They might be outlined in detail during the project kickoff
meeting and then promptly forgotten. This is one extreme
and it is not really a good thing.
Another variation is the calendar-driven project. The project
manager says that June is the month for the Design Phase.
In a pure Waterfall project, this means that all
design activities—and only
design activities—must occur
during the month of June. But in some projects, this
really means that any activity occurring during June is
labelled "design." "The program I'm writing is needed
to help me finish the design document."
This may be an example of a common situation—the
project manager doesn't really believe in the model and
is just acting under some sort of corporate mandate.
He or she may be a part of the conspiracy, allowing
whatever work makes sense and just stamping all of it
as "design." I've been on a few of these projects.
It's amusing to see how pleased everyone is when the
Design Phase ends exactly on June 30—right on
schedule!
Even if Waterfall is really being followed, we
should not just waste time. If we need to do something
necessary to advance the project, but it's not time
for that activity according to the schedule, we need to let the
project manager know. Most PMs will be happy to see that
progress is being made. In any case, we can always do
whatever preparation is necessary to be ready to start
the activity. (You might even consider coding and object
creation as one of those "preparation" steps.)
We can't sit on our hands and blame the schedule.
If you are a consultant concerned about losing hours because
you finished your task too quickly, don't worry. If
the Waterfall model is really being strictly followed,
there will be plenty of problems late in the project.
You'll be busy! And in the meantime, you could head
over to www.waterfall2006.com
for a good spoof of the model.
Applications Unlimited
Bill writes to point out that Oracle's plan
to continue enhancing PeopleSoft (and its other products)
comes with some big disclaimers to the effect that it
cannot be incorporated into a contract, it is not a
commitment, and it cannot be relied on to make purchase
decisions.
This appears to be standard boilerplate to protect
Oracle from being locked in. Similar wording appears in
various places on the Oracle site. But it's a reminder, I
guess, that Applications Unlimited is Oracle's plan
today. What happens in the future remains to be seen.
|
