Question 14: Are the user requirements realistic?
21 Ways to Excel at Project Management
Good Practice: For many projects the total set of user requirements can be ambitious, making it difficult or even impossible to deliver a solution, which meets all the requirements in a manner that is robust, cost-effective and maintainable that can be rolled out quickly to a large user base.
It is important to match the user requirements specification against the available technology and solutions that can be implemented in a timely, robust and practical manner. This may result in an agreement that some of the requirements, say 20% will not be delivered. Such a compromise will ensure the remaining 80% can be delivered quickly. This is commonly known as the 80/20 rule or Pareto Principle. This compromise is important for global projects with a large user base. On such projects the speed and ease of implementation is an important consideration in the overall solution.
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.
- Get 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 by playing 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.
- Use a recognised notation, such as UML, for modelling the software.
- Cross-check the software design against the requirements and review regularly.
- Basing a solution on complex or new 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.