Linda Scott | 18 Nov 2021 | 5 min read

How Much Detail Should I Put in Procurement Specifications?

Now reading How Much Detail Should I Put in Procurement Specifications?

It can be tricky to know how much detail to put into your procurement specifications. Do you just put some high-level requirements in, or dictate everything down to the smallest detail?

In this blog article, we look at how this decision can impact the responses you get, and how you can determine the level of detail you need to provide.

The Three Types of Specifications

Can you imagine issuing an RFP without a specification? Your suppliers would be left scratching their heads trying to figure out what you want, and when you evaluated the responses, you’d have no clue as to whether those offers would include what you’re after. And as soon as the successful supplier started, they’d immediately request a variation.

To avoid this outcome, giving specifications is a given. But the level of detail you give can drastically change the response you get - or even ensure you don’t get any at all.

There are really three approaches when it comes to giving specifications: Functional Specification, Performance Specification, and Technical Specification.

Below, we’ll cover the pros and cons of all three approaches. For all three, we’ll use the example of requesting a security surveillance solution for a building.

Functional Specification

We need a security surveillance solution appropriate for the building.

Pretty straightforward, right? This defines the need at a high level and allows the supplier to propose an appropriate solution.

This is a good idea if you’re not an expert or are short on time, both situations where you can’t offer a lot of details.

This sort of specification maximises competition. How? Each specification is capable of being fulfilled by a variety of solutions, meaning multiple suppliers can put their hat in the ring.

There’s another notable benefit to this sort of specification. If the solution doesn’t work, liability is with the supplier. This is because the design of the solution relied entirely on the supplier’s expertise. However, it’s better to have a working solution than sue the supplier.

So what are the downsides of this approach? Well, the most obvious is that you’re likely going to have to evaluate a range of very different solutions. If you’re not an expert - which is one of the reasons someone might do a functional specification - how are you going to evaluate whether or not the proposed solution is workable?

The other downside is that suppliers are going to feel compelled to ask you a lot of questions about your policies, needs and budget in order to put in a conforming proposal. You may need to arrange a site visit, a briefing session, or both.

That means all that time you saved by being brief in your specifications may be offset by ensuring the suppliers know enough to respond to it.

Performance Specification

We need a security surveillance solution that:
1. covers 100% of the exterior and the interior with no "blind spots"
2. has a resolution of at least 8 Megapixels
3. complies with AS/NZS IEC 60839.11. 1:2019
4. allows recorded video to be archived and stored digitally
5. allows onsite or offsite monitoring
6. costs between $2m and $3m for a turnkey installation.

A performance specification is still output-focused like a functional specification but includes some performance information, hence the name.

This approach defines the need at a high level and offers more details to assist the supplier with proposing an appropriate solution.

This is a good way to go if you want to stimulate innovation and you have enough market understanding to define some basic standards without reducing competition inappropriately

Like with the functional specification, you also need to have enough in-house capability to evaluate the supplier's claims about their solution.

There are some downsides to a performance specification. Imagine if the eight-megapixel standard is not high enough, and is inappropriate for your purposes. This means liability for the poor solution rests with you.

So how do you avoid this? You need to know enough about your needs to define them correctly so that you don’t accidentally end up excluding “next generation” solutions.

You don’t have this knowledge in-house, you’ll need to engage a subject matter expert to help you develop the specification.

Technical specification

We need a security surveillance solution provider to supply, install and commission a security surveillance solution that must meet the following standards:
1. Centrally managed, distributed sites and multi-server solution
2. External weatherproof Video cameras (45)
3. Internal Video camera (155)
4. No less than 50 cameras per recording server
5. No less than 2 recording servers per system
6. Minimum numbers of concurrent users to be >25
7. Silent alarm manager
8. Dual authorisation (Video Client users)
9. Secure HTTPS camera connectivity (on supported devices)
10. 3rd party application integration and support for video analytics
11. Built-in Video Motion Detection (VMD) with Auto adjustable VMD sensitivity
12. H.264, MJPEG, MPEG-4, MPEG-4 ASP & MxPEG Codec
13. Etc

A technical specification is also known as a detailed specification, because it defines the need in a highly detailed way. It is prescriptive and unambiguous.

Unlike the previous two examples that focused on what the solution needs to do, this type of specification talks exactly about what it should be.

This approach is good if you’ve got the capability in-house to define your needs appropriately. If you do not have the expertise, then you will have to buy the services of a subject matter expert. This will take time and money, though the evaluation process may be shortened as a result.

The cost of doing this may be offset on higher-value projects if the specification helps create competition that releases more value. That is why technical specifications are often used in mature markets, where many suppliers can meet the standard and the project value makes it worthwhile to develop a detailed specification.

There are some downsides to a detailed specification. If the solution doesn't work just like with a performance specification, all liability is with you.

Another potential pitfall is you may inadvertently reduce competition by excluding alternate solutions. What if the inclusion of a defined standard (like “Active Directory support”) locks you into an obsolete technology?

How Do I Decide What Specification to Use?

Although the three examples are presented as if they are mutually exclusive, in practice many specifications have features of all three. The reality is that some specifications are what is referred to as “copypasta”.

Copypasta means that the specification has been assembled by copying and pasting content from different sources. The result may be inconsistent choices and language.

In contrast, best practice is to adopt a relatively consistent approach and stick to it. The specification should be the result of conscious choices.

The Rule of Thumb:

A technical specification is most appropriate in situations where we have the capacity, time, want to control the work or goods, and there are multiple capable suppliers available.
A performance specification is the most appropriate if we can define the outputs and we want to stimulate innovation.
A functional specification is the most appropriate when we can define the outcomes that we need, and we have the time and expertise to evaluate offers.