BAs, LISTEN... (1st of 3 parts)

[BA Forum Moderator]

Indeed, the foundation of a good set of user requirements is a
well-planned, well-thought out interview session. Here, the article
describes one method of effectively capturing what our users want to
say, as well as helping them articulate their requirements. And, as
the usual practice in our organization, we practice peer review. it
sure helps!

The article below was taken from Computerworld.

====================================

Listen!

Want to build better systems? Teach your people to conduct better user
interviews.

News Story by Dick Lefkon

AUGUST 09, 2004 - Ask nearly any IT manager how helpful business users
are, and he will eventually say something like, "I know it's not their
fault, but when I expend resources to gather predesign information from
the business users, they tell us only half of what we need to know and
then give me trouble at sign-off when we've built exactly what they
asked for."

That may be true. But why?

Maybe it's because the business analysts who question the users aren't
routinely given real training on how to conduct an interview and don't
receive feedback on their performance. They may be schooled in how to
distill the vital facts into UML product templates but not in how to
get the valid facts from users in the first place.

Half the solution is to construct and require regular use of a user
interview form. Every IT unit should have such a form for gathering
systems planning information before specifications are written. Dust it
off, distribute it to your best advisers, and discuss it. Then develop
a plan for improving and reimplementing it. That way, you'll be sure
that all the important questions you come up with in advance will get
asked in the first interview. This will go a long way toward producing
a well-designed system.

But this works only if the business analyst is really listening to the
answers. You can teach him to listen through a simple
tracking-and-feedback protocol, and that's the second ingredient for
getting better business facts into your design specifications.

How the System Works

Here's how it works: A supervisor or business analyst mentor tags along
with the business analyst to the user interview. At the user session,
both the active business analyst and the silent mentor write on copies
of the standard user interview form. But while the analyst captures
business facts, the mentor uses the form to record sequences of code
letters plus occasional keywords to facilitate later review of the
session. The user needn't be told that the mentor is "grading" the
analyst's interviewing skills.

Using a simple, 10-letter mnemonic code (for a list of the 10 letters
and what they stand for, go to QuickLink 48646), the mentor notes what
he sees and hears every few seconds during the interview. Even if the
mentor has never before coded or analyzed interviews, the process is
easy to learn and can be quickly internalized with a little practice.

Here's how a mentor might employ the code to record a few seconds of an
interview:

Analyst: What process difficulties have you had with the current bond
trading system? (Mentor: Q...Q) User: Well, we've been booking styrips
and zero coupon bonds as very long-term T-bills, but sometimes the P&L
results reverse credits and debits and also come out much bigger than
the trader expected. (Mentor: A...A...A...A)

Analyst: So you're saying T-bills lasting many years sometimes have
their profits and losses reversed and have an unexpectedly large
magnitude? (Mentor: B...B...B) User: Come to think of it, I just
recalled some real bookkeeping problems the such-and-such system caused
last year. (Mentor: N...N)

Analyst: Yes, I remember about bookkeeping very well. You know, I got
all A's and B's in it at Wharton. (Mentor: X...X...X)
Later, the mentor and analyst should meet to go over the mentor's
notated user interview form, and the mentor can explain how the analyst
encouraged or discouraged the user's information flow during the
session.

The analyst should easily discern where improvements are needed from
the raw counts as well as the sequences of the code letters. For
instance, producing lots of QA and QN sequences is good, even with
intervening S's. But frequent QQQ's or XXQ's may mean that the
interviewer is wasting time by overexplaining questions.

Usually, business analysts readily accept a mentor's guidance and keep
the 10 letters in mind at subsequent user interviews. You'll find that
they become better interviewers through practice, followed by a
half-hour critique in which real counts of the letter codes are
reviewed in context.

Soon, your design specifications will be written from more and better
business-user input.

====================================
Lefkon is a former IT manager at Smith Barney and Equitable Capital who
now consults for financial services companies. Contact him at
ait...@hotmail.com.