|  | 

Project Management

How To Manage Scope Using The SMART Requirements Technique

Reading Time: 5 minutes


SMART requirements

Are you an engineering manager / project manager in a startup or product development company. Do you struggle with scope and requirements management? Do you end up taking up more scope than you should be ?

Bad Scope and product requirements management is one of the key reasons for project failures. Most project managers struggle to manage this aspect of the project. There are 5 key areas the manager must be good at to be successful in this phase

  1. Identify and document requirement stakeholders
  2. Clearly document project requirements using the SMART technique described below
  3. Ensure scope is agreed and signed off
  4. Validate the scope continuously
  5. Mange change through a well-defined process

S.M.A.R.T Method

The experts at Global Management Mentors have been using a proven method for documenting project technical requirements which are a sure shot way to ensure you have well documented and manageable requirements. By applying this method for every project requirement the manager will be able to manage the scope on a predictable schedule.

So what is the SMART method of documenting technical requirements. SMART stands for



By Dungdm93 – Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=54290689


SMART was traditionally used in goal setting. But requirements are no different, each requirement is an end goal that you want your project team to achieve. Like any goal, unless a requirement is defined using the SMART technique it will be left for interpretation and can lead to ambiguity in the implementation. Most project failures are due to incorrectly understood requirements or incomplete requirements that do not meet the end user goals.

As we all engineering and project managers know most requirements come as one liners to start with. It is the responsibility of the project manager to lead his team out to elaborate the requirement and document it well for implementation.

Now let us understand using a simple example on how we can turn a vaguely spelt out requirement into a SMART requirement that can help lead out to a good design and implementation.

Requirement : The user should be able to add a product to the shopping cart

The first step is to be Specific


The one liner is no way close to having any specifics. The first step is to start asking the right questions to the requirement stakeholders to elaborate the details.

  1. Identify all the user types who can add a product to the cart. This could be logged in users, not logged users, vendors, admins etc.
  2. Document the actions a user can take to add a product to a cart.
  3. Document the UX visualization of the page
  4. Identify any constraints like under what conditions a user cannot add a product to a cart etc..

Now the one line will be broken down to many line items. One of the requirement items would now be

A logged in user can select the product and click on “Add to cart”, The Cart will be displayed on the right side of the page as seen in the visualization. The product should be visible in the cart with the count incremented by one and the price shall be displayed.

The next step is to ensure this requirement is measurable which in software terms it is testable for the required conditions.


Now in the requirement one has to define the metrics of measurement. This would typically include any non-functional specifications for that particular requirement. Many projects tend to ignore this aspect of the requirement and realize the requirement did not meet the goal as it fell short of the end user needs. It is important to ask the right questions here with the stakeholders and document the measurable goals here. For example in the above requirement

  1. Identify the number of users that will use the shopping cart in a day.
  2. Identify peak and average load conditions
  3. Document the expectations on the response time
  4. Document the max and min number of products a user can add to the cart and any other constraints

So the requirement can now be written as

A maximum number of 200 users can access the shopping cart. A user can add not more the specified products as specified in the product detail. The product should be added to the cart in less than 100 m sec.

At Global Management Mentors we have seen a project where the UX specifications were not clearly defined and signed off at the start. At the project delivery phase the stakeholder kept adding and changing the requirements which lead to project delays.


This attribute reminds the engineering manager to make sure every requirement is realistic and achievable. Many users demand for requirements that are unrealistic. Working on unrealistic requirements will lead to increase in your project costs and the team will be battling technical problems which ultimately will lead to decreased team morale and increased project costs.

It is the responsibility of the manager to ask the right questions to make sure the requirement is what is really needed. The realism can be around the no of users, response times and UI expectations. Based on the real business need and project cost the manager must manage the expectations of the stakeholders.

For example in one of the projects the stakeholder was demanding for a huge user load with unrealistic response times. When the manager demanded business data showing the expected user base it turned out to be much smaller than the ask. The manager was able to set realistic expectations and tone down the scope to meet the customer needs.


This attribute goes hand in hand with being Achievable. The manager must make sure each requirement is relevant to the business need that is being solved. We have seen numerous business users who expand the requirements and add in many irrelevant requirements to the scope. If this aspect is not well managed there will be a huge scope creep that ultimately will not be useful to the end user. Every dollar spent must result in the benefit to the end user.

This attribute also reminds the project manager to ensure that the testers are a part of the team. They must document all the relevant test cases with the expected outcomes.

In a project lead by the experts in Global Management Mentors we had some operations end users asking for many reports that are not directly relevant to the project implementation. Developing those reports would lead to huge scope creep and increase in the project cost. It was managed right at the start and removed from the scope.

Time Based

Finally each requirement will be set on a time line in the project manager’s schedule plan. You could be using agile methods or any other method but each user story or requirement must be clearly defined with a start – end date and resources assigned. This is done as a part of the resource and schedule planning. Make sure every requirement from the SMART requirement specifications is translated into the schedule plan with tractability.


As you can see the engineering manager/project manager must be able to manage this phase on a continuous basis. After documenting the requirements using the SMART technique the manager must follow the steps described in the introduction to manage the outcomes . It is the responsibility of the manager to continuously set and manage stakeholder expectations and review the risks.



The authors are senior managers at startups and product development companies. They come with extensive experience in leadership and management of global engineering teams to deliver high quality software products. Each of them are extremely passionate about these topics . They mentor and train project managers on leadership and management.


Your email address will not be published. Required fields are marked *

Name *

Email *