Checks and Balances
by Pat Craig 

From the Summer 1994 issue of the Complexity Management Chronicles 

We have actively served "in the trenches" of systems development for almost twenty years. In that time, we have witnessed numerous projects that did not go as well as they could have. All too often, management believed Flaming Visionaries and Mr. Can-Do's who downplayed the related risks and costs. This newsletter briefly reviews an example of poor software development and proposes a series of steps, checks and balances if you will, to maximize your company's development resources. 

A startling example of a development project out of control was featured on page one of the Wall St. Journal on August 8, 1994, entitled, "Doomsday Device." The article reports that Hopper Specialty Co. suffered $4.2 million in lost profit due to a bug ridden inventory system. It mentioned two dozen other lawsuits charging the same software vendor with negligence, misrepresentation, and fraud. We do not find this story unusual. There is simply not enough room in this newsletter to describe the number of poorly executed projects we have witnessed. If you would like details of our own experiences, call our office. We can confirm that product liability lawsuits are not a rare occurrence. 

Here are eight rules, eight checks and balances, for keeping your development projects under control. 

1.Require large development projects to pass through a series of qualifying rounds to get initial funding and then require development managers to report progress on the project to get additional funding. 

2.Start development efforts as pilots, especially if the development involves a major change in technology or a major conversion effort. View each pilot as an experiment, not a commitment. 

3.Have regularly scheduled meetings that review all development projects from an objective viewpoint. These meetings should improve information flow and combat the tendency to continue projects already started. 

4.Upper management needs unbiased information about the status of all projects. One thing that prevents this from happening is that no-one wants to deliver bad news. Hence, information is filtered as it travels up the organization. To keep information honest, use consultants or employees not directly related to the project to determine the project status and to communicate the status, good or bad. Ask the consultant or employee to play the devil's advocate role, looking for potential problem areas. 

5.If a project is not going well, with no improvement in sight, separate the project from those originally responsible for it; either move the managers or move the project. New managers with no vested interest in the project's outcome should take over the project. 

6.Get a development process in place and ensure that everyone in development follows it. Revise the process as you learn better ways to create software. (The process should have checkpoints where managers have an opportunity to reassess their own projects, identify troublesome ones, and evaluate alternatives for managing them. One alternative, often overlooked, is cutting losses by canceling projects.) 

7.Don't just reward results. Change the bonus and/or compensation system to reward managers for following a development process. 

8.Appoint a person or group to work full time on improving the quality of the deliverables. This area should be independent of Development and should report directly and regularly to a senior executive at the company. 

ęComplexity Management 1994 
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 - at no cost to USA mailing addresses.

*********************************************************************** 

Return to Complexity Management Home
Contact Pat Craig at patcraig@alum.mit.edu