Home » Communication » Project Managers Quit Talking Jargon To Our Customers

Project management is often about learning to communicate in another language.  I’m not talking about a national language, but instead the language of the industry or domain that we are working in.

While I’m primarily an information technology and software guy, I’ve had to translate my expertise and jargon into such diverse domains as military command and control,  space based sensors,  graduate education and training, national intelligence gathering and analysis,  mobile phone development, and call center management.

The notion is that we must take our management expertise, especially in the area of project management, and translate that expertise (and jargon) into the domain of the customer or employer we are supporting. We must also translate the jargon and concepts of their domain so that we can understand what we need to do. This translation and learning process is probably one of the most difficult things a new project manager will need to do.  Often, we must both project manage and learn the knew language (domain) at the same time.  (For more ideas during this learning period, see why a process is a great thing to lean on).

Project Managers Quit Talking Jargon To Our CustomersOne mistake I’ve often seen is the project manager attempting to first get the customer to learn their language of project management (tasks, dependencies, resource levelling, earned value, etc.) This usually proceeds by the project manager looking at a tool such as Microsoft Project and asking questions so they can fill in the data asked for by the tool.  What we are doing is asking our customer or our project team, to translate what they do into our project management vocabulary.  Instead, we should work hard at understanding what they need or what they do and then based upon that understanding,  make our own translation of what needs to go into the tool.  We still show our customer or team what we’ve come up with and ask them if we have adequately represented what they have told us.

In one job, I had the position of being the company advocate for using advanced project management estimating techniques (e.g., SEER-SEM, Function Points, etc.).  In other words, we had a project to get all software development teams to adopt these advanced methodologies.  We would arrange meetings with the software development teams and talk to them about adopting the techniques.

On one occasion it was obvious that the development manager and his team were having this meeting only because they were told to talk to us by their senior management.  My team lead did the initial talking, explaining the estimating technique and why the development manager “had to” adopt it, because it was a government requirement to do so.  The development manager and team were clearly not happy but were stoically sitting through our presentation. I decided to cut in on our presentation and started  to ask the team questions about how they did their planning and estimating for each project.

Since I was an experienced software programmer and development manager, I could readily understand what they had been doing and ask a few leading questions. This helped to uncover the typical challenges they’ve encounter, which they would not have volunteered on their own.  We got into a fairly detailed discussion on what worked and what didn’t and I found a couple of key places where our new capabilities could help them. After a few minutes and seeing some excitement in them as they perceived something that might help them, the development manager looked at me in surprise and said “you are actually here to help us?” My team lead,  who was a bit perplexed that I had taken over his meeting, looked hard at me with a kind of “what just happened?” look.

The entire success of this meeting with based upon us being able to translate our project — which was to get the organization to adopt a new methodology — into the language of the development team.  It took more than just a presentation, offering training classes and a command to “do it.” The key factor was our assistance at understanding and being able to translate and adapt the methodology into the existing working environment of our customer.

As project managers, we should work at learning and talking in the domain and even jargon of our customers.  This will build our expertise as well as grow the respect and confidence our team and customers have in our project management abilities.

How well do you understand and talk in the domain language and jargon of your customers?

Thank you for sharing. Sharing and comments tells me which articles are most helpful to my readers:
Facebook facebook   Twitter twitter   Linkedin linkedin   Tumblr tumblr   Pinterest pinterest   Stumbleupon stumbleupon   Reddit reddit   Email email  

2 thoughts on “Project Managers Quit Talking Jargon To Our Customers

  1. Bruce Benson says:

    Comments from around the web:

    Mark Bresin • Bruce, Back in the 80’s we initiated a customer support effort to improve our TCS initiative. We identified our HiVi customers and assigned a number of 3 man/woman teams (Electrical, Mechanical and Marketing) that were very familiar with the specific products and represented Motorola as the faces to the customer for all issues regarding any quality or customer usage inputs. This was seen as very positive by our customers and led to numerous product improvements which enhanced customer satisfaction and also keyed in on (as you elude to) the understanding of the Language and/or Jargon that were sometimes unique to a particular customer. These teams had a profound effect based on accountability and ability to respond on issues in a timely fashion—-the customers really felt that they were being serviced, and communicated with in a very dedicated process.

    Bruce Benson • Mark,

    Great example as well as a good example on how to do something like this. Thanks for sharing.

    Bruce

  2. Bruce Benson says:

    Comments from around the web:

    Ajaya Gupta (LION™) • True, all stakeholders are not same…some are Technical others are Functional…one may deliver KPAs based on Delivery expectation f the stakeholder

    Bruce Benson • Yes, we need to adjust to each of our stakeholders and communicate with them in an appropriate way. This kind of flexibility and the understanding that this is what we need to do as a PM is pretty critical to having successful projects.

    Bruce

    Ajaya Gupta (LION™) • Presenting Project Preambles empathetically and Quest for Clarity in communications is the key

Leave a Reply

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

Name *
Email *
Website