Critical Skills Needed for Project Success – Part 2 Translation
This article is part of a series and presents the second critical skill that all project managers (PMs) and business analysts (BAs) need for success. This one is about the importance of being able to translate technical complexity into business language. As the technology in organizations has become not only increasingly important to its success but also more complex, the need for business stakeholders to understand its true value has increased accordingly. Both PMs and BAs need to talk to their stakeholders about technology, its use, its value, and the results it produces. The language they use has to be about both the technology and the business and be stated in terminology that stakeholders understand.
BAs have always been translators. From the early days of business analysis to the present we have translated business requirements into specifications that could be designed, built, tested, and delivered. But translation has never ended there. We take technical designs and specifications and translate them back to the stakeholders to be sure they understand what they’re actually getting. We have been translators as technologies and methodologies have changed. So being a translator is nothing new. What’s new is that with more complex technologies like AI, the importance of translation is being recognized.
Advertisement
[widget id=”custom_html-68″]
Years ago I started a new job as a PM. The team was full of technical jargon when they talked to me (OK) and in their discussions with stakeholders (not OK). I encouraged them to translate what they were saying into business language. So instead of talking, for example, about DB14 or problems with Joe’s program abends, I encouraged them to translate these issues into business language–to talk about Price information and how to fix the results caused by program errors. At first there was resistance, but gradually there was a focus on the business and not the technology. I’m not sure the team was entirely bought into a business focus. After all it’s cool to be able to talk techie. But I had several sponsors comment on the positive change.
The fact is, the more complex the technology, the greater the need for us to help stakeholders understand our elicitation questions so that they can make good business decisions and understand the ramifications of their decisions.
OK, so BAs have always been translators. What in it for PMs? We PMs spend lots of time with our sponsors and executives. I know how tempting it is to try to impress them with our technical prowess. We can easily fall into the trap of thinking we’re adding to our credibility by showing how fluent we are in the technical language. But far more impressive is understanding the technical terms and concepts well enough to clearly explain how the technology provides value to the organization.
To be successful translators, we need to understand not only the technology, but the business, including the industry, the organization’s goals and objectives, and the specific business area. But what does “understand” mean? On an AI project, for example, we don’t need to understand the details of model creation, but we do need to know that the algorithms being used further the business objectives. We need to be conversant enough in the technology to formulate our questions as well as answer questions that arise.
3 techniques for effective translation
Visual business models are among the best tools for the translator. Process, data, use case, and prototype models help the technical staff better understand the business requirements. Models abstract detailed information and present it in a way that’s useful to all audiences. Abstraction, of course, is the process of filtering out extraneous information, leaving only the essential details. Most people find models way more useful than requirements written in a lengthy list of “shalls,” which is how we used to document them.
When we translate, we also need confirmation from the business. Visual business models help translate back from the technical to the business stakeholders. The emphasis, of course, is on business models, because we don’t want to hand technical specifications or designs to our stakeholders without translations into business language.
Synthesis. Being able to translate means we need to take in a lot of information at once and almost instantaneously sort through it, discard the extraneous, and present the most important concepts. What helps us is understanding the context of the topic at hand. And we need both business and technical context. This allows us to take disparate facts gotten in previous conversations and put them back together in a framework that helps the business understand what we’re talking about and how they’re going to get value.
Elicitation. In Part 1 I covered elicitation, saying that we ask questions and listen to the responses, and that’s how we learn. There are times during translating when we need elicit information. For example, if we’re providing stakeholders information on AI results based on the algorithm used to create those results, we may want to ask the model creators why that algorithm was used or how it helps the business. Once we have this information, we can be confident that our explanation to the stakeholders is both technically accurate and valuable to the business.
Translation is critical to project success. It’s one of those skills that sounds easy, but which takes knowledge and a mastery of various skills. Translation is part of what distinguishes us from the order-taking BAs and PMs who are less valuable to our organizations.