In my field of Systems Engineering, one of the most important disciplines is Requirements Management, which is how you ensure that what you build corresponds to what the customer is asking for. The customer tells you what they want in their contract, you describe it back to them to make sure you both agree what is required, then you build it, making sure what you design/build/develop/produce matches up with the original request. It’s a pretty straightforward concept, even when described using only the most common thousand words in the language. Despite this, problems arise time and again, and there are classic diagrams which keep surfacing in seminars and powerpoints the world over.
At the weekend I was having a rest after taking the dog for a hike, and while flipping TV channels I saw that the seminal “rockumentary” This is Spinal Tap was on, so I watched for a while. On a side note, it’s worth repeating that stars Christopher Guest and Michael McKean are widely agreed to do the best English accents by American actors in a movie.
Anyway, there is a classic sequence in the movie which illustrates the need for clear requirements definition and management. In a creative rut, the band decide to resurrect an old popular favorite song, ‘Stonehenge’, complete with a dramatic new piece of scenery. Guitarist Nigel Tufnell (Guest) sketches what they want on a napkin, and manager Ian Faith (Tony Hendra) takes the napkin and says, “Consider it done.”
Later, when Ian goes to see how the artist (Anjelica Huston) is doing with the job of building the scenery piece, he discovers that what he thought was a small scale model prototype is actually the final finished piece.
Ian: Are you telling me that this is it? This is scenery? Have you ever been to Stonehenge? Artist: No, I haven't been to Stonehenge. Ian: The triptychs are...the triptychs are twenty feet high. You can stand four men up them! Artist: Ian, I was...I was...I was supposed to build it eighteen inches high. Ian: This is insane. This isn't a piece of scenery. Artist: Look, look. Look, this is what I was asked to build. Eighteen inches. Right here, it specified eighteen inches. I was given this napkin, I mean... Ian: Forget this! F**k the napkin!!!
So Ian is angry that the artist interpreted the instructions too literally. He thinks she should have understood from context that they wanted something 18 feet high, or better still asked and clarified the requirement.
I’m assuming there was no time to build the set the proper size, because the show goes ahead, the tiny Stonehenge makes the audience laugh, and there is an angry confrontation between Ian and the band afterwards.
David: I do not, for one, think that the problem was that the band was down. I think that the problem may have been that there was a Stonehenge monument on the stage that was in danger of being crushed by a dwarf. Alright? That tended to understate the hugeness of the object. Ian: I really think you're just making a much too big thing out of it. Derek: Making a big thing out of it would've been a good idea. Ian: Nigel gave me a drawing that said eighteen inches. Alright? David: I know he did, and that's what I'm talking about. Ian: Now, whether he knows the difference between feet and inches is not my problem. I do what I'm told. David: But you're not as confused as him are you? I mean it's not your job to be as confused as Nigel is. Ian: It's my job to do what I'm asked to do by the creative element of this band. And that's what I did.
Interestingly, Ian defends the problem with the size of the set by saying, “I do what I’m told”. He doesn’t blame the artist, he takes her excuse and makes it his own.
So what should have happened? One of the following would have prevented this problem arising.
- When Nigel drew the napkin, Ian or one of the others should have looked more closely at it, considering they all know how “confused” he is.
- Ian should have spotted it when handing to the artist.
- The artist should have spotted it and asked for clarification.
What’s the lesson? I’m not sure it’s a particularly flattering lesson as regards the customer –
- Don’t take any requirements from the customer at face value, especially if they seem unreasonable (the requirement, not the customer).
- Make sure requirements are properly documented, clarified and agreed (no napkins (or emails)).
- Ensure the project timescale has plenty of room for errors to be fixed (Hahahahah OK I’m just joking with that one).
Wrangling requirements can be tough. Balancing the “wants” of the customer with the “cans” of the project can be pretty stressful. Then again I’m sure I’d feel much worse if I weren’t under such heavy sedation.