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 .