The Broken Telephone Game of Defining Software and UI Requirements by Martin Crisp.
Martin is writing in a UI context but the lesson he teaches is equally applicable to any part of software/project management. (Even U.S. federal government big data projects.)
His counsel is not one of dispair, he outlines solutions that can lessen the impact of the broken telephone game.
But it is up to you to recognize the game that is afoot and to react accordingly.
From the post:
The broken telephone game is played all over the world. In it, according to Wikipedia, “one person whispers a message to another, which is passed through a line of people until the last player announces the message to the entire group. Errors typically accumulate in the retellings, so the statement announced by the last player differs significantly, and often amusingly, from the one uttered by the first.”
This game is also played inadvertently by a large number of organizations seeking to define software and UI requirements, using information passed from customers, to business analysts, to UI/UX designers, to developers and testers.
Here’s a typical example:
- The BA or product owner elicits requirements from a customer and writes them down, often as a feature list and use cases.
- The use cases are interpreted by the UI/UX team to develop UI mockups and storyboards.
- Testing interprets the storyboards, mockups, and use cases to develop test cases,
- Also, the developers will try to interpret the use cases, mockups, and storyboards to actually write the code.
As with broken telephone, at each handoff of information the original content is altered. The resulting approach includes a lot of re-work and escalating project costs due to combinations of the following:
- Use cases don’t properly represent customer requirements.
- UI/UX design is not consistent with the use cases.
- Incorrect test cases create false bugs.
- Missed test cases result in undiscovered bugs.
- Developers build features that don’t meet customer needs.
The further down the broken telephone line the original requirements get, the more distorted they become. For this reason, UI storyboards, test cases, and code typically require a lot of reworking as requirements are misunderstood or improperly translated by the time they get to the UI and testing teams.