An agency for the website, an integrator for the link with the ERP, a hosting provider, a freelancer for the content: many digital projects rely on several suppliers at once. Each of them makes progress, and yet the project stalls. Coordinating suppliers rarely goes wrong in the middle of someone's work package. It goes wrong at the boundaries, where one supplier's output becomes another's input.
I work alone, and on an engagement I often find myself in the middle of several teams who have never met. What follows is how I go about it: one accountable person per deliverable, a single reference document, one shared rhythm, and an exit planned from the first day. None of it is complicated, but it has to be in place before the first problem falls between two chairs.
01Why problems fall between two suppliers
Each supplier has a contract, a scope and a contact. Within that scope, they usually do good work. The problem starts in what nobody bought: the boundary between two work packages.
Take a contact form that has stopped sending anything. The agency says the form works. The integrator says the connector receives what it is sent. The hosting provider says the server responds. All three are right about their own scope, and the form is still broken. Nobody is acting in bad faith: the boundary simply belongs to no one.
Two causes come up again and again. The first is a piece of data that changes meaning as it passes from one tool to another. On a project, I saw a mix of centimetres and millimetres between two tools distort an entire render. Each tool was correct in its own units. Since then, I ask for the reference data to be written down at every boundary: format, unit, who produces it, who consumes it.
The second cause is that everyone checks from where they stand. I have seen a site look fine to the logged-in team and be broken for visitors, because of caching. Each supplier tests what they can see. Someone has to test what the end user sees, from start to finish, and that someone has to be named.
02One accountable person per deliverable: the RACI matrix
The tool I use to name that someone is the RACI matrix. The French Ministry of the Economy gives a simple definition in its RACI method sheet (in French): a two-dimensional table, with activities or deliverables in rows and the people involved in columns. Each cell gets a letter:
- R for responsible: the person who does the work;
- A for accountable: the person who approves and answers for the result;
- C for consulted: the person whose opinion is sought beforehand;
- I for informed: the person kept up to date afterwards.
The rule that matters most is in the same sheet: an activity can only have one approver. They can hand the work to one or more people, but they remain responsible for it. And those consulted have no authority: the approver always decides.
Rainer Berak, from Project A, makes the same point in his video on the four rules of RACI. Every topic needs exactly one accountable person, not a team and not two people, otherwise each relies on the other. He adds something I think is right: the informed and the consulted cost more than they bring when you add too many. The Scrum Guide says it in its own way: the Product Owner is one person, not a committee.
Building the matrix for several suppliers
Here is how I go about it when several suppliers are involved:
- I list the deliverables, not each supplier's internal tasks. I do not need to know how the agency splits its work; I need to know who answers for the checkout page.
- I add a row for each boundary: "ERP order export to the website", "go-live", "end-to-end acceptance testing". These are the rows people forget.
- I put the suppliers in columns, plus the client and myself.
- I place the A for each row before anything else. If nobody wants it, that tells you something: no contract covers that row.
- I go through the table in a workshop with everyone. The Ministry's sheet allows 30 to 45 minutes for 4 to 30 participants, and that is the order of magnitude I keep in mind.
For the A on boundary rows, I start from the GOV.UK Service Manual: the service owner must have the decision-making authority to deliver on all aspects of a project, and final responsibility for quality lies with them. So a boundary between two suppliers belongs to the client, or to whoever the client appoints, not to one of the two suppliers. When the client gives me the delivery role, I take those rows.
03A reference document everyone reads
The matrix says who answers. It does not say for what. For that you need a document every supplier reads, and only one.
On an integration between an ERP and an e-commerce site, the specification changed at almost every meeting. I versioned it, one release after another, so that everyone was talking about the same document. Without a version number, two suppliers can work from two different states of the same text, each sure they are right. I have written in more detail about how I write an ERP and e-commerce integration specification.
That reference document contains at least:
- the deliverables and what "done" means for each;
- the data exchanged at each boundary, with its format and unit;
- the dependencies between suppliers, in order;
- a version history, with what changed and who decided it.
Dependencies deserve particular care, because a delay at one supplier is paid for by the next. I cover this in the article on web project planning built from dependencies.
04One shared rhythm instead of one-to-one meetings
The trap in managing several suppliers is the one-to-one meeting. The client sees the agency on Monday, the integrator on Wednesday, the hosting provider whenever there is an incident. Each leaves with their own version of the situation, and the client becomes the only person with the full picture, without the time to keep it up to date.
I prefer a single, short rhythm with every supplier involved in the boundaries of the moment. We look at the rows of the matrix that are moving, the week's dependencies and the open questions. A decision that affects two suppliers is made in front of both.
The GOV.UK Service Manual advises you to treat contractors and permanent staff as equal team members, with fewer communication overheads as a result. A supplier who hears the other's constraints can adjust their work before the problem lands on your desk.
One level up, I stick to a habit: a monthly report that goes out on its own and a committee that decides are worth more than a dashboard nobody reads. The committee settles what the weekly rhythm could not. I describe how I prepare one in the article on the project steering committee.
I picked up this habit long before digital work. When I started out in audiovisual production, the job was to hold a budget, a schedule and a team to a date that did not move. You learn quickly that a fixed date leaves no room for topics nobody owns.
05Planning each supplier's exit from the day they arrive
A supplier always leaves in the end: end of a work package, end of a contract, a change of vendor. If their exit has not been planned, part of the project leaves with them.
The GOV.UK Service Manual is clear on this. It says to work only with suppliers prepared to pass on what they know, to have a plan for transferring knowledge, especially when moving between phases or changing supplier, and to give only the access people need, removing it once it is no longer required.
In practice, as soon as a supplier arrives, I write down:
- the access they receive, who granted it and when to remove it;
- the documents they must keep up to date, and where they live (with the client, not with them);
- what they must hand over when they leave: code, configuration, accounts, documentation.
I hold myself to the same rule. My engagements are short and end with a documented handover. If I leave and the client cannot take back control, I have done a poor job. I go into this for IT services firms in the article on working with an IT services firm without losing control of your project.
What this method does not solve
A RACI matrix does not replace a contract. If a boundary is covered by no purchase order, the table will show it, but it will not pay for it. You will then need to add it to a supplier's contract, or take it on in-house.
Nor does it fix a supplier who does not deliver. It makes the problem visible sooner, which already counts for a lot. And on a very small project, with two people who talk every day, I do not bother with a matrix: a shared list of deliverables and who answers for each is enough.
06Where to start this week
If you have several suppliers on a project right now, this is what I would do first:
- List the boundaries: every place where one supplier's work becomes another's input.
- For each one, write down the name of the person who answers for it. If you cannot find one, you have found your next problem.
- Check that there is a single reference document, with a version number, that every supplier reads.
- Replace one one-to-one meeting with a joint session for the suppliers concerned.
- Test the journey end to end as a visitor would, before acceptance testing and go-live.
This is the kind of groundwork I do at the start of an engagement, before running the suppliers day to day. You can see the detail on the SLX Management services page, and a few projects in the portfolio. If your project is at that stage, we can talk about it.