Skip to content

Project Scope – The Quest for Good Requirements

At the start of a project, together with business and other stakeholders, the project manager must identify the scope of the project. This contains the totality of the products to be delivered, and the services and activities to be performed. In order to be able to capture these, the requirements must be identified first.

Requirements? What is it all about?

A requirement is a need expressed by stakeholders, it’s a quality expectation and it could be a behaviour the required product must have. Otherwise said: it’s an aspect of a new or improved product or service which needs to be present in order to fulfil the customers’ expectations.

Where can I find these requirements?

We have to understand that there are different levels of requirements. At highest level there are the business requirements. These are the things that management, the project board, the project sponsor requires for the end product. And mostly these are described on high level. Refinement for these come from other people, with more knowledge on how the end product should look like, be like, behave etc. These people are called stakeholders and thus with them you’ll be capturing stakeholder requirements.

Further down the lane the next step is, starting from these business and stakeholder requirements, to identify the functionalities the product must possess and identify the technical requirements for it.

To give an example e.g. management of a company started a project to expand their product range with a new type of water pump specifically designed to operate in flooded areas. Next, stakeholders added their requirements such as: the pump must be lightweight and should fit in a 1m3 box. Nothing about the functions for it yet, so here it comes: the pump must be able to pump 1000 liters per hour. Technical requirements from these can now be derived: Since it has to work in flooded areas, it has to be robust. But on the other hand there was a requirement that it should be light weighted, so we have to carefully choose the material for the housing of the pump. Also, since it must be able to pump 1000 l/h, the motor has to be powerful, which will have to be taken into account when designing it.

Two types of requirements we haven’t mentioned yet, but these might also be worthwhile to be identified:

  1. Non-functional requirements: these do not add any functionality to the product, but might be necessary. In case of our example we could say that the 1m3 box is a non-functional requirement.
  2. Transitional requirements: what needs to be done to go from the current (old) situation to the new situation. In case of the pump, nothing much. But in case you’re doing a software project, it might be needed to transfer data from the old software package to the new one.

To answer the question where to get these requirements: We now are aware that most of them come from talking to people, by interviewing them, by working with them in a requirements work shop, by conducting surveys and so one. But not to forget that studying existing documentation might also provide input.

Quality: ‘Superb’, ‘Good’ or ‘Just barely good enough’?

Once we have gathered the requirements, the next question we should ask is: What quality should the product(s) comply to? Does it need to be ‘superb’, ‘good’ or ‘just barely good enough’?

And again it’s the business and other stakeholders that can provide their expectations about this. But also sometimes regulations, laws and so on, will request a certain level of quality (think e.g. about ISO).

A good way of dealing with this is adding acceptance criteria to each requirement. Knowing what makes the stakeholder accept the product you will deliver, helps in understanding the expected quality.

But even then we’re still not at the end of our quest. There are other factors that might influence the quality like e.g. the budget (is there sufficient money to guarantee the requested quality’?), time (do we have sufficient time to build and properly test it?). If this is the case, the stakeholders must be informed and decisions have to be made.

In our example of the pump, some acceptance criteria could be:

  1. Robustness of the pump must be proven (e.g. by testing it for a month when constantly pumping).
  2. Lightweight: it may not weigh more than 15 kg.

One attention point here: Voltaire once said: ‘Best is the enemy of good’. Although, these are words from the 18th century, if we relate them to the quality in projects, we must, even in the 21st century, bare them in mind. Many people tend to provide better or less quality as requested. In the case of better quality (also known as ‘gold plating’), the customer will be delighted, but will not pay more for it. In case of lesser quality, the customer will certainly be displeased and will request rework (without paying for it). So in both cases, it’ll be the supplier who’ll lose money.

Why should we pay attention in gathering the correct requirements?

Findings from studies shows that due to poor definition and management of requirements, 35% of the budget is wasted because rework needed to be done and that even 23% of the projects are either deferred or not implemented.

This is of course nothing new to all of us, but anyhow these are tremendous figures worth thinking about.

The lesson here is that if we, as project managers, want to deliver the requested product(s) with the requested quality and within budget and time, we need to keep our scope under control. In order to succeed in this, we must make sure that we are in control of the requirements.