IT project managers are the translators of the business world.

They speak code, they speak business, and they use their knowledge of both fields to get both sides of the organization to communicate.

And sometimes, acting as your company’s translator can be the most frustrating part of a project manager’s job.

The problem.

Jason Cohen offers a fantastic analogy when it comes to technical communication with nontechnical customers—it’s like a doctor trying to explain the complications of a disease and the risks associated with a treatment to a nonmedical individual. He writes:

In the end there’s nothing you can do, because this is a field that takes years to master, in both education and real-world experience, the complexities and context of which cannot be satisfactorily transmitted to even an intelligent layman. You’re going to have to trust your doctor.

Unfortunately, offering up this analogy probably won’t help your relationship with your customer, but it does shed light on the severity of the situation. No matter how much explaining you offer, how much you so desperately might wish that your customer has the same experience and technical savvy you might have, there will be times when your customer just won’t “get” it.

With that in mind, these tips are meant to help you communicate with your nontechnical peers. It will not magically make them understand technical processes, but these methods will help project managers keep scope and completion criteria in check while adhering to business drivers.

Use existing project management processes.

There’s a reason why so much of the tech world has moved over to Agile. While Waterfall methodology offers an easy-to-understand approach to project management, it doesn’t account for knowledge problems at the beginning of any project. Using the right method can help improve communication between you and your customer.

Take Scrum, a form of Agile that emphasizes an “inspect and adapt” feedback loop. It’s up to the product owner to have a vision of what the final product might look like, and to refine his or her “vision” of the project as it progresses. She or he must act as the barrier between the technical team and the stakeholders. Product owners are most successful with their customers when they focus on the “what” instead of the “how.” Focus on the ideas of the final product, and make sure you listen far more than you speak.

Use the product owner to “own” the communication between technical team and the stakeholders. In this particular case, Scrum offers a formal process to narrow communication to a single point—you don’t want your whole tech team trying to translate the vague “whats” coming from your customers.

With that said, it’s worth noting that sticking 100% to process is sometimes burdensome. At Capterra, we rely 80% on Agile, but Agile necessitates flexibility, even from its own process—if there needs to be more than one point person communicating between our technical team with our business development team, we don’t stubbornly hold on to process just for the sake of process.

Avoid task limbo.

One frustration with using Agile methodology is that because so many variables are in play, tasks can all-too-easily fall into limbo. By “limbo,” I mean a state where the project manager has not defined whether the team should go forward with a specific task—likely because she or he hasn’t confirmed that it’s what the product manager or stakeholders want.

The consequences of limbo are potentially deadly for a project—key product features are foregone for no reason, adjustments that should have been made far earlier in the project are held off until the last minute, and new requirements derail project plans.

There are two ways to avoid this problem. The first is forcing your project management team and stakeholders to make a choice: do or do not do. Make this decision with every project task or requirement. If that decision cannot be easily made, there is likely a communication failure. Whether this failure comes from stakeholders, team members, or project managers, forcing the “yes or no” question will increase project efficiency and communication problems.

The second way to avoid limbo is employing project management software. For example, there is project management software specific to increasing project communication (like Asana) or designed to support Scrum and Agile (like Atlassian Jira). Either way, project management software is an excellent resource to help define what is unknown and create a path to addressing those variables.

Aim for complete communication.

At the end of the day, there’s no replacement for in-person communication.

Complete communication is all about working with your customer to help them understand difficult concepts in layman’s terms. While collaboration software can assist project managers hoping to work with their stakeholders, nothing can replace the nuance involved in in-person interaction.

Ever listen to someone try to communicate with someone who doesn’t know English very well, and instead of trying to explain the idea differently, they just speak louder? This problem persists for project managers as well.

Raj Chilakapati, Capterra’s lead project manager, emphasizes using more than just verbal communication to explain ideas. For example, visuals, he explains, are particularly good at representing concepts to nontechnical customers.

In sum, use the communication tools available to you. This means writing out explanations for difficult technical processes, verbally breaking down ideas, and even using diagrams and presentations to communicate potential issues. Use every resource available to be clear, concise, and concrete when working with your customers.

More?

What other ways do you recommend to increase communication between technical project managers and nontechnical customers? Do these methods work for you? Leave your thoughts below!