Brûlé’s Rules of Playing Telephone with Requirements

You remember the game of telephone, right? The test of communication skills where one person whispers a message to his neighbor, and that message is translated multiple times from person to person until eventually, the last contestant repeats her interpreted message aloud. The goal is for the final person in the chain to correctly hear the original message, but invariably, there is laughter all around as the message is misconstrued.

When this happens in business however, it’s no laughing matter. When core messages are lost in translation along the command chain or vendor channel, it can manifest in lost revenue, poor morale or costly mistakes. When used as a business training tool, the game of telephone appeals to a myriad of industries and has educational value: the significance of articulation.

There is an army of business process outsourcing (BPO) experts chomping at the bit to provide goods and services to an organization, and their growing pursuit illuminates the relevance of telephone. There is a tendency to interpret information in very individualized ways, but as business analysts (BAs), we don’t want to allow for that. Rather, BAs strive for clear, concise and coherent articulation of requirements because it influences the outcome of solutions. BAs know that “winning” the game of telephone happens when both the client and vendor make a concerted effort to articulate needs and capabilities, then proceed to mash them up and make sense of the output.

Why is this issue relevant, and why is it so imperative to nail it? In today’s competitive business climate, most organizations don’t possess internal capabilities to design, build AND implement solutions, and therefore decide to outsource projects outside core competencies. For example, an accounting firm might not have the right employees to handle IT, nor can they clearly articulate their needs to drive technology solutions, so they outsource their tech needs to IT specialists. But the accountants will fail if they presume the techies are both experts in IT AND experts in understanding requirements. Such an assumption happens too often, and when it does, no real solution is achieved… resulting in vendors held accountable for failures beyond justifiable measures. In actuality, articulation of requirements is the responsibility of ALL involved parties.

Consider this illustration of how important is the clear enunciation of business needs and how easy it is to fail at communicating even the simple messages. Stop for a minute and carefully, deliberately read aloud or write down these phrases:

Surprisingly, only one in 40 people accurately read the phrases and catch the repetition: “THE THE”, “A A” and “THE THE”. In contrast to the challenge of something as straightforward as this riddle, the responsibility of designing complex solutions – and communicating their requirements – to meet critical business needs is crucial. Then layer on the challenges of cultural bias, language contrast and differing levels of expertise, and you have one very difficult game of telephone indeed.

If you find yourself in the midst of a game of telephone when it comes to translating business requirements, here are some deliberate rules to bear in mind:

1. Assume the lowest common denominator. Never give ANYBODY the opportunity to interpret your written word. It’s possible to avoid misinterpretation by writing needs in a concise manner with clarity and coherence. In order to follow this rule – the 3 Cs – you must ensure that the phraseology used is clearly defined. For instance, if you were traveling in a foreign country with a language barrier, you’d still be able to navigate the process of boarding via your boarding pass because this air travel standard is clearly defined for all users. In business outsourcing, key terms like “user” must be clearly, coherently and concisely defined for everyone, regardless of demographic, culture, level of skill or job type.

2. Draw a roadmap, follow it to a ‘T’ and prepare for roadblocks. Be absolutely certain the driver (project owner) is clear on the directions (requirements). The owner of the requirements roadmap must plainly dot the Is and cross the Ts in unmistakably universal language. Said roadmap describes the tasks to take in order to arrive at the destination, such as selection of approach, consideration of integrated project teams and available tools. BPOs should clearly understand how the business is run before, and as part of, properly establishing job requirements. Yet in contrast to thorough planning, an element of flexibility is essential. Perhaps on a road trip we make an unplanned stop? Extra time and gas allow for surprise diversions. In business, you must monitor events to anticipate potential cost overruns or changes in requirements and prepare for such plausible detours accordingly.

3. Lost in translation is not an option. In the global world of business – and travel – there is no room for a language barrier or misinterpretation. Misunderstanding can send you to the wrong destination, i.e. potential disaster ensued by mistaking the women’s restroom for the men’s. The best way to avoid confusion is to create universal signage explicitly indicating words that must be defined to ensure clarity—like user, task or error. Identify all critical vocabulary terms that must be clear for requirement fulfillment. Then break down and decompose each word to clearly understand the meaning. Definition development is the most appropriate means to approach BPO requirements.

