• 21 Ways to Excel at Project Management

Getting Realistic User Requirements

Question 14: Are the user requirements realistic?

Good Practice: Obtaining a realistic requirement set is essential to your project's success and the well-being of the project team.

For many projects, the total set of user requirements can be ambitious, making it difficult or even impossible to deliver a solution that meets all the requirements, in a way, that is robust, cost-effective, maintainable and can be rolled out quickly to a large user base.

It is essential to match the user requirements specification against the available technology and solutions you can implement in a timely, robust and practical way. This situation can result in an agreement that some requirements, say 20%, will not be delivered. Such a compromise will ensure that the remaining 80% can be delivered quickly. This compromise is essential for global projects with a large user base. On such projects, the speed and ease of implementation is an important consideration for the overall solution.

To be successful at requirements gathering and to give your project an increased likelihood of success, follow these rules:

1. Don't assume you know what the customer wants. Ask!
2. Involve the users and practitioners from the start.
3. Define and agree on the scope of the project.
4. Ensure requirements are specific, realistic and measurable.
5. Get clarity if there is any doubt.
6. Create a clear, concise and thorough requirements document and share it with the customer.
7. Confirm your understanding of the requirements with the customer by playing back to them.
8. Avoid talking about technology or solutions until the requirements are fully understood.
9. Get the requirements agreed upon with the stakeholders before the project starts.
10. Create a prototype, if necessary, to confirm or refine the customers' requirements.
11. Use a recognised notation, such as the Unified Modelling Language (UML), for modelling the software.
12. Cross-check the software design against the requirements and review regularly.

Common Mistakes

• 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 into must have, should have, could have, and would have, commonly known as the MoSCoW principle.
• Not having enough consultation with actual users and practitioners.
• Solving the problem before you know what it is.
• Lacking a clear understanding and making assumptions instead of asking for clarification.