The Requirements Gap – What to do When Something was Missed
In a Seinfeld episode, Jerry takes his car to an unknown mechanic. For Seinfeld fans, Jerry was on the outs with Puddy at the time. Anyhow, Jerry is talking to George, questioning a $2000 repair the mechanic suggested, and George’s response is: “Well, of course, they’re trying to screw you! What do you think? That’s what they do. They can make up anything; nobody knows! “Why, well, you need a new johnson rod in here.” Oh, a Johnson rod. Yeah, well, better put one of those on!”
When implementing software and there is a clear gap in understanding – this episode goes through my brain. If you are the customer, and the vendor or product suggests something that seems off – it’s the Johnson Rod. If you are the vendor or product, and the customer is adamant that something should work the way they want it to – Johnson Rod.
In the end, I often find that few people are trying to “screw” each other. Usually, it’s just a clear gap in understanding. Whether customer, vendor, or product, a misunderstanding must inevitably be addressed during any software implementation.
The Requirements Gap in Action
Over a decade ago, I was implementing localization workflow software for a customer. The software facilitated the translation of advertisements into multiple languages while maintaining all branding via Adobe InDesign. The software would take Ads ranging from posters to huge 3-story wall hangs and allow the creative Director to change the language. It was a pretty slick software offering and would help the customer who flew every regional translator into the US to localize their advertisements for their major Product releases. Everything on the implementation went well until we ran into ‘the Implementation Gap.’
About six months into the project, we learned that all Creative files were saved as one Gig or higher – to support the possibility that any file may be turned into huge 3-story wall hangs. This was a crazy concept and was unique to this customer at the time. Yet this customer had no idea that this was special. Additionally, every test file prior was much smaller until we tried to push this to production. Everything choked on the amount of 1GB files running through the translation platform – including the network. So, this was the moment – assign blame or solve. In the end, it made no sense to save every file in that manner, and luckily, the customer agreed to reduce their file sizes. Still, we were all panicked – vendor, partner, and customer.
The Lesson
The main challenge with the Requirements Gap is that it’s often challenging to vet during Pre-Sales conversations. We would never have thought to ask: Do you save your files as everyone else? It’s not even a question that we thought was a question. We did ask that question but received only file format options – not sizing variability. And the files we did receive were significantly smaller. Conversely, the customer had no idea what they were doing was unique and potentially problematic to the implementation.
The only real solution was to change the requirement, but many organizations often choose to abandon the software. What makes “abandon the software” such a horrible option is that it avoids a necessary change. Quitting the software is the equivalent of any end-user who chooses not to use the new software because it’s new. Very rarely is an implementation gap something that is a true showstopper. In the case of this customer example, they chose to navigate around the gap.
One thought on “The Requirements Gap – What to do When Something was Missed”
Thanks! This is something of which I very much needed to be reminded today. Your timing is impeccable.