Stamping Out Requirements Dysfunction

Michelle Stronach has over 20 years of experience in the project management field, with experience creating successful PMOs and implementing project, portfolio management and IT governance frameworks. Michelle truly appreciates the value of feedback and welcomes comments on her articles.

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.


Continue reading...

Log In
Sign Up

"I'm sick and tired of hearing things from uptight, short-sighted, narrow-minded hypocrites. All I want is the truth. Just gimme some truth."

- John Lennon