Get Your Management
On-Board
by Pat Craig
From the Spring 1997 issue of the Complexity Management Chronicles
This newsletter completes our four part series on mitigating staff turnover. As we have
indicated, staff losses can result in software delays, reduced creative capacity, and
staff replacement costs. Our overview newsletter (Summer, 1996), the first in the series,
listed the following reasons for staff losses:
|
Snowballing employee resignations caused by managers who push too hard, |
|
Shoddy work being shoved from stage to stage in the system development life
cycle, |
|
Balance of power wars between Development and Test. |
The second report in the series (Fall, 1996) addressed balance of power wars. The third
report in the series (Winter, 1997) addressed snowballing employee resignations. This
newsletter will offer suggestions for stopping shoddy work.
The overview newsletter (Summer, 1996) discussed examples of shoddy work and described
how enforcing strict exit and entrance criteria for each development phase proved
successful for two clients. See that newsletter for more detail on exit and entrance
criteria.
A Software Vendorıs Success: The following explains how a software vendor client of
ours successfully resolved their problems with poor workmanship. The vendor significantly
improved the quality of their deliverables by bringing in a new management team. This team
was not only committed to quality software but also had many years of relevant experience.
Hereıs how they increased the quality:
|
Clear, attainable goals: The management team knew that software professionals
(analysts, writers, testers and developers) cannot produce high quality work if the
expectations are set too high. So, very wisely, at the beginning of the project they
created two lists of features for the upcoming release: a must-have features list which
Marketing publicized and a private list of additional features the Development group hoped
to deliver. Management worked the project plan intensively and continuously to maintain
high quality and meet the software ship date. When efforts from development hit unexpected
technical issues, management cut out many of the features from the private list of
hoped-for features. |
|
Setting Standards: The new management team set standards for a development process
that everyone in the organization adhered to. First, management insisted that all business
requirements be documented. Next, they required a sign-off on the requirements from the
Marketing department. (This was to ensure that Development could begin building the right
product.) Then individual developers were required to write a system design document
outlining various alternative solutions. Finally, a larger group of developers and some
technically savvy managers reviewed the alternatives listed in the system design and chose
a course of action. |
|
Holding people accountable: When bugs were found in Test or in the Field, the
bug-producing analyst or developer was called ³on the carpet² to explain how they missed
catching the bug. (We know of three other companies who hold their staff accountable for
bugs. One company lists relevant bug data on the staff memberıs annual review. Another
company banishes bug producing developers and gives them outsourcing help to find more
suitable work.) |
In conclusion, improving the quality of software requires management commitment.
Management needs to implement processes and standards. Only then will quality deliverables
be the natural outcome of the new processes.
İ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 - at no
cost to USA mailing addresses.
***********************************************************************
|