DHQ: What were the circumstances that
led you to write Complete Systems Analysis?
J. & S. ROBERTSON: We had clocked
many years of systems analysis experience, most
of it as freelance consultants. One thing that
we noticed was that each time we left a project,
our experience walked out the door with us. We
tried several experiments at training in-house
staff to replace us, but managers who were paying
a lot for our services (it wasn't really that
much) wanted us to do "real work" rather
than induct their people. This book is our attempt
to pass on real project experience. It's also
a teaching book. We love to teach, and this is
one way that we can do it.
DHQ: How did Piccadilly Television become
the subject of the book's main project?
J. & S. ROBERTSON: We worked
for a television company in London. It was a fascinating
project, and we didn't want that experience just
to pass into memory. So we wrote a book about
it. The company gave us permission to do it, although
we changed some aspects to protect any confidential
information. The name Piccadilly is a little joke.
The real company is called Central Television.
Central is also the name of one of the London
tube lines, so we named our case study after another
line: Piccadilly. Various aspects of the tube
crop up in the book, and some mysteries in the
book can be solved with a map of the London Underground.
DHQ: What does CSA offer people who have
already learned analysis techniques on the job?
J. & S. ROBERTSON:Complete
Systems Analysis reflects ideas that have
developed over at least fifteen years. New ideas
like event-response data and process models, integrated
analysis, and viewpoints are presented, along
with earlier practices like top-down functional
decomposition and data flow analysis techniques.
The book is written so that analysts with previous
experience can add to it rather than having to
relate to a completely new set of terminology.
DHQ: How did you structure the book to
adapt to the diversity of readers' systems analysis
backgrounds?
J. & S. ROBERTSON: The first
section of the book presents one project, the
Piccadilly Television case study. The reader has
to work through it. We kept the project separate
from the textbook section so that someone with
a little experience could work straight through
the project, without being diverted by the textbook.
After the project is finished, the textbook, because
it is separate, serves as a reference. We wanted
to mimic the way people work on projects: They
sit at their desks or, better still, the users'
desks and build models of systems. If they get
stuck, they refer to manuals, textbooks, other
people, and so on, for help. The book follows
this structure.
DHQ: How did you come up with the idea
of using ski trails as an organizing motif?
J. & S. ROBERTSON: We were
searching for a way to give people paths through
complicated subject matter. Tim Lister, one of
our partners in the Atlantic
Systems Guild, pointed out that such a device
already existed: ski trails. In the years that
we have been skiing, we have spent many hours
staring at signposts giving the names of the trails,
and about the same amount of time trying to reconcile
ski trail maps with the terrain. It somehow seemed
natural, when we needed a device to guide people
around this book, to use ski trails.
The motif appealed to us for another reason.
Not every reader comes with the same level of
experience, or has the same requirements from
this book. Ski trails are graded to beginner,
intermediate, and expert levels, so once again
that seemed the perfect analogy. We have the three
types of trails running through the book, and
the reader may follow any one he or she wishes.
We've also added a fourth patha promenade
for managers that covers the fundamentals without
assigning any modeling work.
The skiing analogy led to one other thing: the
ski patrol. In the book, the ski patrol arrives
at the end of a workshop, discusses what may have
gone wrong, and offers advice on how to proceed.
We loved writing the ski patrol pieces. It was
really tough (and embarrassing) to go back over
all the mistakes we made in our careers, and offer
advice to anyone about to make the same mistakes.
It was teaching at its best to write a piece on
how to recover from a mistake and get back on
the trail again. This underpins our unshakeable
belief that learning anything, particularly systems
analysis, requires one to experiment, make mistakes,
and thenmost importantlyunderstand
why the mistake happened and how to avoid it in
the future. We try to get our readers to make
mistakes (there are a few deliberately set traps
in the book) so that they understand the process
better.
DHQ: In what ways does Complete Systems
Analysis add to the theory of systems analysis?
J. & S. ROBERTSON: The word
"complete" says it. We have avoided
an exclusive treatment of small (but nevertheless
interesting) parts of the subject in favor of
demonstrating how systems analysis is really done.
In other words, the book is not about a theoretical
aspect of one facet of the subject; it involves
the whole process of systems analysis.
DHQ: Thank you, James and Suzanne!
The preceding interview appears in
The Dorset House Quarterly, Vol.
4, No. 3. DHQ
is now iDH: Inside Dorset House, our free
quarterly newsletter. It features book excerpts, interviews,
author news, and special discounts. Request a subscription
with our Contact
Form.