4. Know your audience. Pride of ownership is important. Telling everybody about every detail in an infinitesimal manner is not. By knowing your audience and adapting your methods, language and content, you communicate in a way that can be heard. For example, if an employee walks a busy boss through the diminutive details of his project, right before the boss’s own deadline, the boss would certainly be annoyed by the time suck. The chief just wants the bottom line. But a peer might share interest in the minutia and want to brainstorm and collaborate during a slow period. Everyone in the airport, or shall we say, the complete project ecosystem, doesn’t need – or want – all the details. The check-in agent only wants to know your final destination…. the accounting department only wants their invoicing question answered. Each person involved simply wishes to reach the destination, meet expectations and accomplish their tasks. Thus who receives what information, of relevant quality and quantity, is important. Remember, be deliberate about what you share, when you share it and whom you share it with.

5. If they present a requirement, they own it. Much like travel agents, BPOs or BAs might be the translator of all things, but psychics? No. The greatest pitfall in developing and managing requirements is unwittingly acquiring ownership of – and accountability for – those requirements. In actuality, stakeholders own and are responsible for requirements, not BAs. As analysts, the more we can motivate others to articulate requirements, the more the responsibility accurately falls on their shoulders. You can do this well by probing through the creation of stakeholder maps, making certain roles/requirements are defined and encouraging active participation among the right audience members. In fact, active participation in the requirements management and development process can lead to a greater appreciation for the output.

6. Measure and measure again (and again….and again). Assessment and validation of one’s work should never be underestimated. Take a pit-stop snack of humble pie, reminding yourself that triple checking is not about your shortcomings, but rather the perfection required of the product being developed, as well as an opportunity to learn from mistakes. In a world where everything moves at lightning speed, we cannot be too quick to jump in the car and simply drive, nor can we just exclaim, “Here’s the requirement; now let’s go!” To ensure that the trip we embark on is one we want to take, it’s imperative to deploy a succession of checks and balances. One small change in the plan can impact all its other parts and pieces…hence everyone involved needs to constantly observe the project’s progression to avoid costly mistakes. Check your ego at the door and ask for a fresh set of eyes to review the work. Furthermore, implement a series of peer reviews as part of a regular routine, much like the regularity of checking your car’s oil.

7. Jack be nimble, jack be quick. Every iteration of the process should produce clear, tangible artifacts that have high value, every time. Much like the theory of prototyping, items need not be built to perfection immediately, but rather yield an evolution where subsequent versions improve upon one another. The first airplanes in modern history certainly weren’t comparable to the sophisticated aircraft we fly on today. The agile approach is a strong business paradigm…it builds unmistakable, high-quality, tangible deliverables that continue to evolve and advance. In this model, errors – such as defects or misinterpretations – can quickly be realized, relayed and remedied at a minimal cost and are a great opportunity to build upon that which we glean from previous prototype versions. In short, don’t suffer from analysis paralysis in striving for perfection. Rather, learn from your mistakes in an iterative fashion – thereby mitigating costs – and improve on the product as you progress.

8. Quality AND its quantification both matter. How can anyone argue with flying first class? It’s the premier definition of quality. But if we haven’t quantified the impact of that measure – for instance, are we first class on a one-hour flight or a 12-hour flight? – we haven’t proven how it influences the net result. Here’s another example: say your business developed an application to increase efficiency of time elapsed in customer service response (quality). Without understanding how this translates into increased revenue, profitability or efficiencies (quantification), we as BAs have missed the value boat. Quantification of outputs is at the heart of quality, and when we prove quality improvements have an effect on the bottom line, the purpose becomes clear to all stakeholders on the telephone tree.

There you have it…my eight rules for playing telephone with requirements. If you follow these guidelines, I’m certain you will positively influence the outcomes of solutions. Here’s the bottom line: to be successful BAs in today’s global, outsourced environment, we MUST ensure that we – and everyone throughout the ecosystem – clearly articulate what we are doing, what we are trying to accomplish and what we are delivering. When we outsource and try to communicate from one side of the world to the other – both literally and connotatively – misinterpretation is likely. That’s why regardless of our methods or approaches, it’s essential that we deliver the right information to the right people, all the way throughout the (telephone) chain. Now THAT’S a trip worth taking.

Author: Glenn R. Brûlé, CBAP, CSM, Executive Director of Client Solutions, ESI International brings more than two decades of focused business analysis experience to every ESI client engagement. As one of ESI’s subject matter experts, Glenn works directly with clients to build and mature their business analysis capabilities by drawing from the broad range of learning resources ESI offers. ESI, a subsidiary of Informa plc (LSE:INF), helps people around the world improve the way they manage projects, contracts, requirements and vendors through innovative learning. For more information, visit www.esi-intl.com.

NOTE: Top article image © Noam - Fotolia.com.