In my previous post, I pondered how the inevitable lag time between the definition of requirements and the delivery of solutions is exacerbated by the business world fluctuating dramatically in short periods of time. Today’s business requirements may not only be different than yesterday’s business requirements, but today’s business requirements might be different before we even get to tomorrow.
“It is not only the lack of speed which causes problems,” Christian Fürber commented. “Another major issue is the lack of precision in which people express requirements. Imprecise requirements often lead to misunderstandings due to their ambiguity. Moreover, some requirements are never asked for, but always expected (cf., the Kano model). When people cannot see the future product they also may not ask for certain features, yet. I experienced sufficient results to solve these problems by providing a standardized vocabulary for expressing requirements. People not only save time, but are also precise when they are able to express requirements in a standardized way.”
Tappers and Listeners
In their great book Made to Stick: Why Some Ideas Survive and Others Die, Chip and Dan Heath explained how Elizabeth Newton earned a Ph.D. in psychology at Stanford University by studying a simple game in which she assigned people to one of two roles: tappers or listeners.
Tappers received a list from which they selected one well-known song (e.g., “Happy Birthday to You”) and tapped out (by knocking on a table) the rhythm to a listener, whose job it was to guess the song based on the rhythm being tapped. Over the course of Newton’s experiment, listeners correctly guessed the song only 2.5 percent of the time (3 times out of 120 songs).
“But here’s what made the result worthy of a dissertation in psychology,” the Heaths explained. “Before the listeners guessed the name of the song, Newton asked the tappers to predict the odds the listeners would guess correctly. They predicted that the odds were 50 percent. The tappers got their message across 1 time in 40, but they thought they were getting their message across 1 time in 2.”
“Why? When a tapper taps, she is hearing the song in her head. Meanwhile the listeners can’t hear that tune — all they can hear is a bunch of disconnected taps, like a kind of bizarre Morse Code.”
Stop Tapping and Start Talking
Therefore, I definitely agree with Fürber about the need for expressing precise requirements using a standardized vocabulary. Otherwise, IT Listeners will struggle to understand Business Tappers, and Business Listeners will also struggle to understand IT Tappers.
Stop tapping and start talking about requirements — in a language that everyone can understand.
2 Comments
Hi Jim
I love the point made by the 'Tappers and Talkers’ study. It definitely highlights how badly we can describe our requirements because we overestimate our ability to communicate effectively.
Sadly, getting people to start communicating in a 'standardised' manner all too often exacerbates the problem. What tends to happen is that business people start to use IT jargon when defining their requirements, truly believing that this will help.
The problem is that jargon, contrary to what its users’ believe, is actually a major barrier to effective communication. This is because the person speaking and the person listening both have an entirely different understanding of what each jargon term means. Neither knows (or is willing to admit) this.
Jargon, is ‘a standardised way of communicating’, that all too often turns ‘Talking’ into ‘Tapping’, giving results something like this:
“We need an ERP that is web enabled with cloud-based capability. We need both synchronous and asynchronous interface capabilities with a very thin client element. Although we admit it has benefits, we will have no funds to produce fully normalised data structures. Referential integrity, although desirable, may have to be sacrificed. We will need to limit the depth of process models to level three and will not have time to level them. Apart from that, the new system must give us all that we have now and simply run faster with less errors.”
There are two responsibilities when establishing requirements. The first is, 'I must clearly convey my requirements to you’. The second is, 'I must unambiguously establish what you require'.
The first responsibility can also be stated as, 'I must clearly sing the song in my head out loud to you'. The second as, ‘I must closely listen to all that you actively say (or sing) and even more closely to all that you directly or indirectly infer, though do not say.”
Regards
John
Thanks for your comment, John.
Excellent example of requirements essentially sent via a Jargon Telegraph.
And great point about what I would call the need for Singing Lessons to complement the need for Listening Lessons so that we can effectively both communicate and understand requirements.
Best Regards,
Jim