Working with an IT services firm, from the client side, usually starts well: a capable team arrives quickly and the project gets going. The trouble comes later, when you realise nobody in-house knows any more why a rule was coded the way it was, that three versions of the specification are in circulation, or that the end of the contract means the end of anyone understanding the system.
I have been running tech projects for around twenty years, on both the business side and the delivery side, and I often find myself between a client and its technical suppliers. I do not do long staff-augmentation contracts, managed services or ERP overhauls myself: these are areas where an IT services firm belongs. Here is what I put in place so the client stays in control, and where that approach runs out.
01What an IT services firm sells: time or an outcome
The first question is not "which firm?" but "what am I buying?". There are two main models, and they place the risk in different places.
With time and materials, you buy skilled time. Consultants work on your project and are billed for the time they spend. If the result is late, you still pay. It is flexible when the need keeps moving, but you carry the risk, so you have to do the steering.
With a fixed fee, the firm commits to a deliverable, a deadline and an amount. Mike Clayton, who trains project managers, sums it up in his video on fixed fee contracts: it is all about risk. The supplier carries the overruns, the client gains financial certainty but pays a premium for that risk. He also warns against the client who wants an amount that is both fixed and low.
My rule is simple: fixed fee only if I can write down the requirement and the acceptance criteria before work starts. Otherwise, time and materials with tight steering, or a series of small fixed-fee phases.
02What you never delegate
An IT services firm can build anything. It cannot decide for you what has value. The Scrum Guide says it about the Product Owner: they may delegate the work but remain accountable, and they are one person, not a committee. I hold on to that idea even outside Scrum. Someone on the client side settles the priorities, and the whole organisation respects their calls.
The UK government's Service Standard points the same way: the people who make decisions should be part of the team and accountable to it, and work with outside suppliers should be on a sustainable basis.
In practice, I never delegate three things: the order of priorities, the reference data (which tool is the source of truth for a product record, a stock level, a customer) and sign-off at acceptance testing. The day the firm alone decides what counts as "done", you are no longer steering anything.
03What to set up before day one
This is the least visible part and the one that saves the most trouble. I treat it as a checklist, ticked off before the first consultant touches the code.
The contract and the data
If the firm handles personal data (customers, staff, users), it is a processor under the GDPR. The French data protection authority, the CNIL, is clear: do not start a subcontracted service without a contract covering Article 28 of the GDPR (page in French). That contract sets out who is responsible for what, how data is returned and destroyed at the end, and how incidents are reported. The CNIL also asks you to look at the whole chain: your processor's own subcontractors count too.
Access
The same UK manual says to give suppliers only the access they need, and to plan how it will be removed. I add a list kept up to date: who has access to what, since when, with which account. Shared "supplier team" accounts are out, because nobody can tell who did what.
The reference document
A specification that everyone reads, versioned and dated. On an integration between an ERP and an online shop, the specification changed at almost every meeting. I kept it moving version by version, so that everyone was talking about the same document. That became a method for writing an integration specification. With an IT services firm it matters even more: the signed version is the one that gets invoiced.
The acceptance criteria
Written before development, not after delivery. I work from my acceptance testing and go-live checklist. One point I always keep in it: a site can look fine to the logged-in team and be broken for visitors, because of caching. So acceptance testing is also done as a visitor, logged out.
04Steering an IT services firm day to day without becoming the team lead
Steering a firm does not mean managing its consultants as if they were your staff. There is a practical reason and a legal one.
The practical reason: if you hand out tasks one by one, you are redoing the firm's job, taking on its risk, and paying for management twice.
The legal reason, at least in France: the Ministry of Labour points out that the labour code prohibits, with some exceptions, any profit-making operation whose sole purpose is supplying labour (page in French), and that the user of that labour can be penalised, not only the supplier. I am not a lawyer, and where the line sits is a conversation for yours. But I keep one rule of conduct: you state a need and you accept a result; how the consultants organise their work stays with the firm.
What works, in my experience, is a fixed rhythm rather than constant presence:
- a short weekly check-in with the firm's lead, on what is done, what is blocked and what is waiting for a decision;
- a monthly report that goes out on its own, always in the same format, with progress, time used and risks;
- a steering committee that actually decides, once a month, with the person who settles priorities.
A monthly report that goes out on its own and a committee that decides are worth more than a dashboard nobody reads. In my content machines, I apply the same idea to feedback: a correction that comes back twice becomes a written rule. With an IT services firm it is the same. A recurring defect in acceptance testing becomes a written criterion, not one more remark in a meeting.
05Planning the exit from the start
The most useful passage in the UK manual on suppliers is this one: only work with suppliers prepared to pass on what they know, and have a plan for transferring knowledge, especially when you change supplier. It suggests pairing consultants with in-house staff, knowledge-sharing sessions and documentation kept in good shape.
I turn that into three requirements written into the contract:
- the code and documentation live in your tools (repository, wiki), under your accounts, not the firm's;
- every significant delivery comes with a short note: what changed, why, and how to check it;
- someone in-house follows the project closely enough to ask the right questions the day the team changes.
It is also how I run my own engagements: short, with documented handover at the end. I do not see why a team of ten should be held to a lower standard.
06When an IT services firm is the wrong choice
A firm is not the default answer. It fits three situations badly.
First, when the need is not yet clear. Putting a time-and-materials team on a fuzzy project means paying a lot to find out what you wanted. I would rather scope the project in a week, with a prototype if needed, and then go to market.
Second, when nobody in-house can steer. Without someone who decides, even a very good firm ends up setting the priorities itself, and they are not necessarily yours.
Third, when the project is small. The coordination cost of a team weighs heavily on a few weeks of work. One person who designs and builds can move faster. That is my situation, with its limits: I do not replace a team that runs a system day in, day out.
And a limit of my own method: all this structure takes time on the client side, especially at the start. If you cannot give it a few hours a week, you need to know that before signing.
07Where to start on Monday
If you already work with an IT services firm, take an hour to check four things: the data processing contract exists, the access list is up to date, the current specification has a version number, and someone in-house knows who settles priorities. Whatever is missing becomes the agenda for the next check-in.
If you are about to choose one, write the requirement and the acceptance criteria first, then decide between time and materials and fixed fee knowing who carries the risk. That upstream work is part of what I offer in my services, and the portfolio shows the projects where I have done it. If your situation fits none of these boxes, we can talk it through.