Resolve Conflicts & Reap the Benefits!
by Pat Craig 

From the Summer 1996 issue of the Complexity Management Chronicles 

We have witnessed conflicts between Development management and their staff, between Development and Test, and between Development and Analysis. Getting caught in the crossfire can be stressful. More importantly, we have seen key employees leave their projects due to these conflicts. Aside from the cost of replacing key employees, staff turnover often causes software delays. 

We tapped into our network and brainstormed all the significant conflicts we've collectively experienced. This newsletter represents our analysis of those brainstorming sessions, our suggestions for nipping conflicts in the bud, and our description of some best practices we have observed. 

Vicious Spiraling: The largest cause of staff turnover we encountered is Development managers taking the position, "If I push my employees hard enough, I can deliver this project, on time, by sheer brute force." We have numerous examples of managers who pushed too hard. One project at a financial service institution lost 1/3 of its development staff, 50 people, within a year. 

More careful estimating of project size at the very beginning should help alleviate this vicious spiral of: 

1) projects being underestimated and as a result, running late, 

2) management pushing hard to make up for lost time, and 

3) staff responding to the increased pressure by leaving. 

Implementing project estimating tools would help. In addition, the International Function Point Users Group (IFPUG) is a good estimating resource for training courses. Once the project begins, rigorous project planning coupled with a small, dedicated release team, focused on meeting deadlines, helped three clients.

Sub-Optimal Output: We have observed major conflicts centering around specifications that were not detailed enough to code from and rapidly changing specifications that were not communicated in a timely fashion. These conflicts could be summarized in this way, "We follow your department in the system development process, your output is our input but we cannot do our job properly with what you have provided." In addition to implementing better estimating techniques discussed previously, enforcing strict exit and entrance criteria for each development phase has proven successful for two clients. 

Entrance and exit criteria resemble what happens in manufacturing and distribution processes. Manufacturers have quality control measures which must be satisfied before product can leave (exit) their plants and distributors have requirements that must be met before product can be received (enter) into their distribution centers. Likewise, exit and entrance criteria in the software development process can mitigate conflict by providing checkpoints that all parties understand.

Balance of Power Wars: These conflicts arise between Development and Test and revolve around QA's role as the institutionalized defender of quality. The conflict involves the logging of defects which can embarrass developers. We have seen three clients lose key test staff over logging defects. 

Clear roles and responsibilities, would have helped, i.e. it is the responsibility of QA/Test to write up everything that looks wrong with the system. Knowledge of the bug correction costs would also help. Correcting the defect now, although painful and possibly embarrassing for the developer, is far cheaper than correcting it once the system goes live. 

This newsletter has provided a quick overview of three causes of conflict which result in staff losses. In future issues, we intend to address these conflicts in greater detail. Call us to discuss. 

©Complexity Management 1996
Somerville, Massachusetts
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