How do you manage (collect, document, manage changes trace) requirements on your projects?
Mike FrenetteManager, IT PMO| Halifax Water (retired)Halifax, Nova Scotia, Canada
Many studies have shown that poor definition of requirements is a major cause of project failure. I think we can expand this to poor management of requirements being a major cause too, since defining them is only the first step. Once documented, you must manage changes to them and ensure they are all implemented, assuming that is within the defined scope and budget of the project. And, of course, you need to know how to solicit requirements from your client. Ask the right questions, and you will be successful. Ask the wrong questions, or miss some questions, and maybe not so much.
On your projects, how do you derive, document and manage requirements? What big successes have you experienced in this area? What are the pitfalls to look out for? Saving Changes...
Sort By:
Anonymous
I usually have several sessions with the customer and leads at the table to take the customer's needs and wants and transform those into goals and then identify the technical solution that support the functions to achieve that goal. (Lots more steps than just that one sentence.)
But, how do you define the requirements if you have folks on your team who've never defined requirements before and your customer has lofty goals e.g. "make it user friendly".
Once the requirements are defined, I'll manage them in a requirements matrix tracking development, testing, etc. Saving Changes...
Anonymous
You mention that you have to "ask the right questions" which I agree completely but what are the right questions to ask? Is there a specific set of framework questions that you use when soliciting requirements? Undertanding that every situation is different but what would you consider you core questions. Saving Changes...
I have found that often customer/users are thinking in terms of solutions rather than outcomes, so the requirements come out as how they want to accomplish something rather than the business outcome they are hoping to achieve.
By asking the outcome based questions and not the solution based questions you get far better results and don't narrow down the possible solutions available.
Once defined the requirements need to be documented (http://www.volere.co.uk/) have a very good method for documenting requirements that I have used in the past.
Then apply change control and ensure that they are in scope and tested in the final product.
Regards Julie Saving Changes...
