Stamping Out Requirements Dysfunction
I believe without any doubt that all project failures are related to miscommunication of requirements. If you consider project failure to be a result of not meeting time, cost or scope expectations, you might find the statement a little obvious. But that's not exactly what I mean. Time, cost and scope are tangible constraints which organizations usually define well and are relatively easy to measure. The requirements I am talking about are the ones that define the purpose, function and value--the “business requirements”--as the source of project failure because they are hard to define.
Why Defining Requirements is Hard
Shouldn't it be easy to just state something as basic as a need? You would think so, but human beings tend to think about things in tangible terms and within a context they know. As such, an individual will tend to define requirements as a “want” or “solution” that is limited to their singular knowledge set.
A mythical quote by Henry Ford says, "If I had asked people what they wanted, they would have said faster horses." This statement is mythical because there is a debate over whether or not Henry Ford ever really said the quote; regardless, I still think it is brilliant and really amplifies the point that customers tend to think of needs in terms of known solutions.
For example, when
Please log in or sign up below to read the rest of the article.