| Introduction
to
Part I Empowering the Individual - The Role of Testing
James Bach - A Brief History of the Accessibility of Computers by
Blind People
Kevin Fjelsted - Solving Other People's Problems
Don Gray - The Perils of Parallel Projects
Johanna Rothman
- Do I Want to Take This Crunch Project?
Sharon Marsh Roberts and
Ken Roberts Although "organizational change" is a comforting
executive concept, Virginia Satir, the great family therapist, was fond of reminding
us that "change happens one person at a time." There is no organizational
change without individual change, no organizational effectiveness without individual
effectiveness. That's why the first articles in this volume all address dimensions
of individual empowerment. For some, individual empowerment is a matter
of overcoming disempowering factors—a good example is Kevin Fjelsted's description
of the struggle by blind people to have decent access to computers. Another, more
intimate, example, is the internal models that prevent us from understanding how
broad our role can be, as exemplified by James Bach's evolution of ideas about
his role as a tester. Sometimes, we empower ourselves by the tools we use—physical
tools, like Kevin's Braille readers, or mental tools, like Don Gray's problem
solver's tool kit. Sometimes, we empower ourselves by setting priorities, so we
can do the best we can, under the circumstances—like Johanna Rothman's principles
for coping with multiple parallel tasks. And, finally, we empower ourselves
by staying out of situations that will disempower us, as Sharon and Ken Roberts
describe in their article on how to recognize crunch projects, then either transform
them or say "no thanks."
Introduction
to
Part Two: Improving Interpersonal Interactions - Life
as a Software Architect
Bob King - Step One in Building Strong
Business Relationships
Naomi Karten - Congruent Interviewing
by Audition
Gerald M. Weinberg - Maneuvers to Disable a Team
Becky Winant - How to Deal with Irate Customers
Naomi Karten
A recurring dream of technical workers is to have the opportunity
to work in perfect isolation. For better or worse, though, the vast majority of
technical work puts us in relationships with other people. So, if we are to amplify
our effectiveness, we must learn how to amplify the effectiveness of our interpersonal
interactions. The job of software architect is a perfect example. Though
many of us perceive the architect as a solitary individual laboring in an ivory
tower, Bob King disabuses us of that primitive notion with his article on how
he measures the effectiveness of his architectural work. All of his measures,
in the end, are measures of his effectiveness at working with others. In
her two articles, Naomi Karten shows us how to build strong working relationships
and how to deal with relationships that are threatened by anger, using the example
of dealing with irate customers. Becky Winant warns us of some tempting maneuvers
that can destroy a team's working relationships and, in my piece, I suggest a
way to start good relationships with new employees or team members by congruent
interviewing.
Introduction to
Part
Three: Mastering Projects - Ten Project Haiku
Rick Brenner
- It's Just the First Slip
Johanna Rothman - Quality
Begins at Home
Brian Pioreck - Managing Your ERP: How to Avoid
Common Pitfalls of Implementation
Marie Benesh - Recognizing
Runaway Projects
Eileen Strider Projects are team efforts
aimed at bringing something new into the world, which makes them sensitive measures
of our individual and team effectiveness. To paraphrase an ancient Chinese proverb,
managing a large project is like boiling a small fish—a delicate job. Rick
Brenner leads off this section with some small delicacies of his own: poetry that
mirrors the sensitivity of projects with a delicacy of observation. Johanna Rothman
then transforms some of Rick's haiku into more hearty fare-recognizing the significance
of slips and gleaning information on how to master them. Brian Pioreck neatly
connects his personal effectiveness with the outcomes of the projects in which
he participates, even when they're supposedly simple projects such as making a
pancake breakfast. Marie Benesh scales up Brian's insights to teach us to recognize
and manage some of the common pitfalls of gargantuan projects—ones that are
more like banquets than breakfasts. To conclude the section, Eileen Strider shows
us how to recognize and cope with projects that have eluded our mastery and become
indigestible.
Introduction to
Part
Four: Changing the Organization - The Satir Change Model
Steven
M. Smith - Modeling Organizational Change
Esther Derby - How
to Create a Process for Developing Useful Scientific Software
Patricia
Medvick - Good Practice Hunting
James Bach Once
we have succeeded in demonstrating our effectiveness by successfully completing
a project or two, our aspirations naturally turn to helping others do the same.
But change is not the simple linear process that we might hope, as Steve Smith
explains in his article about Virginia Satir's Change Model. To change an organization,
we need tools to aid our systems thinking, and that's just what Esther Derby gives
us in her article on modeling organizational change. Pat Medvick shows us
how several different routes can lead to the sort of organizational change needed
to create a process for developing useful scientific software, and James Bach
shows us how the search for better practices is not a mere intellectual exercise,
but more of a real-life adventure. | 
