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 patcraig@alum.mit.edu .
|