Exploring trends and developments
in project management today.
Requirements Gathering 101
Requirements gathering is an essential part of any project and project management. Understanding fully what a project will deliver is critical to its success. This may sound like common sense, but surprisingly it's an area that is often given far too little attention.
Many projects start with the barest headline list of requirements, only to find later the customers' needs have not been properly understood.
One-way to avoid this problem is by producing a statement of requirements. This document is a guide to the main requirements of the project. It provides:
- A succinct requirement specification for management purposes.
- A statement of key objectives - a "cardinal points" specification.
- A description of the environment in which the system will work.
- Background information and references to other relevant material.
- Information on major design constraints.
The contents of the statement of requirements should be stable or change relatively slowly.
Once you have created your statement of requirements, ensure the customer and all other stakeholders sign-up to it and understand that this and only this will be delivered.
Finally, ensure you have cross-referenced the requirements in the statement of requirements with those in the project definition report to ensure there is no mismatch.
10 Rules for Successful Requirements Gathering
To be successful at requirements gathering and to give your project an increased likelihood of success follow these rules:
- Don't assume you know what the customer wants, ask.
- Involve the users from the start.
- Define and agree the scope of the project.
- Ensure requirements are specific, realistic and measurable.
- Gain clarity if there is any doubt.
- Create a clear, concise and thorough requirements document and share it with the customer.
- Confirm your understanding of the requirements with the customer (play them back).
- Avoid talking technology or solutions until the requirements are fully understood.
- Get the requirements agreed with the stakeholders before the project starts.
- Create a prototype if necessary to confirm or refine the customers' requirements.
Common Mistakes
- Basing a solution on complex or cutting edge technology and then discovering that it cannot easily be rolled out to the 'real world'.
- Not prioritising the User Requirements, for example 'must have', 'should have', 'could have' and 'would have,' known as the MoSCoW principle.
- Not enough consultation with real users and practitioners.
- Solving the 'problem' before you know what it is.
- Lacking a clear understanding and making assumptions rather than asking.
Requirements gathering is about creating a clear, concise and agreed set of customer requirements that allow you to provide exactly what they are looking for.
Related Articles
Reduce Project Risk in the Requirements Process
Gathering and managing requirements are important challenges in project management. Projects succeed or fail due to poor requirements at any time throughout the project life cycle. The continuously evolving baseline of requirements needs to be managed effectively. The project manager needs to assess and understand the uniqueness of the requirements gathering process for his/her individual project.
Writing the Project Statement of Work
The Statement of Work, or SOW, is the bible for the work the project must produce. The SOW is a key governance tool whether it is being used to direct work for a vendor or contractor, or used to direct the work internally, the SOW must contain a description of all the work that is expected, so how do you go about writing one for your project?
Reduce Project Risk in the Requirements Process
Gathering and managing requirements are important challenges in project management. Projects succeed or fail due to poor requirements at any time throughout the project life cycle. The continuously evolving baseline of requirements needs to be managed effectively. The project manager needs to assess and understand the uniqueness of the requirements gathering process for his/her individual project.
The Elements of a Good Feasibility Study
In its simplest form, a Feasibility Study represents a definition of a problem or opportunity to be studied, an analysis of the current mode of operation, a definition of requirements, an evaluation of alternatives, and an agreed upon course of action. As such, the activities for preparing a Feasibility Study are generic in nature and can be applied to any type of project, be it for systems and software development, making an acquisition, or any other project.
21 Ways to Excel at Project Management
The popular project management eBook now fully updated and available as a website for the first time.
Happy to help, but it may be better if we continue this conversation on the forums, where others may join in.
Why not post you question on the General Project Management forum and we'll continue there.
Duncan
Another problem with me Duncan... my boss has given me assignment to create a scenario takin any software for e.g. address book software, organiser software, bookin online air tickets... he dint even gave me any idea how create a scenario.... i m finding study materials for tis... hope il get good study materials.... is it possible for u to help me in tis matter....
Thanks,
Sufi
thanks a lot for ur support...........
Everyone has to start somewhere. Is there somebody that could help you. Could you work together gathering requirements?
If you can, talk to your boss and tell him/her how you feel. Tell him you value this opportunity and want to do well, but need some help.
One thing to bear in mind when gathering requirements for IT systems is that you don't need technical knowledge. You are recording what the IT system should do, not designing a technical solution.
Ask questions, how, why, where, when - and always play back your understanding of what the customer has told you - did you understand it properly?
I hope this is of some help.
Good luck.
Duncan
I have given an opportunity to work in requirement gathering team... I dnt have any experiencein neither I am an IT gradute even I hvnt done ant software or hardware course... I dnt have any knowlegde abt computers rather thn surfing and using social networking sites... It's 2 months now & I am not capable of doin this in good way as per ma boss expectations N am feeling not good abt this... he only appreciate me in the collection of data... wud you please suggest me what sud I do..... :(
- Requirements Gathering
- Requirements Elicitation
- Requirements Management Plan
- Requirements Analysis
- Requirements Traceability
- Change Control
Within the PRINCE2 framework, your requirements approach and requirements will be defined during the initiation phase with the following pm artefacts feeding into it:
- Project Approach
- Business Case
- Communications Plan
The requirements feed into the following pm artefacts used during the execution phase:
- Work Packages
- Configuration Items
- Product Description
- Product Flow Diagram
The requirements analysis might be carried out by the Project Manager or for larger projects a Business Analyst.
Stakeholders needs to be taken thru set of requirements starting from the product capabilities, quality and the ability to be embedded into the existing enterprise infrastructure. As for baselining of the gathered requirements, well, the only high level requirements are stable, more granular requirements will become stable after having the product design completed. Here it is possible to get the full support of stakeholders and their sign off.
And a question to Duncan: how does the statement align with the PR2 context?