By Jeff Gainer
By Jeff Gainer
(Author's note: This article originally appeared in the January 1999 itmWeb Report.)
we wouldn't have some of our greatest challenges. Too often, the customer presumes that the development community understands their requirements or, more deeply, their needs. Or, perhaps more dangerously, we presume that the customers really do know what they need. More than once, after a brief preliminary meeting, I have been asked, "So you know what we want, right?"
We don't manage requirements well, we don't test well, we don't manage quality well or at all, and our products are almost inevitably late. And while we try to manage our schedules, our people and their work, we don't actively manage our customers. Instead, we regard customers as loose unmanageable cannons.
Rather than fumbling along and discovering expectations along the way, it is more prudent to determine measurable quality expectations at the beginning of the project and monitor and report progress against these goals throughout. Expectations management is very similar to requirements management--but the crucial difference is that we are managing the client, not the product.
Yet we must not only ask customers what they want and need, we must educate them as well. Before, not during the development of a product, educating the customer is essential, as this cautionary tale illustrates:
I witnessed a marketing representative watch a very carefully controlled demo of a prototype. In fact, the prototype was so fragile that it was amazing that it didn't crash while the development leader was guiding the mouse, but when the marketing rep grabbed the mouse and tried something and it actually worked, well, we were just as impressed as he was.
The project was only two months in and we were all mightily pleased that we already had an acceptable prototype and still didn't have formal specifications. I was part of the team extracting these specifications, while the prototype team continued doing whatever it was that they were doing. There was only one customer for the product, and it was to be delivered in another seven months. After the demo, I took the marketing rep to lunch and gently explained that since we hadn't defined formal specifications yet, there was absolutely no way we could have a finished, tested product delivered and installed at the client's site by September. On a napkin, I sketched waterfalls, spirals and triangles. I expounded the interdependencies of functionality, quality and schedule. He took it quite well.
He called me back three days later, still thoroughly excited with the demo of the yet-unspecified product. "The client understands," he said. "I explained the development process and showed them that pyramid thing, and they understood. They're willing to wait until December if necessary."
December would be good, I agreed.
"That demo was just great," he went on. "I was so impressed with it that I showed it to some other clients. I've got six firm orders already, with some little, minor, tiny changes. They're all different, but they're the same, you know what I mean? Can we get theirs done by December, too? I told them we could…."
December 1998
Somewhere in New York City
Known in some circles as "Jeff the Evangelist," Jeff Gainer thinks and writes about the state of information technology and process improvement from his office in Colorado, aircraft cabins, and the back seats of Lincoln Town Cars and limousines. Mr. Gainer's latest musings appear in the January edition of Cutter IT Journal, where he discusses the possibilities of "The Coming Backlash: Twilight of the Gods?"
Copyright 1999, by Jeff Gainer