PMs know that requirements are flawed

The workshop next week, "Using Social Media To Make Smarter Product Decisions," was a good occasion for me to jump into the data we've been collecting about requirements in the technology industry. It's one thing to claim that there are problems that need fixing, and that social media can help fix them. It's another to put that claim to the test.

The requirements survey has produced a lot of interesting results that will see the light of day in a research document to be published later this quarter. The questions we asked build a composite picture of both the content of requirements and the process of creating them. For example, we asked, ""How much time do you dedicate to requirements work at each stage of the development cycle?" Doing a weighted average of the responses, here's the answer:

This picture should be familiar to any PM: lots of requirements work at the beginning of the project; less and less as the project proceeds. Which begs the question, how effectively can the organization make mid-course corrections? When does the "after action report" kind of analysis happen, when PMs look back on the work they just did to figure out what they could do better the next time?

While this spike of requirements attention at the beginning of a project makes sense in bureaucratic terms, it doesn't make sense in research terms. You might pretend that the requirements you build at the beginning of a project are everything that the development team needs to proceed, but at best, that's a comforting fiction. You always need to fill in gaps, provide more detailed explanations, and validate the results.

If requirements are the information that technology teams need to avoid making costly mistakes, then requirements gathering and analysis should be an ongoing activity. While that's certainly true in some PM teams that I've met during my time as a Forrester analyst, in the aggregate, these peaks and valleys of activity still define the requirements landscape for many PMs.

There are plenty of other signposts to deficiencies in product requirements. For example, there's a big mismatch between the skills needed to do requirements, and the opportunities to put these skills to work. While the rest of the story will come later, I thought this one result was interesting enough to now, instead of waiting for the final report.

[Cross-posted at The Forrester product management blog.]

Comments

[David W. Wright]

"You might pretend that the requirements you build at the beginning of a project are everything that the development team needs to proceed, but at best, that's a comforting fiction."

I don't have to pretend, I know. The issue isn't how much time you spend on requirements, it's how well you use the time. If your requirements gathering approach is basically asking the business what they want, you will fail. That is an open-ended question, one which you can never prove has been fully answered.

I don't ask business people what they want... I ask them what they do, what information do they need to do it, and how much of that needs to be different in the future. Those are questions that can be completely answered, and generate all the Functional Requirements your developers need.

Sorry, but doing crappy requirements work does not prove that good requirements work can't be done.