One of the many articles here on management
Managing Supplier Agreements
Written by John Berry on 21st June 2021. Revised 22nd June 2021.
7 min read
There are two types of agreement that might be in place between a firm and its people: an employment contract for its employees, and a supplier contract for all others.
A supplier contract covers the relationship between the firm and the various consultants, associates, sub-contractors, freelancers and other individuals. It also covers contracts between personal service companies and umbrella companies or other intermediaries that might facilitate the provision of services.
Companies struggle to differentiate between the two agreement types. They often issue employment contracts when the person doing the supplying is not intended as an employee and is paid gross. And conversely, they often issue supplier contracts when the person doing the supplying is working a set number of hours for a set wage.
When a person is engaged via a supplier contract when they are really working set hours for an hourly rate, this is often referred to ‘bogus self-employment’. Tax authorities worldwide are on the lookout for such situations where relationships are wrongly expressed or muddied.
We’ve written many times about the difference between an employee and a supplier, and we won’t repeat this guidance here. This blog goes on to discuss how to make a supplier agreement work – assuming that this is what is or might be wanted.
First some concepts.
A supplier supplies goods or services. Those goods or services must be defined in a specification – otherwise how can anyone tell if the supplier obligations are discharged. Often the specification covers deliverables, called off by the firm over time. As an example, one case might be where the supplier develops and supplies a computer application to the firm. The application needs to be defined by its functional and non-functional requirements.
The transaction for supply goes like this.
The firm is interested in the application and sends the supplier a specification. The supplier provides a quotation for the application, maybe elaborating the specification and setting out timescales, price and terms and conditions of sale. If the firm likes the offer made in the quotation, it will place an order. The supplier will then muster its resources and supply the application against the quotation.
If all goes well, the application will meet the specification and the supplier can raise its invoice. The firm will then pay against that invoice.
This is the essence of all supplier contracts and resulting transaction – request for price, offer, order, supply, acceptance and invoice.
All supplier contracts transact like this – even those covering the provision of manpower services. And this is where things go awry.
In manpower or labour contracts, the supply is ongoing. Invoices need to be raised every month to aid the supplier’s cash flow.
The key concept of all supplier contracts with ongoing supply is the use of a purchase order (PO). The contract should be signed. The POs (raised monthly, or whatever) then trigger the next phases of the supply. A PO should define the deliverables for that phase and applicable parts of the specification. It doesn’t define hours worked. It defines a price for deliverables.
Of course, it may be that the quotation, and the price, will have been based on an hourly rate, but that rate is between supplier and firm. It must not appear on the PO – otherwise the contract just looks like one for employment by another name.
Many firms (and suppliers) are concerned that a price can’t be given. That’s never the case. A price can always be given – it’s just that it might not be able to be fixed from the outset. It’s quite common to build price variation into the contract. It may be that a fixed price is set for the first phase of a project (and associated deliverables), but the price for the next phase is variable. It may then be that once a variable element is delivered, subsequent phases can have their prices fixed.
The prices paid and the work delivered varies across the lifecycle of the relationship
The key point about managing suppliers is that work is broken into phasees or work packages, each with deliverables. Quotes are given, and prices are set. Deliveries are made and invoices raised.
We should at this point discuss a key difficulty expressed by many managers. Many moan that running supplier contracts takes time and energy. Hiring an employee is, on the face of it, easier. They get hired and set to task on a job and never talked to again about what they do. That is, of course, absurd. Managers should manage their employees – breaking down jobs, identifying individual work packages and setting objectives. Managers should spend something like half their time working with direct reports – so spending something like two hours per week with each employee or manager.
So, managing employees takes time too. Arguably, it’s easier to manage suppliers since there’s no pastoral, developmental or disciplinary time needed. Suppliers are more like machines – they deliver to a specification and a delivery schedule.
So how does the PO system work?
Let’s take the role of a software developer who will supply modules or libraries for delivery to and consumption by an internal development team. The team is developing a complex solution comprising many libraries.
In month one, the supplier developer might be asked to participate in a series of meetings with employees on the team. That will demand a variable price since the number of meetings and their duration are not set. Along with that, the supplier might be asked to scope the library that they are to develop. They’re experienced, so that should be a fixed price. If they’ve scoped work before, they’ll be able to judge. In subsequent months, and once the specification becomes clear, the price should be firm.
Some proponents of the agile software development approach would argue that the PO system can’t be used. Under agile, developers burn funds and effort under the client’s direction, so no specification is ever needed, and effort is always variable. If this is really the case, it may be that suppliers can’t participate. But more informed software managers would say that even in such a flexible regime, POs with fixed prices can still be used – and indeed that they would be a good way to avoid chaos.
So even under software development, the PO system can be applied – with the caveat that prices may need to be varied under project manager control.
That then comes to the final point about how to manage a supplier contract.
All supplier contracts need project managers (PMs). Someone within the firm needs to raise the POs from knowledge of what the internal teams need delivery of.
The PM raises the POs in which the deliverables are set out. The PM then monitors supplier performance, confirms that the specification and deliverables are complied with, and pays the invoices. The whole system is therefore under the PMs’ control. The PM is simply the manager responsible for the success of the venture – or one of their team. Whether or not a firm likes the idea, a Project Manager is always there, even if not formally appointed. Someone must actively manage all supplier agreements.
So, to conclude.
A supplier is a special type of person who works to deliver goods or services to the firm. They are under a supplier contract.
That’s not a contract for hours to be worked at an hourly rate, subordinate to the firm.
It’s not a contract where the firm, and specifically a contracting manager, carries responsibility for the supplier’s contribution.
It’s a contract under which the supplier takes responsibility for their performance.
Performance is defined by specification, time and deliverables and those are set out in the contract and in purchase orders that trigger supplier action.
Often managers object to this formalised way of proceeding, saying that things can’t be fixed. In those cases, perhaps the person doing the work must be an employee. Perhaps the supplier route is wrong. But we assert that there are few cases where the work can’t be packaged and where the PO system can’t work.
It’s just a question of what’s appropriate; with a little thought about how it’s all to be managed.