IT project managers are the translators for the business world.
They can speak both code and business, and use their knowledge of both to help both sides of an organization communicate.
Sometimes, being a translator for your company can be the most frustrating aspect of a project manager’s job.
Jason Cohen provides a great analogy for technical communication with non-technical customers. It’s like a doctor explaining the complications of a disease to a patient. He writes:
There is nothing you can do because this field requires years of education and real-world experience. The complexities and context of the field are difficult to convey to even intelligent laymen.
Trust your doctor.
Although it won’t improve your relationship with your customer by sharing this analogy, it can help you to see the severity of the situation. It doesn’t matter how much you explain, or how desperately you wish your customer had the same technical knowledge and experience, sometimes your customer won’t “get it.”
These tips are intended to help you communicate effectively with your non-technical peers. While it won’t magically make them understand technical processes and procedures, these tips will help project managers to keep the scope and completion criteria under control while still adhering with business drivers.
Use existing project management processes.
Many people in the tech industry have switched to Agile because it’s easier and more efficient. Although Waterfall methodology is easy to understand, it doesn’t account for knowledge issues at the beginning of any project. The right method can improve communication between you, your customer, and yourself.
Scrum is a form Agile that emphasizes the “inspect and adjust” feedback loop. The product owner must have a vision of the final product and be able to refine it as the project progresses. He or she must act as a barrier between the technical team members and the stakeholders. Product owners are more successful with customers if they focus on the “what,” rather than the “how”. Listen more than you talk and think about the ideas for the final product.
via Scrum Alliance
The product owner should “own” communication between the technical team and stakeholders. Scrum is a process that allows you to limit communication to one point. You don’t want your entire tech team trying to interpret vague “whats” from customers.
It’s important to note that sometimes sticking to process 100% can be burdensome. Capterra relies 80% on Agile. However, Agile requires flexibility. If there is more than one person communicating between our technical team and our business development team, we don’t insist on sticking to process.
Avoid task limbo
The problem with Agile methodology is that there are so many variables at play, it’s easy for tasks to slip into limbo. I refer to a situation where the project manager has not decided whether the team should move forward with a task. This is likely because she or he hasn’t confirmed that the product manager or stakeholders want it.
Projects can be ruined by limbo. Key product features are lost without cause, adjustments that should have taken place earlier in the project are delayed until the last minute, and new requirements are added to the project.
There are two ways to avoid this problem. The first is to force your project management team or stakeholders to make a decision: do or don’t do. This should be done for every project task or requirement.