Andy Jordan is President of Roffensian Consulting S.A., a Roatan, Honduras-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 [email protected]. Andy's new book Risk Management for Project Driven Organizations is now available.
When I first started managing projects, I treated requirements as an input to the project--they would magically appear and tell me what the scope of my project was. It didn’t take me long to figure out that I was taking the wrong approach, that requirements gathering was actually an integral part in the execution of the project. But I am still surprised by how many organizations are unable to come up with good requirements.
In this article, I want to go back to requirements basics and examine how the requirements tie the organizational needs into the deliverables of the project--and how we then go on to validate those requirements.
From needs to deliverables--via requirements All projects begin with a need, or maybe more accurately a set of needs--things that the organization is looking to change. The reason may be competitive, operational, financial, regulatory or any number of things, but we always start with a basic need. From this need the organization--let’s call it the client or customer from this point--needs to create the objectives for the project.
Transferring the need to objectives is an important part of the project--a need can be explained and understood, but it’s not something that can tangibly be addressed. There may be a number of different ways to address the business need, and the objectives give us a better framework to address that need