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.
4 Comments
Gotta do it:
He knows changes aren't permanent,
But change is.
--Rush
What you describe here is at the heart of the "Evolutionary MDM" platform called Semarchy Convergence.
Did I brainwash you remotely? :-)
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.
So true, especially when it comes to analytical requirements. So often the real requirements don't show themselves until stakeholders get their first glimpse of the data. Then the picture comes into focus. This was a similar theme to my "Recalculation" blog from last month http://blog.kalido.com/2013-year-of-intelligent-business/