Datasheet

Telling Stories
8
The needers, who don’t want to seem stupid or mean in challenging the
knowledge of the makers, haplessly approve the “requirements” document
and go about their business. Who has time to read a document like this? The
first 50 pages are lists of data fields and data types followed by a printout of a
PowerPoint presentation with bullet points that say “State of the Art,” “Secure
Solution,” and “Peak Performance.” It’s hard to know what these mean, but
they sound impressive.
Besides, the needers don’t feel like they should have to do a lot of work at
this point, because after all, they are paying someone to meet their needs; let
the makers figure it out. And what they need is so obvious. Anyone with a
decent background in accounting knows the basics of transaction processing
and can adapt it to this line of business. The manager of the makers seems so
clever and smiles nicely as if she understands exactly what to do.
The makers disappear for three weeks and come back with a prototype
of what they call the interface to show the needers. None of the needers dare
to ask what an interface is. The makers show the needers several pictures of
screens and the needers get some idea of how they will use the new system.
Someone asks how they can apply a discount rate for preferred customers and
the makers say that will be added later. No one takes notes. There are several
more meetings showing different versions. The same person asks about the
discount rate again and the makers show them where the discount field is
on the customer‑profile screen. The needers are reasonably happy with what
they see (when they’re paying attention), even if it is missing some details.
The system goes into production. Soon, a customer calls up angry because he
was not given his usual discount.
It turns out that no one who enters transactions has access to the customer‑
profile screen where it’s possible to add the discount rate, and it would raise
regulatory issues about segregation of duties if they did. Without substantially
changing the architecture of the whole system, the only way to apply the dis‑
count is with a post‑sale credit that takes a full day at the end of the month
for a staff member to manually calculate with spreadsheets. Not an optimal
outcome.
Because the needers and makers did not understand each other well enough
and didn’t spend enough time on requirements, the system doesn’t meet some
fundamental needs.
What I just described happened last year. This year, senior management
wants to clean up the mess and try to make the system that was supposed to fix
everything actually work, so they’ve drafted you, the hapless project manager,
37001c01.indd 8 1/29/09 10:50:41 PM