Now despite the premise of this post, not all conflict in a technical project is bad. Healthy teams resolve their conflicts through respectful discussion of the technical, practical, or organizational impact of each competing option. However, the emotional investment team members commit to their argument can appear to be based on personal prejudices. To keep the debate constructive, negotiations like this should be structured more formally. By employing a principled negotiation process, the team identifies the differing professional backgrounds and acknowledges the merits of each. By separating the people and their biases from the problem, the cloak of technical superiority within which each contender seeks to wrap itself would be rendered useless. So how do they get to this stage of maturity?An active conflict resolution process requires some time and patience to implement. To understand the interests of each conflicting party, each presents a pitch for their approach that addresses much more project related advantages. The pitch identifies relative level of technical acumen among the project pool of talent and approximate project life budget required to support the development tools, processes, and procedures. The criteria established for acceptance includes time to full productivity, total cost of development support, and match of talent pool to the method and platform.
If that’s sounds like some pretty expensive conflict resolution, how expensive can a passive approach to conflict resolution be? Being rooted in personal bias, affective conflict is not likely to resolve with a positive outcome. Keeping talent in close professional contact when there are clear signs of affective conflict creates tension and likely a choosing of sides especially when there are irreconcilable differences in their implementation techniques. For instance, two system architects who emphasize different performance characteristics can only reconcile their differences by introducing unnecessary technical boundaries.
Having seen the results of the passive approach, an example immediately springs to mind. Let’s say an Agile practitioner with a solid Java Enterprise Edition background teams with a more traditional development practitioner with an extensive .NET background. By ignoring the architect’s conflict, the manager ignores the destructive personality conflict as a procedural conflict. With a passive approach, the project manager tasks the two architects to haggle and present a design in which they divide work equitably. This would result in the parallel development efforts and also add a major task to the scope of the project. The new task would be required to integrate the two disparate work products. This wrecks the schedule created when the WBS and task time and cost estimates were used to create the schedule.
Such added expense and risk when integrating two such work products is not reasonable despite the fact that the conflict was compartmentalized. The entire project would be completed more quickly by standardizing on methods and platforms would likely require excusing one of these engineering leads. And that is how passive conflict resolution wrecks a technical project from within.
Innovation and Technology Management 
Leave a comment