Exploring trends and developments in project management today

Getting Realistic User Requirements

Question 14: Are the user requirements realistic?

Requirements Analyst sitting with a customer writing requirements

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 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 important to match the user requirements specification against the available technology and solutions that can be implemented in a timely, robust and practical way. This may result in an agreement that some of the requirements, say 20%, will not be delivered. Such a compromise will make sure the remaining 80% can be delivered quickly. 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:

  1. Don't assume you know what the customer wants, ask!
  2. Involve the users 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 them back.
  8. Avoid talking technology or solutions until the requirements are fully understood.
  9. Get the requirements agreed 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,' 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 instead of asking for clarification.