As any manager knows, so long as there are IT departments and business analysts, there will be misunderstandings and miscues between the two. Frequently, it’s because—and we’re generalizing here—business determines the destination while IT charts the journey.
Collaborative approaches to development and innovation rely on building bridges and relationships. But there can be stress points between IT and business teams, who see overall projects and systems in different ways.
Don’t let their very different personalities undermine your project goals and sabotage efforts to work together. Whether you're an operations manager, team lead, project manager, or scrum master, here are five techniques you can use to close the gap, foster better relationships, and mend fences when inevitable miscommunications do happen.
Take time to understand the problem.
While general personality clashes and arguments can happen for a variety of reasons, it’s just as likely that business analysts and IT have different ideas of when and how tasks need to get done. Tensions commonly arise from disagreements over resource allocation, but they also occur as a result of general costs, technical disagreements, conflicts in prioritization, or lack of consensus on responsibilities or schedules.
Both the IT professional and the business analyst need to understand the underlying issues behind the positions that people are taking. For example, while IT may be perceiving the business analyst as not recognizing and respecting IT’s expertise, the business analyst thinks the IT manager doesn’t understand the business case and its importance. Both of these things can be true, including both at the same time.
One common cause of this stand-off is describing the solution instead of the problem—and ironically, the more expert the participants, the more likely this is. But by not thoroughly defining the problem, assumptions can creep in that mean the project is not actually defined correctly. Worse, the business analyst and IT professional can end up with conflicting ideas of the solution, which if not articulated, don't get worked out. (Agile Scrum stories are of course one way to get teams to describe a problem and discuss it out loud.)
Make sure both teams are on the same page.
Before small problems balloon into large ones, set up a meeting to discuss the project/business goals. Find out what the conflicting stakeholders/groups think, and have them reiterate the higher-level goals themselves. It may become apparent that not everyone is on the same page.
Open conversation is a place to start. Use it to gain consensus around the actual project goals. Both groups may need to go back to a project executive or sponsor for clarification. Unclear project goals or requirements are a persistent source of conflict and need to be clarified as soon as they are identified.
Have a plan and develop some tools for going forward.
When it comes to mending fences, begin at the end: Ask what the end result of your business goal needs to be, and get everyone’s ideas on the table. This question is very important in case of managing conflicts between IT and business. If the expected outcome is not clear, or worse, different between the two teams, this will inevitably result in conflict. This is where active listening comes in. Hear what is being said, focus on the speakers, clarify and acknowledge what was said, and only then, interpret and respond to the speaker.
Once all participants understand the problem, a brainstorming session can help generate ideas to solve the problem, but do it correctly. This can be done individually or in a group. At this point, just getting ideas on paper is key. Don’t worry about whether the ideas are “good” or not. Quantify both the costs and benefits of the solutions and prioritize them.
Above all, produce a conclusion that everyone understands and is seen to acknowledge. This last part is key, because no amount of fence-mending will hold if the parties don't state their agreement to each other.
Start small to get out of old patterns.
Business analysts and IT need to see themselves as engaged in a long-term relationship, because when the current project ends, a new one will begin. So when it comes to mending fences, think small and quick.
Start with solving small problems in a timely manner. Being able to resolve issues productively lays the groundwork for dealing with or even preventing more serious problems that may arise down the road...problems that may be a source of true conflict.
You may find that solving larger disagreements proves to be too hard at first, simply because the more complex an issue, the more interaction is needed to discuss and clarify the nature of the problem. But if you solve smaller issues (even if they're less important) as the foundation for establishing that working together is possible—this proves that that collaboration is productive. And it will lay the groundwork to make the conversation around harder problems more tractable.
Recognize that collaboration is itself a goal, as well as a means.
IT and business analysts support company goals in different ways. This creates differences in the way the needs of each group get prioritized at a company level. As a result, conflicts can happen at any time during a project cycle. Sometimes, conflicts can be carryovers from other projects, but in most cases, they are usually intertwined with the project itself and its deliverables.
More importantly, it can help IT and the business unit build appreciation and respect for each other. And isn't that what we all want?