Getting The Right Project Requirements
By Kevin M. Berry
Every play "Bring Me A Rock" with a boss or customer? Here's how it
goes. "Kevin, please go get me a rock." Kevin, being a model employee,
salutes and charges off, returning in short order with, of course, a
rock. Placing it proudly on the requestors' desk, he stands back,
beaming. "Thanks, Kevin," the boss says, scratching the back of his
head. "But, I was looking for a bigger rock." Kevin dashes out,
promptly fetching a large, fist sized lump.
The game continues, with Kevin fetching bigger, harder, differently
colored rocks. Finally, reduced from willing hey-boy to grumbling mal-
content, he screams in frustration. "What do you want this rock for,
anyway?" "Well, I've got this pointy metal thing I wanted to pound
into the wall to hang my Management School diploma on." "You idiot" -
Kevin is bellowing now - "you needed a hammer, not a rock!" Kevin,
once an aspiring corporate ladder climber, now works down at the
hardware store, happily selling hammers.
Sound familiar? In the real world of IT, a more apt label might
be "build me a database," or "I need a user friendly system to access
enterprise data real time from customer specific terminals." No matter
what you call it, the game remains the same. A customer has a real
need, but not the language or background to explain, ahead of time,
what they want. During the definition and programming cycles, they
don't understand the ramifications of decisions the techies ask them to
make. "Will you be indexing on phone number or address?" could be a key
design parameter, but the term "indexing" means nothing to someone
without extensive database design experience.
So, the alpha version is rolled out, and the customer invariably
asks for a seemingly innocent change that requires a complete
restructure. Along comes beta, and more chaos. When it hits the
validation environment and real users enter the picture, things fall
apart completely. Pretty soon, everyone, programmers and users alike,
are working with Kevin down at Home Depot!
Every model for managing IT projects starts with the mantra: "Get
the Requirements Right" and "Get the Right Requirements!" In
textbooks, classrooms, and on the popular book circuit, it sounds so
easy. Ask the right questions, be patient, give the customer a chance
to sign off on the derived requirements, and then lock down the
baseline, which must be protected ruthlessly.
In the grimy world of real projects, it's not that easy. Even
assuming a boss or customer understands their own ignorance, and is
willing to learn, mistakes and misunderstandings will always result
from a front-to-back requirements development approach. Experience
shows it's far better to follow Steven Covey's approach, "Begin With
The End In Mind". IT professionals think in terms of systems,
software, queries and data element relationships. Users think in terms
of reports, screens, and searches.
Whether building a database, web interface, or process control
system, it's best to start with a blank sheet of paper. Literally. Sit
down with the customer, key users, a white board and dry erase markers.
Sketch out the final product, such as a report printout, input screen,
or metric graph. It is amazing how long it takes to work through
simple things like "which column should be on the left" or "is going up
good or bad on the graph?" Of course, while the users are discussing
whether a column should be alphabetical A-Z or Z-A, the database
designer is hearing "one big table or related small ones" and "indexed
on name or phone number."
This is where that darling of consultants, "facilitative behavior,"
can actually be useful. Asking the right questions, drawing what is
being said, and helping users understand their own process will result
in a good final product. Often, the IT pro winds up helping them flow
chart their own business process, which is 100% certain to be imperfect
This process is one of Covey's "Paradigm Shifts" that can be very
painful for a designer to sit through. Too many times, though, the
keyboard wizards have blown off a user's report format question early
in the design process, only to find out after deployment that a
numerical field should really have been a text field. Once a veteran
designer has sat through these user product development round tables,
they are relieved at all the rework that was avoided.
One reef that many IT project go aground on is the "point one
percent problem." Users tend to get hung up on process or data
glitches that only happen once in a great while. It's up to
the "facilitator" to help them analyze whether a weird case happens
infrequently or regularly. Something that only happens one transaction
in a thousand may be a minor nit to the users, and can be dealt with
manually. To program around these oddities can be a costly, complicated
nightmare. On the other hand, if a bizarre data point or process issue
is going to happen once every 20 transactions, either the system is
going to need to accommodate it, or the user process changed.
Only after complete agreement on the final product is reached
should "real" system design begin. Backing up from the user's reports
or screens, decisions on structures and software can be made.
Architectures that don't support the user's needs are quickly
identified. Now, when the designers reach one of those "cost-benefit"
points, where it's going to be expensive to implement a specific user
need, they can go back to a well informed customer and ask for
meaningful inputs. "We are finding it will be tough to fit all 17
fields on one screen and still have the font the size you wanted. Can
we put the buyer's detailed shipping information on a pop up
instead?" "Well, that depends. Will I be able to cut and paste it
into our label-making program? That wouldn't be too big a deal, and
then you could skip coding the whole interface between the two."
Relate this conversation to the one in the opening paragraph.
Bingo. Smart user, happy programmer, successful project. Save the
rocks for your garden wall when you retire to your summer home on the
beach, or the winter ski lodge you earned as the most successful IT
manager in the history the company.
Kevin M. Berry
Private use welcomed, reproduction in other publications requires
permission of the author.
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Kevin M. Berry
© 2012-07-14 Kevin M. Berry