Beyond SMART Requirements

Making sure business requirements are suitable is a valuable practice. Using SMART requirements (Specific, Measurable, Achievable, Relevant, and Time-bound) is a great start, but it isn’t always enough. Here are other requirement characteristics that help keep projects out of trouble.

• Will the requirement cause conflict? Requirements can benefit one part of the business and cause difficulties for another. For example, creating a streamlined approach for selling a product might help sales while creating problems for the finance department in collecting client payments. Identify potential conflicts and try to adjust requirements to benefit all business areas.
• Prioritize the requirements. Prioritizing requirements accomplishes two important things. First, in the event of budget cuts, you can remove requirements that have the least impact on the delivered solution. This strategic approach to prioritization simplifies scope management. Second, the discussions around prioritizing requirements are an educational process for the project team. The more the team understands stakeholders’ needs and business rationale, the more effective the project deliverables can be.
• Are stated requirements “the tip of the iceberg.” Stakeholders sometimes think about their immediate needs and overlook the big picture. For example, a sales team presents a requirement to enable customers to select product color on the company website rather than talking to a sales agent. This could trigger an avalanche of requests for choosing different product options via the web. In this situation, the project team might proactively ask whether product options beyond color are desirable. That way, the development team could design and build a more comprehensive set of product options, which might be cheaper and more efficient in the long run.
• Does this requirement impact regulatory processes? Businesses consider process or tool enhancements to increase productivity. What if enhancements affect outcomes that are needed by regulatory requirements. The process to create a regulated outcome might also be regulated. Make sure requirements don’t violate regulatory standards for processes and outcomes.
• Are test cases available and feasible to create? Complex projects can involve multi-faceted requirements. Test cases assess a solution help determine whether the project solution satisfies a requirement. There’s a risk when test cases can’t be derived or are extremely expensive. The next logical step is to assess that risk to determine if you should accept the requirement. Commercial Off the Shelf Software (COTS) provides an example. Some COTS components are not validated via test cases because non-functional requirements, like usability or real-world performance, might not be adequately testable during development (due to lack of access to client production environments and so on).

Add these characteristics to your requirements checklist. If you have other items on your checklist, share them with us in the comments section.

For more about requirements, check out Angela Wick’s Requirements Elicitation and Analysis course.

Coming Up

I am busy updating two of my courses. Later in the year, you’ll be seeing new and improved versions of Learning Microsoft Project and Project Management Foundations: Choosing the Right Online Tool. The latter course will review more tools than the original using a different format.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 72,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________