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 path—a 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 then—most
importantly—understand 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.
