I am sure you are able to think of a number of typical, reoccurring conflicts in project collaboration. But if you are aware of these difficulties why do they keep appearing? In my last blog post here at microTOOL I argued that one reasons for this is the fact that we ascribe this to the wrong reasons. The results are measures leading to nothing. This time I want to introduce a method allowing getting to the bottom of things. This method is taken from my conflict-solving game GameChanger. To familiarize you with the method I will use an example often to be found the implementation phase of projects.
Finding the Causes for Conflict: A Systematic Approach
The story goes as follows: An IT department is repeatedly confronted with the fact that other departments of the same company such as marketing or sales are ordering software from 3rd party manufacturers without consulting them first.
With signed contracts and consulting hours booked managers and consultants of said manufacturers show up at their door and expect nothing less than frictionless and quick implementation. In many cases this is impossible because interdependencies and technical boundary conditions have not been taken into account. Very often the software is implemented with a reduced scope of functionality and at significantly higher effort and cost.
In spite of the fact that there already have been talks about this and the IT department has offered consulting multiple times, what has been described here is quite common occurs on a regular basis.
Why is that? The department I went into that matter with was unable to explain it. Indeed, the answer is not that obvious.
The other managers are not dumb. They are perfectly aware of these reoccurring issues caused by experts being shut out. They also know that they could easily get rid of the problem simply by inviting these experts. The offers are holding, so why aren’t they doing anything about it?
Well, what would Sherlock Holmes do if you were to hire him to investigate? “Watson, when you have eliminated the impossible, whatever remains, however improbable, must be the truth.”
So, let us look at all the possible reasons. The following six options represent the six reasons for the problems mentioned. To examine them is the most effective method of finding the causes for conflict in collaboration between people:
- Cause #1: Lack of motivation
Involved parties may simply have differing preferences, in spite of the fact that they understand the viewpoints of the others.
In our case the managers or department heads may not be convinced that involving IT experts will yield positive results. Possibly they think that the negative effects will outweigh the positive effects, for example if the discussion gets too technical too fast or the desired applications cannot be implemented for equally technical reasons. Their strategy can be summarized as Create precedents and the rest will follow. Apologizing is easier than asking for permission.
Maybe the managers have had the experience of IT experts causing endless discussions with the provider, which they regard as being unproductive and disruptive. Or they think that the IT department is a service provider and must not interfere in the selection of tools.
- Cause #2: Individual skills
Skills necessary for the realization of the desired solution may simply be non-existent., e.g. technical skills. The IT expert present may direct questions such as We need to establish a connection to a IBCO messaging bus. What interfaces are available? at the service provider. These are utterances marketing managers are not able to process, and neither are the sales managers of the provider. These people specialize in supporting and responding to user requests.
These situations create a feeling of insecurity; users get lost in technical details and have the impression of losing control. They do not understand that what happens is a routine procedure and not the end of the world. Delays occur because there is need for clarification. All this is very unpleasant, which is why many people try to avoid it by postponing it. As a precaution the IT expert is not invited, because “we can do that later”.
- Cause #3: Goal conflicts between parties involved
Parties involved may have conflicting goals that are incompatible with each other.
The overall goal in our example is a common one, software that works well. At closer inspection there still is potential for conflict.
The IT department will usually opt for software that is based on technology they are familiar with, that fits well into the existing infrastructure, is easy to maintain and does not create any dependency from the manufacturer.
Also important are stability, security and data protection. In contrast, what interests users the most are functionality, usability, speed and comprehensive data access. Because users are well aware of these differing preferences they like to create precedents even if it means that they will have to struggle with resulting issues.
- Cause #4: Teamwork issues
Collaboration just does not run smoothly between departments. They suspect each other of being only interested in reaching their respective goals and disregarding those of others. Conflicting interests are not addressed and responsibility is assumed only for one’s own field.
- Cause #5: Systemic conflicts
Boundary conditions, e.g. company organization can also cause conflicts.
In some cases, the departments could well be integrated into one, this way, they would not be measured against different goals. For example, the IT department is measured against factors such as stability, cost efficiency, server capacity or data availability. Standards, long-term planning, easy maintenance and support by experts are important.
In contrast, marketing departments need to react to changes quickly, establish new contacts and experiment with new trends. Flexibility, pace, experiments, new technologies, anytime access to data are what counts here.
These goals are in contrast to each other which shows in the collaboration of the two departments; they are caused by the boundary conditions that impact all participants.
- Cause #6: Organizational obstacles
Shortcomings of the system such as business processes and rules can also cause conflicts. In our example conflicts may be created by audits or quality assurance measures necessitated by the processes or rules. IT departments may be forced to apply restrictive measures regarded as stiff and inflexible by other departments. We are not allowed to do that because that could cause problems during the audit creates the impression that they are hiding behind these guidelines.
The crucial question
Which one, now, is the main reason for all this? In most cases more than one. Complex problems cannot be explained in a simple, linear cause-and-effect scenario. Very often, multiple factors are at play simultaneously, and it remains unclear which factors are more important than others and which are just the result of others.
You will notice that even supposedly unanimous teams opinions differ if the analysis is carried out in detail. By eliminating one cause after the other you will finally and inevitably arrive at the most important one, the one you should focus on first.
Advantages of the approach
What have you gained with this approach?
Clarity and awareness; awareness of the fact that the there are multiple, interlocking causes at the root of your problem; awareness of the fact that other parties involved also have reasons for their behavior; awareness of the fact that ignoring the real cause of the problem makes finding a solution impossible.
Your way of looking at the problem changes, especially if you perform this method in a group. Believe me, you will be surprised by the effects.
So, what about a solution? It is not here yet.
But solving problems is your specialty, isn’t it? By detecting the real cause you are more than one step further in finding a solution.
Should you be interested in more tips on how to approach problems like these, drop me a line. I will put together a list of the best tips. In a future blog post here at microTOOL.