Creating a set of shared principles
Sometimes, it is easy to get people to agree. That most frequently happens when everyone agrees with the criteria for deciding "what is right." If two passionate people both believe they are right, but they are right for different reasons with different results, agreement is impossible.
You have to make sure that everyone sees the problem in the same way. That requires everyone to bubble up their requirements into the common 'basket' and to see the value in each other's needs.
This is the essence of what we call the "Common Requirements Vision." This is a document created mostly by listening to the needs of teams that are measured differently. In creating this document, you are, in effect, creating a balanced scorecard. There has to be a way that everyone can see the measures that matter to them and recognize the measures that matter to others.
More importantly, things matter for different reasons. Juan may care about a particular application that he built, and may consider it a "requirement" that other teams use it in exactly the way he intended. Amhad may care about about a particular approach to using technology, because he believes that the philosophy reduces costs in the long run. Sofia may care about the ability to perform a specific business function efficiently, while Tina may care about providing a feature to the customers that she believes they will value.
Getting these different voices to agree on a particular solution is the apocrophyl "herding cats" but if you are a cat owner, as I have been for many years, it really isn't difficult to get all your cats to come to the same place... simply open a can of cat food. You've found something they all want in a way that they all expect to get it.
The common requirements vision provides a way to give the different voices a chance to be heard and valued.
Of course, you need a lens to measure the relative value of each of these ideas. Juan's care about his application is fine as long as that care aligns with the strategy and operations of the company. If he is passionate about his home-grown inventory package, and the company is merging with another firm that has demonstrated excellence in supply chain controls, his application may need to take a back seat. Getting him to agree to that won't be easy. You have to provide him with the lens that he needs to fairly evaluate the strategic value of his application.
You need to show Juan that each of the applications in a solution domain, like inventory control, have a fair shot at being considered. People tend to like the idea of fairness. Now find a measure that everyone agrees will be good for the company, like providing specific supply chain controls and supporting multiple currencies or supply chain networks. Then allow him to make the call: how well does my little home-grown application, right now, today, meet the needs of the sophisticated organization that my company has become?
Only then, will Juan agree to release his application and step back and see the value of moving the entire company to a shared inventory solution. Of course, I made this example up, but change the names and the solution domain, and you have a problem that is faced over and over... getting people who are emotionally opposed to doing the right thing to see the error of their ways.
What is that lens that will help this team of differently measured folks come together? It is business strategy. You have to help everyone measure their values against the stated and implict strategies of the business. We did that with Juan. We showed him that the strategy of the business was to get the best of the newly acquired company... by adopting their excellent mechanisms for supply chain controls.
Sometimes business strategy, the reason for the big decisions, is lost in the shuffle. Perhaps that business wasn't purchased because they are great at supply chain control. Perhaps they were purchased because, by purchasing them, the company removes a competitor or picks up a mature product to fill a gap in their product line. In these cases, the processes and techniques used by the other company did not drive the acquisition.
On the other hand, the strategy of the company may still include excellence in supply chain controls, and the company being purchased may have particular strength in that area. You may think it is a good idea to bring that strong suit to your company. However, they may have built that strength by creating a culture of values that conflicts with yours. Their values may have aligned with central control while your company may have valued independence of different business streams.
This is also a strategy, albeit a cultural one. The respect for the independence of each business area is a corporate strategy. The fact that it doesn't show up in the executive memos doesn't mean you get to ignore it. Nor should you assume it.
Write it down. It is part of your common requirements vision. "Strategy 4: Empower business leaders to solve their own problems quickly and independently." Make that opening verb strong. "Empower" implies both commission and omission. Providing a data driven business rules interface is commission. You are creating opportunities for agility. Building systems with simple connections that are easy to manage is omission. You are preventing the business from getting mired in red tape when they want to implement something new.
You cannot create a consensus on the right direction without these common principles, aligned to strategy, that show a business how they work with you to achieve common goals.