Tenders: Pros and Cons, Dos and Don'ts - Requirements gathering

It's a fact isn't it that the cheapest car is the most popular and common? It's also a fact that the most popular TV or dishwasher or birthday card is the cheapest isn't it?

Of course, we know that this isn't true at all and that these purchases are based on value and not cost.

Here in lies a common problem with procurement and in particular tendering, which should and can be a positive driver for cost reductions. Should cost be a factor? Absolutely! Should cost be the biggest driver? Arguably not! We've all heard the phrase, "Buy cheap, buy twice". However, there is an exception to every rule and often the most expensive option isn't the best one either.

So taking all that into consideration how do you construct your procurement process so you get the best value, and what does value even mean?

I'm going to explain this in the context of one of our latest efficiency initiatives here at Every: expenses!

By this I mean streamlining the recording of, reporting on and paying expense claims.

In almost every organisation expenses will be incurred and need to be repaid and so a process is developed along with an Excel spreadsheet or similar. However, it isn't the most efficient of processes and the bigger the organisation grows, the more the cracks start to appear in this process. So it'll get to a point where the cracks can no longer be covered and they need to be properly addressed.

A common mistake is to start with a set of requirements based on what you do and want rather than what problems you're trying to solve. Ask yourself why you're even thinking about the requirements in the first place. Usually it's because something is causing a problem.

In the case of expenses there are problems in quite a few areas from the initial recording through to the reconciliation with the accounting system. For example, people lose receipts, or the receipts bleach in the sun and can't be read. In context of submissions, people sometimes claim for things that aren't covered by the policy and so a conversation ensues that delays the process. Sometimes expense claims have to be checked by more than one person and so the person who's submitted them has no clue as to where they are in the process and when they can expect payment so they're chasing someone for an update. The picture that's being drawn is a very creaky process slowing everything down and causing problems.

Now, if I was to start with the traditional tendering method, I'd build a set of requirements based on what I do now and ask that expense systems provide features that support that. This is called an "Input" or "Closed" specification and it's telling the suppliers what I want the system to offer. The basis for this could be that everyone is quoting on the same thing and is therefore the fairest method. However, that's missing a significant opportunity to think a bit outside the box and have a different way of doing things (there's a later article about supplier input you may want to look out for).

A far better way is the "Output" specification approach. I'm sure you'll recall conversations about "Closed" versus "Open" questions, e.g. "Did you enjoy the sunny weather this weekend?" versus "What did you do to take advantage of the sunny wether this weekend?" This approach works very well in developing procurement requirements. Here's an example:

Closed/Input: " Your system must be able to handle receipts in a variety of formats. Please confirm?"

Open/Output: "We want to replace the reliance on requiring and processing paper receipts. How does your system help us achieve this?"

Which of these questions offers the greater opportunity to let the system suppliers express themselves and demonstrate innovation bringing potentially new ways of doing things?

In the context of the Every software for Compliance, Policies, Assets, etc., this is how it could work?

Closed/Input: "Your system must allow for teachers to log help desk calls. Please confirm?"

Open/Output: "We want to replace the interruptions in the corridor of site staff (and the notebook in the staffroom) with a more simple and efficient method of recording help desk calls from teaching staff as well as improve communication on the progress of their calls. How does your system help us achieve this?"

This is how you help system providers properly understand your problems and how they may be able to demonstrate how they'd support your improvements. It also provides a wonderful insight into how system providers really apply their products to the real problems.

Procurement and tendering can be a minefield and this is just one aspect of the process. Look out for further articles on procurement that will focus on how you enlist help from suppliers without unduly influencing or compromising the requirements process and how you can get the best out of their presentations beyond the standard 60-75 minute supplier presentation that really helps no-one.

You May Also Like to Read