Fear of Non-Progress
December 17, 2001 (updated September 5, 2002)
This article is divided into the following pages:
The Waterfall Effect
Tackle the Problem Head-On
Most middle managers love to see source code. They love to see reams upon reams of source code, the earlier
in the project lifecycle the better. This to them represents progress. If "90%" of the project code has been
written, then the project must be "90% complete".
The same managers balk at the notion of spending time up front gathering requirements, writing specifications,
laying down the groundwork for a project where everyone is on the same page. This to them is non-work, as
the project does not appear to be any nearer completion. Six months might have gone by without any code
having been written.
This problem is exacerbated by a common tendency to take a "waterfall" approach to development. All
the functional specs must be written, then all the design specs, then all the code. Then everything is
integrated in one big swoop, and integration testing takes place for the entire system, then user acceptance
testing takes place. The customer does not get to see any real evidence of progress until right at the end of the project.
"The customer wants assurance that you are following a low-risk process"
It's understandable that management balk and panic at the prospect of this sort of high-risk process. They
don't see any working code until late in the project. There is no sign that the project will be brought in
on time, even with the project manager's earnest-faced assurance that everything will "suddenly come together
on day 347 or therabouts". To the senior manager, this is a terrifying prospect, and understandably so.
Managers at this level need to see tangible progress, and they don't have time to learn the finer aspects
of process engineering in order to appreciate that the project really is on track.
Of course, it could be argued that they should at least understand the basics, because after all, they are in charge of a
software project. But does that mean that the customer should also be educated in the same way? And the "power
behind the customer", the moneybags to whom they must justify the project? The answer is probably
yes to an extent, if this was an ideal world - but of course in most cases it just won't happen.
Therefore, if the customer won't "play ball", or cannot reasonably be expected to learn our rules, we need to change our ball game to suit them. To translate that into English: the customer doesn't have the time or inclination to learn about software methodologies. We are the programmers, after all. They just want working software. So we need to give them that, and to actively demonstrate they we are in the process of giving them that, throughout the project.
The customer will want assurance that you are
following some sort of process (and a low-risk one at that), but beyond that they probably don't care about the details. All
they care about is what they are going to get, not how they are going to get it. That's your problem. The customer will make
appreciative noises and agree wholeheartedly that they need to know more about the process your team
are following - but then the next time you speak to him, it will be as if the conversation never happened.
Life is like that sometimes.
"Convey a sense of rapid development"
Fear of non-progress, then, is a real problem. Clueless managers (who really should know better) will encourage you
to leap straight into the programming. To them, code = progress, therefore coding = appreciable activity. If the
requirements gathering has taken too long,
they will push for you to skip the design phase altogether, and to just "start making some progress."
So what's the answer? How do you get those all-important requirements and design phases out of the way without
terrifying your own managers and the customer?
The answer is really in two parts. The first, and most important part, is communication, conveying a sense of
rapid development. We'll cover that
in a moment. First, though, it's worth reviewing the process itself, and examining an insidious problem that can manifest, even on projects that don't set out to follow a "waterfall" process...
>> Page 2: The Waterfall Effect
<< Back to Lifecycle