Better descriptions of requirements in tenders create far more successful public sector projects

Read the article in Danish here.

There are many perspectives to consider when describing the requirements for a solution. How detailed should the requirements be? How should they be designed? Who can provide them? How do they take account of the rapid development of society?

In our work to formulate requirements for the procurement of large IT projects in public organisations, we have gradually found a route through the jungle that is worth sharing. As you will see, it is particularly important to prioritise the clarification work before the actual work of writing the requirements specification and preparation of tender documents. In practice, we often find that the clarification work takes place in parallel and, due to time pressures, even at the same time as the requirements work, which can make the work more difficult and create backlogs.

Here are our recommendations on what to do when writing a requirements specification.

Understand the relationship between the project's business goals and needs

Start by establishing an overview that describes the connection between the overall business goals, which are often also found in the project's business case, and the business needs. Business needs make up the overall characteristics of the solution and constitute the highest level of requirements. Underlying requirements can subsequently be related to one or more business needs and through them to the goals. You can use the overview as the structural backdrop that can first guide the requirements work and then the subsequent contract management.

Understand the market

Based on the business needs, you should conduct a market dialogue on the specific project and the market's ability to meet its needs. For example, it is possible to examine to what extent standard systems can be expected to meet the needs and whether the scope of the tender needs to be adjusted.

Understand the nature of procurement

It is particularly important to understand the relationship between standard and customised solutions. A high degree of standardisation is often the intention, but frequently up to half of the system's functionality ends up being customised. This can be an important reason why projects go off track. The dilemma lies in assessing the ability of the standardised system to meet overall functional requirements versus its ability to meet the detailed requirements, and whether the detailed requirements are critical to achieving business goals.

Understand your offering

The tender form also plays an important role in how requirements are written. Here, it is vital to understand whether you can negotiate adjustments to the requirements during the tender process. If this is not possible, as is often the case with mini tenders under a framework agreement, there is a greater requirement for market knowledge and detailed requirements. In addition, it is crucial to know whether the project should be delivered using an agile methodology, which can generally reduce the need for detailed requirements.

Establish a framework for the requirements work

Collecting and drafting requirements often requires the involvement of many people and stakeholders. This means that requirements often risk being designed in different ways, and that there is an overlap between requirements, which may lead to misinterpretation by the supplier, which may mean that you as a customer do not get the solution that you requested.

It is therefore important that frameworks, in terms of requirements structure, level of detail and requirement format, are agreed early in the process. In particular, the level of detail is difficult to define and should be agreed during the clarification phase. Examples of requirements should be developed jointly so that the level of detail, syntax and format are calibrated.

Is the devil in the detail?

It is usually an advantage to write functional requirements as generally as possible to ensure that tenderers have the greatest possible scope to use standard solutions or innovation in their responses. It doesn't make sense to try to force suppliers into a very specific solution if there's no need for it. More general functional requirements will often lead to a greater need for non-functional requirements that define the rules of the game for the functional requirements, e.g. that different regulatory requirements are complied with. Similarly, overall functional requirements will require good evaluation criteria that describe what will carry the most weight. An overarching requirement can often be met in more or less elegant ways than a detailed one. Here, the evaluation criteria should describe what the customer values most.

Describe what the user should be able to do

User stories are a great way to describe functionality requirements from a user perspective. User stories describe what the user wants to do, what the user wants to achieve, and the success criteria that must be met for the user to have achieved what they want. User stories put the user at the centre, which is an advantage, and by their nature they are easier to keep at an overall functional level than specific requirements. Finally, user stories are easy to communicate and suitable for involving the organisation in the requirements work.

How to ensure good requirements

The content of the requirements is one thing, but the way in which they are to be drafted in linguistic terms is quite another.

Here, too, our experience is that there are real advantages in tightening up projects considerably. Any tender document must be written in clear, concise, and unambiguous language. It should be exhaustively described, complete and with precise information. In addition, it is important that it contains only necessary requirements, that is the "need to have" and not a lot of "nice to have". And finally, it is the alpha and omega of the process that every requirement is verifiable, consistent, traceable, and realistic.

If you put the hard work in during the actual design of the requirements, then we can guarantee a much better starting point and much greater success in the actual procurement process.