Satisfying Requirements
(software project managers beware!)
Three short anecdotes to give software leaders pause for thought.
Case #1: Some years ago we were required to make a recommendation for
selection of a project management information system for running a large portfolio
of major projects. One of the software contenders we looked at, and rejected,
was a very expensive system of European origin. Subsequently we learned (from
the Wall Street Journal, June 9, 1999) that two companies had invested a great
deal of effort and money ($103 million in one case and $45 million of a projected
$250 million in the other) only to abandon it before getting any real use out
of the software. The product in question is described as "elegant though
extremely complex software that can monitor and help manage a company's every
move". Sounds attractive, doesn't it?
However, as one executive of the customer companies put it: "They expect
you to change your business to go the way the software works." The vendor's
response apparently was: "Although this is true, the cost of the change
is worth it because the software allows companies to operate more efficiently.
Indeed, the most important thing is executive commitment — it's not a software
project, it's a business transformation project." This is indeed a beguiling
argument. The way you need to work with software is not the way you would normally
do things manually. But if, at the end of the day, the software does not produce
the results you need, then it serves no useful purpose. And that is exactly the
conclusion we came to, fortunately without significant investment.
Case #2: There is an amusing tale circulating on the Internet that goes
something like this. (Since the author is unknown, we have taken some liberties
with the details.) A project manager died recently and was met at heaven's gate
by St. Peter. St. Peter said that the project manager's life was such that he
had the option of selecting either heaven or hell. The project manager thought
it over for a while and prudently asked if he could examine both before making
his decision. St. Peter agreed and the two of them floated down through the clouds,
past earth and into hell. The project manager was amazed to see people happily
working away at the latest laptops, using the latest software, while at the same
time eating, drinking, laughing and generally having a very productive time.
The two of them then floated up through the clouds up past earth and into heaven.
There everyone was dressed in white robes, peacefully sitting around, not doing
much of anything except reading, sipping tea and quietly chatting. Clearly, there
were no computers of any kind anywhere in sight. The project manager decided
that this was all well below expectations so he selected to go to hell. A few
weeks later, St. Peter was passing through hell with another candidate and came
across the project manager chained to an ancient-looking floor-model tower computer
producing indecipherable computer code on an old CRT screen, all the while being
whipped and prodded to produce results.
Seeing St. Peter, the project manager yelled out: "Hey, what happened?"
To which St. Peter replied: "What you saw was the demo."
Case #3: Some time ago, a software company was invited to provide advice
and recommendations for a highly distributed systems project. The market research
identified one particular possibility, but the vendor's licensing structure assumed
only one centralized instance of the product. The cost to procure the required
number of licenses proved to be prohibitive and the product was therefore ruled
out of the selection process. Some years later when there was some dissatisfaction
with the chosen product, the project team again investigated the marketplace.
This time they discovered that this particular vendor had changed its licensing
structure, because it realized the need to accommodate distributed configurations.
Of itself, this case is not particularly remarkable, but it does highlight
a couple of issues. First that competition in the marketplace is a valuable asset
for consumers. Secondly, this could be a useful lesson for project management
associations and their restrictive copyright policies.
|
