Let’s face it: tech language is complex and sometimes it’s very hard to be able to effectively communicate between two entities that have different lingos that are not only related to the kind of activities that they carry out, but also to the mentality that working in a specific sectors embeds in people’s minds. The main problem is not this diversity but the fact that this is one of the elements that usually gets seriously underestimated when setting up specific cross functional initiatives.

Having worked for more than ten years on complex technology transformation projects I have experienced that, besides the time, the effort  and the good will of the people committed to these initiatives if the organization doesn’t make some specific and yet simple preparatory steps, your project is going to crash and burn soon.

The IT-business interaction paradigm is one good example of how you might be sitting on a “collaboration bomb” without even knowing it. The information flow between the “IT domain” and the “business domain” has always been complicated by factors for which both parties are accountable for. Both can be very complex and require specific competencies and deep knowledge with the risk of creating the well known and feared “silos approach”.

The problem becomes even more important when we bring a third party, such as a vendor or a system integrator, into the picture. Now we will have several different perspectives that will have to be “translated” in order to ensure project success: the “product oriented” attitude of the business stakeholders that is focused on the final product or service that will be delivered; the “project oriented” language of a system integrator that tries to drive the progress of a project toward its completion and the “service oriented” mindset of internal IT that will have not only to provide services during the project, but most probably to provide application and system maintenance services once the solution will be live.

So what are the actions that can be put in place in order to have the different actors of this Babbel effectively communicating and working together and enable us to defuse the “collaboration bomb”? Here’s a few tips:

  • Write a “vocabulary”: sit together with your representative from IT and business and spend some time in defining a common taxonomy assigning to each term a shared meaning. Where possible try to align to industry or international standards even though a certain degree of flexibility should be allowed for companies peculiarities to be taken into account.
  • Use a “Translator”: sometimes it is very useful to have a person within an organization that could work as a “translator”. This is one of the main drivers of why IT Demand Managers were created and are continuing to be recognized as valued professional in most companies. Combining both IT and business knowledge that will be enable, drive and facilitate transition and communication, ensuring that business needs are correctly accounted for and fulfilled on one side and helping in making perceived by the business technical needs and constraints that IT will have to abide to, on the other.
  • There’s only “WE”: as soon as you get into a project there should be only one pronoun allowed: WE. The project team wins or loses together. When we work on a project we are all on the same side and we work more as a football team where the Project Manager is the coach and the different functions are its positions. What good would it be to have an exceptional striker if our midfielders are not able to get possession of the ball and serve them, or if your defense is not able to block the rival team’s incursions? When WE are the drivers of the project we immediately close  the door to the “blaming game” where people’s priority is more to expose themselves as less as possible then to achieve the project’s objective and we get into a win-win mindset that will foster success.
  • Value the cultural mix: there’s the vastly diffused (wrong) conception that cultural differences are a debilitating factor for the project while they are instead a big resource for both the single initiative and the organization. Be aware that when I talk about culture i do not only mean the one determined by the nationality of a specific person but also the one determined by its background and profession. Each one of these cultures has strengths and weaknesses: choose your  team carefully and create a mix that compensates the weaknesses and amplifies the strength and you will be one step closer to successfully completing your project.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Protected with IP Blacklist CloudIP Blacklist Cloud