Requirements flux


As Steve Jobs once said:

“You can’t just ask customers what they want and then try to give that to them.  By the time you get it built, they’ll want something new.”

The inevitable lag time between the definition of requirements and the delivery of solutions is perhaps the primary reason for the perpetual strife between the Business and IT.  I have previously posted about how The Business Must Go On and Necessity is the Mother of (Not Only Good) Invention to explain the challenge of the workarounds used while waiting for a solution becoming the de facto solution because the workaround worked well enough.  But in those cases, the requirements didn’t really change, it was just that the solution took too long to arrive.

The challenge that Jobs was describing, in the context of consumer technologies, is what I refer to, in the context of business technologies, as requirements flux — when business requirements change so much while waiting for the delivery of a solution that when the solution arrives it no longer solves a problem that the business has.  IT is often left frustrated by this scenario, especially when they followed the business requirements to the letter and diligently delivered exactly what was asked for.

When this happens, IT sadly echoes the lyrics from the song "So Cruel" by U2:

“I gave you everything you ever wanted.  It wasn’t what you wanted.”

It seems like requirements are even more in flux these days given the influx of fast-moving large volumes of various data and 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.

What Say You?

How does your organization deal with the complex challenge of requirement flux?

Please share your thoughts and experiences by posting a comment below.


About Author

Jim Harris

Blogger-in-Chief at Obsessive-Compulsive Data Quality (OCDQ)

Jim Harris is a recognized data quality thought leader with 25 years of enterprise data management industry experience. Jim is an independent consultant, speaker, and freelance writer. Jim is the Blogger-in-Chief at Obsessive-Compulsive Data Quality, an independent blog offering a vendor-neutral perspective on data quality and its related disciplines, including data governance, master data management, and business intelligence.


  1. Hi Jim,
    excellent article! It is about time to talk more about requirements management, especially in the data domain. In my opinion it is not only the lack of speed which causes problems. Another major issue is the lack of precision in which people express requirements. Unprecise 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 requirments. People not only save time, but are also precise when they are able to express requirements in a standardized way.

Leave A Reply

Back to Top