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
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
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
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
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 email@example.com .