CIS498
Chapter 9
Changing Your Requirements -Gathering Mind -Set
The success of any IT project is determined at the very beginning of the p roject life cycle,
when the IT staff meets with the business clients to gather the requirements. But IT's
track record with this important phase is similar to its history with project management
itself: abysmal. Requirements have been gathered for decades, but most IT
organizations have yet to discover a consistently successful way of sitting down with
business clients, discussing their needs, and translating those needs into a useful
system, enhancement, customization, or software package selection.
In fac t, according to some statistics, poor requirements gathering is the cause of about
70 percent of today's technology project failures. That's because passing along one bad
requirement is akin to throwing a stone into a pond and watching how far the ripples go.
According to some calculations, each badly defined requirement results in 10 bad design
statements, which then can multiply to 100 incorrect coding statements. Even if that's
an exaggeration, you can easily see how poor requirements negatively affect a pplication
integrity, maintenance costs, and client satisfaction. This is true whether you're looking
to build a custom system, buy a new software package, or enhance an existing system.
Skipping requirements gathering is like building a house without a pl an. For example,
I've seen companies buy software that didn't meet their business needs, mainly because
they wanted to save time on the requirements step. When they tried to modify the
package to meet their needs, they discovered they didn't know the requi rements. They
sadly concluded that the step they skipped really did need to be done to make the
package useful.
I often see organizations turn to yet another vendor tool or methodology in their
attempt to improve this situation. But just as with project ma nagement, IT is facing a
problem that requires less of a scientific fix and more of a mind -set change that
emphasizes the up -front work of really communicating with business clients to discover
what they need.
From what I've seen in my 24 years in the IT p rofession and from working with clients
across the country, this is a mind -set change that's way past due, as business leaders
grow increasingly frustrated with the gap between what clients need and what IT
delivers. I learned about the importance of good requirements throughout my varied IT
career, which included stints in analysis, development, production support, project
management, and relationship management. It became clear to me that to have success
in any of these roles, it all starts with good requ irements. Everyone who has to read and
use them appreciates them, they increase productivity and quality, and they add
accountability. Finally, a good requirement is measurable because either the end
product delivers on that requirement or it doesn't.
Spec ifically, I learned two critical things about gathering requirements:
1. Always figure out and then describe what the problem is and what specifically is needed,
because there are many solutions to a given problem.
2. Don't come up with a solution before you kno w what the requirements are. There are just
too many people who want to tell you how to do your job. How many times has your IT staff rushed through the client interview stage to jump into
what they consider to be the real work, designing and programming? And when they do
spend time with clients, are they really listening? Or are they busy trying to relate what
they hear to something they're already familiar with, like another system they've
recently built or a platform they're comfortable with? Sometimes t hey might hear just a
little bit and immediately determine that what the clients want simply can't be done,
instead of asking more questions to verify their understanding.
To better understand the problem, imagine you're a bridge designer, and a client com es
to you, describing his need to get over a body of water so he can cross from one
landmass to another. You'd start designing a bridge, right? Well, what if you were in the
submarine business? Or in the airline industry? Or a tunnel engineer? The point is that
the client simply needs to get from one piece of land to the other, and whether that's
best done by bridge, submarine, balloon, or dirigible can only be determined by an
unbiased third party who knows how to unlock the client's real needs and expecta tions.
How many times a day does the client need to go back and forth? How quickly does he
expect to be able to accomplish it? How many other people need to do the same thing?
Do they all have to move at the same time?
And it's not as though business clien ts are any better at this. In fact, today's more
technology -savvy clientele often come to IT with a solution based on a recent article
they've read or a conference they've attended. Then the IT staff think it's up to them to
implement that solution rather than backing up and finding out what the client's real
needs are.
No tool or methodology can resolve these problems. It's a matter of changing the IT
professionals' mind -set and helping them develop new skills so they can see things
through the eyes of the client, establish a rapport, ask the right questions, actively listen
to the responses, ensure understanding, and accurately translate those needs into a
written document. Also keep in mind that the ability to quickly and effectively capture,
validate, an d control client requirements doesn't apply only to project managers and
business analysts. These are essential survival skills for anyone working in today's IT
environment of lean staffing and crunch -mode projects.
When IT leaders become more aware of the skills gap that exists in their own
organizations, they can transform their organizations' requirements -gathering cultures
and help individuals develop the necessary skill sets, independent of any particular
vendor's tool or methodology. When they affect this type of change, the results can be
astounding. I know — I've seen it.
Recently I worked with a client who had two project teams that were trained to do
requirements gathering. The first team adopted the techniques; the second team did
not. The first tea m delivered its project on time and on schedule, with high client
satisfaction. The clients, who were geographically dispersed, were enthusiastic about
how well the project team understood their needs and communicated its progress. The
second team was over budget and behind schedule and constantly heard complaints
from their clients. To paraphrase one of the client responses, “We don't know what we're
getting or when.”
The What, Not the How I think of the requirements -gathering process as a journey, with pl enty of precarious twists and
unexpected turns along the way. If you're a skillful driver, you can stay on track and arrive at
your destination. But poorly negotiating the curves or taking a wrong turn can result in a lot of
wandering along unpaved roads t hat lead nowhere. Unfortunately, a successful arrival requires a
skill set that most IT professionals don't have, from what I've seen in my work with IT
organizations. It's the job of the IT leader not only to become familiar with the optimum route to
requ irements -gathering success but also to teach his or her staff how to navigate.
The first and most important skill is steering the client interview toward the what , not the how .
From the hundreds of projects I've worked on, I can say that the failure to do this is the biggest
downfall of most IT professionals. In their zeal to get to what they consider real IT work, many
project managers and business analysts start shaping the solution to the client's needs (the how )
before they really understand what those needs are in the first place (the what ). But as soon as
they do this, it's a guarantee that they're veering from the right path.
Let me explain it this way. Do you have any 8 - to 12 -year -olds in your life: neighbors, nieces or
nephews, sons or daughters? If so, you may have heard them say how much they really need a
cell phone. But have you ever asked them what they intend to do wit h this electronic device they
seemingly can't live without? If so, you've probably heard answers like “Talk to my friends”
(have you ever been on the other end of an 8 -year -old's phone conversation?), “Let my parents
know where I am” (how far do 10 -year -olds really travel these days?), or more likely,
“Download a cool ring tone,” “Take pictures.” By pressing further, you might uncover that it's
not really a cell phone the tweeners really need at all; what they're really after is a sense of
independence, of feeling like a grown -up, of keeping up with the latest technology rage — all
things that can be achieved in a variety of ways and not necessarily with a cell phone (which
they're bound to lose or at least lose interest in after showing it off for a few days) .
Fortunately, talking with clients is usually not like talking with a 12 -year -old, but the common
thread is that you can't automatically assume that the solution clients say they need is really the
optimum one. Arriving at that requires digging underneath the surface, steering the client toward
describing not how she wants something built but what she needs to accomplish. Remember,
your goal is to figure out what the client needs from the new system or modification or software
package — not how she wants it to be built or designed. In other words, project managers,
business analysts, and others need to learn to leave the how to the designers and consider their
job to be getting to the what .
To understand this better, let's go back to the client who needed to cross the body of water. If he
came up to you and said, “There's a river over there. Can you build me a bridge?”, that's a how .
But if you ask him, “What do you need to do? What is your goal?”, he might answer, “I need to
get to the other side.” That's the what . And when you get to the what , you realize there are many
options for the how , whether it's a bridge, a tunnel, a ferry, or a submarine.
In other words, you don't want to design answers; you just want clients to tell you what they
really want. There can be many solutions and many designs to fit a client's needs, and that should
be left to the designers to figure out, not the requirements gatherers.
By asking what instead of short -circuiting the process by starting with the how , you can air out
many ot her designs and approaches, some of which might be better than the how the client
comes to you with. A typical example from my experience is a client who brings me a screen or a report with a new
column added and says, “This is what I want!” By questioning what the client needs with the
column, I might find that the information is derived; for example, formulas need to be defined,
the data don't exist anywhere in IT (they're on a client's spreadsheet), or the information is
readily available somewhere else, like in another report or on an application not currently used
by the client.
I was working with an IT organization that related the following example of falling into
the how trap. Its business clients brought in modified screenshots showing how they need ed the
system to be changed. The IT organization worked with the clients to spec out the changes and
sent it offshore for development. When the newly modified screens were returned for testing,
someone in the IT organization asked why a new set of screens was developed to handle
functionality that already existed! It turns out that the business clients were unaware that there
was an existing functionality that would work just fine.
The Importance of the Interview
The second fork in the road that can throw r equirements gatherers off course is the mistake of
taking client requests at face value. Far too many IT organizations take on the role of order
taker — listening to what clients want and unquestioningly delivering it to spec — only to discover
the final resul t doesn't serve the business needs at all. This is such an easy trap for IT
professionals to fall into that it was discussed in more depth in Chapter 5.
Clie nts don't always know how to communicate their needs, and it's now up to IT to lead the
way. And the way to do that is by developing strong interview skills, which is yet another
Achilles heel for many IT professionals. From what I see in the IT organizati ons I work with,
most IT staffs approach the client interview as an item to complete as quickly as possible rather
than as an opportunity to build rapport, establish a partnership, and really understand what the
business is trying to accomplish. It's the I T leader's job to sensitize the IT staff to the importance
of the interview and teach them how to take advantage of this prime time with the client.
Good interviews don't just happen. It's good to ask a lot of questions, but you don't want to come
across a s disrespectful or annoying. It's important to steer the clients toward talking about what
they want, but you don't want to appear arrogant or negative. There are many fine lines that need
to be walked, and the only way for the IT staff to keep its balance is to develop communication
skills.
One of the most common interview problems I see is that the interviewer becomes frustrated
with the interviewee, especially when she thinks the interviewee doesn't know anything. I have
heard statements such as “Can I t alk to X, who knows something about the problem?” without
realizing that she has just insulted the person she is addressing (usually management).
Above all, a satisfying interview requires establishing a rapport with the person or people with
whom you're p artnering, which means allowing the conversation to naturally flow beyond a
discussion of work and technology. Such camaraderie will go far when you inevitably run into
conflicts, confrontations, and other difficult conversations with the client in the fut ure. The idea
of establishing rapport is so important that we've also discussed it in Chapters 5 and 7.
For the purposes of requirements gathering, however, there are some specific ways to open the
lines of communication. One idea is to encourage the IT organization to conduct its interviews in
the client's offic e, which will help set the client at ease. This is important because an intimidated or defensive client won't be inclined to open up to the requirements gatherer. This also gives the
IT professional the chance to look around the office for personal memento s such as photographs
that reveal something about the client's personality or life outside work. These are easy
conversation starters that can encourage a natural flow of communication and benefit the IT staff
when it gets down to the business at hand.
Bec ause this doesn't come easily to many IT professionals, they need to be encouraged to ask
about the client's golf game, his whitewater rafting trip, or her marathon training and listen for
interests that they share. Such tidbits can be used for further con versation starters when IT
professionals see the client again in the hallway or at their next meeting. Most people enjoy
talking about themselves to people who seem truly interested, and that's what establishes human
connections.
It is estimated that 55 pe rcent of communication is nonverbal. I remember being in a client's
office when IT called to get some information. The client said, “Okay” but rolled his eyes,
frowned, and let out a groan. The caller heard, “Okay,” but to anyone present in the office, the re
was obviously an issue to be discussed and resolved.
Do note, however, that if any individuals on the IT staff don't feel capable of engaging in this
type of rapport, it's probably better for them to try another tactic, like talking about the weather
or something else of general human interest. The last thing you want is for the IT professional to
come across as a phony who ritualistically asks the same question about the same photograph
with no genuine interest in the client's answers. Similarly, if the client's office reflects nothing
personal, that should be taken as a cue to the person's more bottom line –oriented personality, in
which case the IT professional should stick to the business at hand, such as asking, “How are
sales?” or “How's business?”
Another common interview mistake is for requirements gatherers to fail to establish a common
language between themselves and the client. IT professionals need to be sensitized to
understanding that first, there is indeed a difference in terminology in the t wo worlds, and
second, they need to be proactively encouraged to adopt the terminology of the business client.
They can't be too proud to ask for definitions — acronyms in one industry can mean something
else entirely in another industry, or even in another division of the same company. Problems
occur when you persist in using the jargon of your own world or when you assume you
understand the client's terminology.
In fact, you may discover that different business clients are using different words to mean the
same thing. In those cases, the IT staff can serve as a bridge between clients, encouraging them
to agree to a uniform vocabulary for a particular project or initiative and clearly defining that
vocabulary in a project glossary or dictionary. When everyone agrees on the terminology, it
eliminates the room for confusion.
I came across the same acronym that means two different things in two different business areas
of a company I'm working with. Since IT deals with the entire company, this can lead to
confusi on when team members change or requirements are passed on to designers. It also causes
issues for new employees, contractors, and offshore developers.
Here are some additional tips on helping the IT organization improve its interview success:
Take a who and what inventory . Chances are that multiple clients will have to be
interviewed, so it would be wise for the requirements gatherer to do some research ahead of time on what pieces of information are necessary and who is the most likely source for that
information. For each person she interviews, she should know her objective. She doesn't, for
example, want to waste someone's time talking about general ledger concerns if that's not that
person's area of work.
Make a written list of questions . This will hel p the requirements gatherer manage his time
during the interview. He may arrive with 10 questions, but if the person turns out to be a
treasure trove of information, it might take half an hour to get the answer to the first one. If he
still has 9 to go, he can determine, in partnership with the client, whether to move on or plan
another meeting.
Stay in an asking mode . If the requirements gatherer concentrates on asking questions rather
than making statements or not responding at all, she'll avoid two commo n errors that I see IT
professionals make: making assumptions and forming arguments. If she has even a shadow of
a doubt about whether she understands something, she should ask for clarification or otherwise
check her understanding. It's better to play stu pid than to misunderstand. And if she doesn't
agree with something the client says, she should respond with a question. She's not there to
argue; she's there to find out what the client needs.
Provide prototypes . A good way to verify mutual understanding is to use visual aids, such as
mock screens, reports, or models. It's important for the requirements gatherer to emphasize to
the client, however, that the prototype is not the end product but is simply a tool to ensure that
everyone is in agreement. Too often, when the IT staff draws a mock screen, the client is
surprised when the actual screen doesn't turn out that way. One way to avoid this is to never
leave the prototypes behind with the client.
Craft a smooth ending . When ending the interview, the requirements gatherer should make
sure he recaps his understanding of what he heard in the interview, explain the next steps, and
express appreciation for the person's time.
Communicating through Pictures
A third wro ng turn that I often see IT professionals make along the requirements -gathering path
is to begin writing up the requirements before ensuring that they and the client are on the same
page. All too often, after the client interview, the requirements gatherer disappears, sometimes
for weeks, writes up the requirements, and then presents a fully written document to the client for
feedback. When the client finally gets back to the IT professional — usually after a lengthy time
lag — with changes, the process repeats itself, stretching out the back -and -forth review period for
several months, with many lengthy lulls. At one company, requirements documents are rewritten
an average of seven times before they reach final -copy stage! This approach is time -consuming
and abs urd, and in the end, the chances of getting it right are slim to none.
Note that this is not what an iterative approach should look like. A healthy iteration means that
the work is being done, reviewed with users, and quickly corrected in hours or days, an d this
process is repeated until the document is correct or complete. That's different from writing a full -
length document, publishing it, and continually making adjustments to it for months.
To achieve a healthy iteration, I suggest inserting a picture -drawing phase into the process before
jumping into the document -writing phase. Call them models, context diagrams, event analyses,
or anything you wish — the idea is to create a clear communication tool that's easy for both IT
and the client to see how everyth ing connects and what's in and out of scope. I've seen this method work on numerous occasions. In one case, a senior IT vice president had
bought a software package to replace an existing antiquated application. He thought it solved the
business needs and would be easy to install. There were no requirements. The development team
was certain that the project would be a failure but was unable to communicate that upward.
Within an hour, we drew a context diagram to show all the system interfaces that had to be
developed to communicate with the new package. There were 57 system interfaces that would
have to be designed, developed, and tested, and this did not include installing the package,
loading the data, or ensuring that the package met the client's needs.
Two hours later, after reviewing the context diagram, the senior vice president canceled the
project, saying he hadn't realized how big an effort it would be to install and that we would need
to get the requirements done before purchasing a new package. A p icture on one page
communicated what the development team had been trying to tell management for two months.
In another case, I was involved in a large IT effort to build a new regulatory business process.
We used modeling to first define the existing proc esses and then modified the existing processes
to accommodate the new process.
The first day was difficult, because the clients couldn't understand why we were drawing pictures
and not writing requirements. But by the second day, they had begun to fully ut ilize the modeling
approach, with comments such as “Take process X; modify this, this, and this; and it will do
what we need to do.” We were also able to establish and document a common business language
definition.
Because most people can draw or model mo re quickly than they can write, this new step
effectively minimizes the lull between initial interviews and the feedback loop, which keeps the
discussion fresh and as close to real time as possible. Also, most people are more responsive to
pictures and dia grams than to a wordy document, which makes it easier to pull clients into a two -
way, engaging conversation instead of the arm's -length, removed, and disconnected type of
communication that written documents promote.
Diagrams also make it easier for client s to see and explain what's wrong or missing in the system
or process that IT has modeled. With a long written document, by the time many clients and IT
staff get partway through it, they can barely remember what they read in the first half. But with a
pic ture, the client can immediately see and discuss what's right and wrong.
If the IT staff does a good job with the initial interview and the iterations that follow from the
picture -drawing stage, they'll find that when they actually write the requirements d ocument,
they'll need to revise it only once or twice at most. That's because everybody involved has agreed
to the ideas and thoughts behind the document, used a common language, and has given
feedback up front.
A word of warning: You may see so much succe ss with picture drawing that you're tempted to
go right to the prototyping phase without writing a requirements document, or perhaps writing
requirements only for business logic. However, this is a dangerous approach. While I have seen
IT management push t he idea of skipping written requirements, the risk is significant. Consider
how vulnerable you'd be if key staff members left the organization because of turnover, or a
decision was made to use offshore development. The lack of written requirements is a pr oduction
support nightmare, and this is especially true when enhancements are requested. Also, without an
agreed -upon set of requirements, there is no baseline established to manage change. Writing a Solid Requirements Document
As we near the end of the re quirements -gathering journey, there's a fourth fork in the road that
can throw IT professionals off the requirements -gathering path: writing the actual requirements
document. Let's go back to the points made at the beginning of this chapter. Since requirem ents
are what designers use to design, testers use to test, and so on, one mistake in the requirements
document has a negative ripple effect, and we end up delivering something that doesn't fill the
client's needs. We end up with patchwork new applications , a high level of postimplementation
defects, low client satisfaction, requests for enhancements, and budget and schedule overruns —
and that's if we succeed!
The goal is to write a simple document that is clear and concise. It should be easily understood
by IT and the business, from senior management to the staff, with no ambiguity. I once worked
for a CIO who said, “If I can understand it, then you've done a great job of writing the
requirements.” In other words, write it for someone who doesn't know what m ust be done.
In writing the requirements document, it's important to hold the power of words in the highest
esteem, especially with something that requires the language precision that requirements
documents do. This is essential, so it's important for requ irements writers to be as accurate as
they possibly can, which might mean learning some new skills in written communications.
There are several language tricks you can pass along to requirements writers to ensure precision
in the document. Here are two:
1. Th e power of must . Make ample use of the word must . It is one of the most powerful
words in the English language, because when you use it, there are no two ways about the
statement you're making. “X must do Y,” plain and simple, 100 percent of the time, n o
exceptions. It's not the same with words like should and shall , which imply an
undefined maybe , an unnamed exception to the rule. Those gray areas are exactly what
lead writers of requirements documents into trouble.
Unlike its cousins should and shall , must exposes the exceptions and forces people to
define them. When clients read a must statement, they're likely to respond, “No, actually,
that shouldn't happen under these specific conditions.” This helps us capture what's so
easy to miss — the exceptions to the rule.
When you say, “X must do Y,” someone will find an exception, even if it's as obscure as
“except when there's a blue moon following the harvest moon on the fifth month of an
odd year.” And those are the things that all too often just don't make it into the code.
Here's an example. At one company, a project team wrote a document with zero defects
traced back to the requirements phase. That's because through computer modeling, 37
defects were exposed, all of which were instances in which each shal l was changed to
a must . When these changes were brought to the client, eight statements were flagged as
having multiple exceptions.
2. Watch out for and . As much as you can, try to eliminate any stray and s from your
document, because their presence indicates that you've combined two thoughts that
should be separate from each other. The whole idea is to keep the statements simple, and
when it's time to design code for the statements, it will be much easier if the designer
understands that there are two distinct thoughts, not two thoughts rolled into one. Requirements should be expressed in short simple sentences with their associated
exceptions. Much too often, I see one -sentence paragraphs that describe mul tiple
requirements, which confuses everyone involved.
Conclusion
If IT professionals want to improve their project success rate, the first place to look is at the very
beginning of the project life cycle: the requirements -gathering phase. This is not a pha se to speed
through and check off as soon as possible; it's an opportunity to establish a partnering
relationship with the client and use all the communication skills you can muster to truly
understand what the client needs.
For years, organizations have t ried and failed to improve their requirements -gathering process,
using the new tools being promoted or the methodology of the day. But despite all their efforts,
they find themselves running into the same obstacles, falling down, and wondering yet again
wh y they can't get it right.
That's why some IT leaders are beginning to try something different. They're taking the path of
establishing a new mind -set among their organizations to approach their projects differently and
embark on the requirements -gathering journey with their compasses pointed in the right
direction. With the right skills in hand, they can traverse the winding path and take all the correct
turns.
When you help your staff members improve their communication and interpersonal skills, they
beco me more insightful interviewers. It's only then that IT will stop building expensive bridges
to nowhere and start helping its clients walk on water.
Top 10
Techniques for Changing Your Requirements -Gathering Mind -Set
10 . Establish rapport.
9. Communication is the key.
8. Interview the right people.
7. Talk in the business language and use pictures (models).
6. Don't assume — ask.
5. Don't solve the problem before you know what it is.
4. Requirements are short, concise sentences.
3. Use the power of must — exceptions will kill you.
2. What is a requirement, not how .
1. Give the people what they want.
