All disciplines and functions develop their own language and terminology that allows them to develop and understand each other. The problem is that in doing so they become impenetrable to outsiders to the extent that they become closed shops. This might be a good thing, keeping that expensively acquired expertise on the inside. But if that group has to work with people ‘on the outside’ (tell me of a group that doesn’t) then continuing with the same language and terminology won’t help at all.

More Than One Skill Set

One of the professions where this is particularly prevalent is Project Management (I include Programmes here too) since project people, almost by definition, have to interface with people outside of their team. Many project people often have a primary discipline and add project management to their skill set or become project management specialists who can adapt to different sectors.

Either way, the need to communicate with sponsors, stakeholders, clients, end-users, suppliers, senior managers within the business and others is paramount. And communication, let’s not forget is a two-way thing. It’s all very well using commonly understood language within a close-knit team of similarly experienced professionals but to use that language when communicating outside of that group leads, at the very least, to confusion. At worst it leads to distrust since people will think they are having the wool pulled over their eyes with all the technical jargon being spouted.

Are Project People That Different To Others?

So why is this different for project people when compared to other technical disciplines? Well in many ways it isn’t, all professionals need to consider their communication skills extremely carefully when talking with those outside their discipline. This becomes more and more important the higher up the management chain people go as they start to work across functions more. For project people however this working across functions and disciplines occurs almost from the off, at the ‘working level’. Very few of those leading and working in project teams haven’t the developed (so called) soft-skills that are needed to operate effectively with non-project people?

So what’s the best approach for project people when working with non project specialists? It all revolves around getting the communication right which means ensuring understanding and reducing conflict within businesses and between businesses.

  1. Practice using non-technical language when describing work to each other so that it becomes the norm. If needed, bring in an outsider who has knowledge of the business but not necessarily the project itself and see if you can explain to them just what it is you are doing – treat it as an informal peer review.
  2. Spending more time with stakeholders to ensure you have an excellent understanding of their expectations and that they appreciate your particular role in a project engenders trust. In doing so stakeholders start to develop an understanding of the project terminology being used. But make sure that you keep an eye on body language and facial expressions. When you pick up that someone is confused with what you are saying or simply doesn’t follow it at all, explain in clean language just what you mean. Not all stakeholders will confront you directly when they can’t follow what you are on about, silence isn’t agreement.
  3. Be attentive to the language used by non-project people especially when they start to pick up on some of the project terminology itself. What might seem obvious to a project specialist such as the meaning of Critical Path, may not be the same for a non project person who might think its a list off all the tasks they think are important. It is the responsibility of all professionals, not just project people, to ensure that others fully comprehend what their expertise offers – allowing misunderstandings to persist does nothing more than breed distrust for the profession as a whole.

So it comes down to excellent communication skills at the end of the day. This isn’t something that gets covered in project management training too often. Use the language of the profession within project meetings and discussions. Don’t use it to hide behind and bewilder the very stakeholders you need to ensure the project you are working on gets delivered and, above all else, accepted.

Follow Paul Slater on Twitter

© Paul Slater and Reflect & Lead, 2014.


Leave a Reply

Your email address will not be published. Required fields are marked *