Strategic Requirements Management

Andy Jordan is President of Roffensian Consulting Inc., an Ontario, Canada-based management consulting firm with a comprehensive project management practice. Andy always appreciates feedback and discussion on the issues raised in his articles and can be reached at andy.jordan@roffensian.com. Andy's new book Risk Management for Project Driven Organizations is now available.

SHARE
Request to reuse this
Add to my favorites
Practice Areas: Business Analysis/Requirements Management, IT Strategy, Portfolio Management, Scope Management

In theory, requirements are a fairly straightforward part of a project. Even if the specific requirements themselves are complex, the process shouldn’t be that difficult--we define requirements to fulfill the scope of the project and then design and build a solution that satisfies those requirements. We then validate the requirements by confirming that every requirement has supporting functionality and that every deliverable supports a requirement. There may be times when the scope has to get squeezed in order to protect other, higher priority constraints, but there shouldn’t be much more to it than that.

However, I believe that we are frequently making mistakes in defining and managing our requirements--and if we get requirements wrong then we have little chance of delivering an effective solution. In this article, I want to explain why I think that things are wrong and offer some ideas on how to improve them. I’m going to assume the development on a new technology product, but the concepts will apply equally well to any kind of new development initiative.

Objectives to scope to requirements
Organizations are becoming increasingly strategic in the way that projects are reviewed and approved--focusing on what the outputs of a project will deliver in terms of organizational benefits rather than simply focusing on the features and functions that …

Please log in or sign up below to read the rest of the article.