Project management is often about learning to communicate in another language. I’m not talking about a spoken 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 new language (domain) at the same time. (For more ideas during this learning period, see why a process is a great thing to lean on).

One 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 leveling, 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?