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. 


Return to Complexity Management Home
Contact Pat Craig at