Conrad Weisert, November 14, 2007
©2007, Information Disciplines, Inc.
NOTE: This article may be reproduced and circulated freely, as long as the copyright credit is included.
"I agree with you in principle, but this project is so critical that
we just don't have the luxury of following the methodology."
- a recurring management cliché.
- a recurring management cliché.
I recently attended a major conference on I.T. project management and requirements analysis, sitting through quarter-day presentations by eight experts in the field. At the end I reflected on what I had just heard that was different from what I would have heard at a similar conference thirty years ago: almost nothing!
The conference attendee from 1977 might not recognize a few terms like PMBOK and agile and might be awed by the quality of the presentation slides, but he or she would be well acquainted with the concepts, the anecdotes of success and failure, and the expert advice. The inevitable conclusions are:
Of course we don't all have that knowledge and experience, but the organizations we work for have that institutional knowledge (or did at one time). Our bright younger staff members can follow our organization's written methodology1 and, if necessary, take one of our organization's in-house courses to acquire the needed competence.
So why are today's managers attending these expensive and time-consuming conferences and outside courses? Why do their bosses pay for them to do so? Any why do so many projects keep failing?
One reason is the lack of organizational memory. Another even bigger cause is the lack of management discipline.
When we know how to do something right and yet persist in doing it wrong, we probably lack management discipline. We may understand the validity of the principles we've been taught and we can pass an examination on those principles, but when we have to apply them we're still tempted to take shortcuts. We understand the principles intellectually but not emotionally. Those principles may be valid theory, we may reason, but we're facing a practical crisis.
The silly cliché at the top of this article is repeated somewhere almost every day by some straight-faced executive, who reassures us that we'll follow the methodology on our next project. But that next project never comes. By the time we've recovered from the wreckage of our current project the next one is just as critical and we once again have to set aside all discipline and
Roll up our sleeves and do whatever it takes to get the job done.
- another management cliché
Rather than following the processes they or their predecessors already knew about, many executives who become impatient with project failures adopt one or both of these tactics:
Problem solved! (until the next urgent project)
After several iterations of those cures followed by more compromises, frustrated managers may be receptive to one of the radical new methodologies that reject discipline altogether. If you just do away, the radical methodologists assure us, with project planning, requirements definition, and most documentation altogether in favor of an iterative agile approach, then everything will turn out just fine. Sure.
Some final observations
Obsolete assumption by the experts
Although using packaged application software products has become the mainstream solution for today's user organizations, just about every lecturer I've heard recently has assumed that every project is going to build custom software. Experienced managers know, of course, that a project that will install a major application software product demands rigor in both project management and requirements definition.
A dissent— November 18, 2007
I now see the basis of our disagreement. You completely miss the point of agile, which requires:
There seems to have been a recent terminology shift from "systems analyst" to "business analyst". That's probably a good thing, since it implies a clearer distinction from some popular but vague developer job titles such as "programmer-analyst". On the other hand a new term may reinforce the misconception that rigorous requirements definition is something new.
On this web site the two terms are equivalent.
Return to IDI home page
Last modified November 17, 2007