Image by Steve Buissinne from Pixabay

Does this situation sound familiar?  Things are going along just fine.  And then they’re not.  There’s a glitch, a bug in the system.

Digging into the situation, you discover that the people who implemented the system didn’t understand what the system was really intended to do.  And then you hear the implementation team say something like, “Well, that wasn’t in the requirements.”

And they’re not wrong.  It wasn’t in the document labelled “Requirements.”  And it probably wasn’t in the requirements because the people who put together the requirements assumed the implementers knew what they were doing.

Not assumed that they were competent in a specific technical skill set.  Assumed that they knew what they were doing.  Understood how the system was going to be used.  Recognized the import and impact their actions have on the organization as a whole. 

In my experience, whenever “requirements” are involved, that assumption is always wrong.  In my experience, requirements are for people who don’t know what they’re doing.  The problem is that they’re often written by people who assume otherwise.

In my experience, requirements are for people who don’t know what they’re doing. If they did, they wouldn’t need the requirements.

Tracy Hunt

So where’s the flaw?  What is the root cause?  Is it that “it wasn’t in the requirements?”  Or is it deeper than that?  Is it perhaps that an ink-on-paper document entitled “Requirements” was necessary in the first place?

As an entrepreneurial business leader, when you engage people who are technically competent but who won’t take the time to truly understand what it is they’re doing…when you engage with people who are “requirements” based…you’re setting yourself up for tremendous disappointment and frustration.

Here’s a tip.

The next time someone asks for your requirements, tell them you only have one:  100% satisfaction.  When you find someone who delivers that, you’ve found a good companion.