Damage Control
by Pat Craig
From the Fall 1997 issue of the Complexity Management Chronicles
Some software projects have deadlines that cannot move, such as Year 2000 upgrades (Y2K).
In date-critical situations, some person or team needs to function as damage control
central. A torpedo is coming straight at the ship (your organization ) and a blast is
imminent. You have seconds to prepare. Part of the ship will probably be lost. How can you
minimize the blast? Our hints for controlling the damage follow.
Ideally, you'll put together a small team. In any case, these critical roles
should be filled: You need someone who has strong analytical skills (Analyst), someone
with superb communications skills (Communicator), and someone to assist the analyst who
has organizationsl skills as well as good detail orietnation (Detail-Watcher/Copilot).
Ideally, the team members have worked together before, so they trust one another. You need
a group that does not panic easily.
For years, software projects have utilized small, focused teams with clear
responsibilities. Frederick P. Brooks discussed teams in his 1975 classic, "The
Mythical Man Month". This year's AQP conference had a fantastic seminar about
building small, high performance teams that featured Green Berets, the US Army Special
Forces. You can order a cassette tape of this session for $8.95 and s/h by calling
1-800-347-2902 and requesting session #322, "Learning from the Best."
The Analyst should identify the most financially damaging risks. This analysis should
lead to priorities for addressing applications and functions. Next, the analyst should
determine the software status for all the components making up the project. That status
includes not just the programs, but also the jobstreams, control cards, etc. To keep the
flow of information honest, the analyst should have an independent group check-in the
software as it is compiled/ linked/ binded, and have another independent group test it.
The analyst needs to be ruthlessly pragmatic: "What will be saved an in what
order?"
The Copilot should scan for "orphans", parts of the system falling between
the cracks. For example, we worked with an application group who declared that they had
completed their Y2K upgrades and wanted to deliver their application to test. But no one
had taken responsibility to upgrade the 100 or so common modules, which they depended
upon! These orphan programs had worked bug-free, and therefore unattended, for years.
The Communicator, working closely with the Analyst, focuses on keeping management
and other stakeholders informed. Nothing beats frequent and succinct communications
with the users, customers and management by a calm communicator.
If the project is spinning out of control, the Analyst and Communicator should
collaborate on a summarizing memo to the stakeholders. By focusing on the major
risks, stakeholders will usually make the right choice.
We recently saw a client implement these ideas successfully. This client was creating a
Fed Funds trading system and coding it in VB. This system, driven by Federal Reserve
changes, was in grave danger of missing a Fed-imposed deadline. To fulfill the dual role
of Analyst/ Communicator, management conscripted a product manager. Management also hired
a Detail-Watcher. On the Analyst's recommendation, they cut product functionality and met
their deadline.
For additional ideas on controlling damaage, please refer to our Winter
1994 newsletter, Must the Date Move, our Summer 1994
newsletter, Checks and balances, and finally our Winter 1995,
newsletter, QA Managers Caught in the Middle. Good luck with your damage
control!
©Complexity Management 1997
Somerville, Massachusetts
Located in Metropolitan Boston
***********************************************************************
Complexity Management Chronicles, a newsletter for software quality assurance
professionals, is published in print form four times a year. Send your name and snail-mail
address to the e-mail address below if you would like to be on the mailing list - atno
cost to USA mailing addresses.
***********************************************************************
Return to Complexity Management Home
Contact Pat Craig at patcraig@alum.mit.edu .
|