Outsourced technology department: what determines the cost

An outsourced technology department means the responsibility for your software existing, working and continuing to evolve sits outside your organisation, with a roadmap decided with you. It is not an engagement with an end date: it is the whole function, sustained over time.

The difference from a fixed-scope project is not one of size, it is one of shape. A project ends when what was delivered is in production, and at that point somebody has to pick it up. A department does not end, because what is contracted is not a delivery: it is that there is someone answering for the system on the Tuesday it goes down and in the quarter when the direction has to be rethought.

None of them is a price. All of them are properties of your situation, so you can answer them yourself before talking to anyone — and answering them is what makes two proposals comparable.

What has to keep working while it changes

A system that can stop for a night and one that cannot may share a plan, but they do not share a cost. Everything it takes to change without stopping — deployments with no downtime, being able to roll back, environments that resemble production — exists because of that requirement and only because of it.

How much surface there is

Not lines of code: pieces that have to be held up. Every system, every integration with a third party and every platform it ships on — web, iOS, Android — is one more thing that breaks on its own, updates on its own and has to be tested on its own.

What is known about the system

The concrete question is whether it can be stood up from scratch on a clean machine by following a document. If the answer is no, the first thing done is finding that out, and that is work before the work starts. It is the factor that varies most between two situations that look alike.

What can be touched

A version of the language with no support, a dependency frozen because nobody knows what breaks when it goes up, a database that no longer receives patches. Each one turns an afternoon's change into a change with prerequisites, and the prerequisites are the part nobody budgets for.

What you are required to prove

The ENS if your client is a Spanish public administration, an ISO if your buyer demands one, the GDPR always. Traceability, access control, a change log and evidence that all of it happens are real work, and they are not done once: they are held up every month.

How much it has to hold up without you

Someone answering at three in the morning costs differently from answering at nine on Monday, and the difference is not the alert: it is what has to be in place for that alert to mean anything. Putting a specific window on the response is what makes two numbers comparable.

How much the direction changes

A plan that is rethought every month is held up by an architecture built to absorb that change without redoing what is already built, and that is decided at the start. It is neither worse nor better than a steady direction: it is a different thing, and which of the two is yours has to be said.

• The programming language. It almost never decides anything. What decides is how many versions behind it is and whether the one running still receives security patches.
• Which cloud it is. If what runs on top of it is built from open pieces, the provider is interchangeable and the choice stops being structural. If it is not, then the cloud is not a cost: it is lock-in, and that is a different problem.
• How many screens it has. Twenty screens on a clean data model cost less than three on business rules nobody has ever written down. What you pay for sits underneath the screen.
• The figure in the first proposal. The starting price says little if it does not say what happens in month thirteen. What has to be compared is the cost of the whole relationship, including the cost of ending it.

Two proposals compare when they answer the same question written in the same words. These are the five that almost never get asked, and the five where the difference between the two numbers sits.

1. What is inside and what is billed separately

   The test environments, the continuous integration, the monitoring, the security updates, the out-of-hours responses. Each one exists in both proposals: the question is whether it is inside the number or arrives later on another line.

2. Who owns each thing when it ends

   The code, the repository organisation, the cloud accounts, the domains, the app store accounts. Ask for it in writing and ask before signing: in Spain, if the contract does not say the code is yours, it may not be.

3. What happens when it ends

   How much overlap there is, what is handed over and in what state. Ask for it in writing before signing: a written exit plan takes ten minutes to read, and one that has to be improvised costs weeks.

4. What happens when the scope changes

   In a fixed engagement, a change is a renegotiation. In an ongoing relationship, it is Monday. Knowing which of the two you are buying explains half the difference between the two numbers.

5. What they can prove about themselves

   Which certifications they hold, with what scope and who issued them; which instrument covers the data transfer if they are outside your country; and whether they sign the data processing agreement before the first access. If they have to prepare it for you, it does not exist yet.

The work being the same does not mean it is contracted the same way. The difference is in what is agreed, and everything else follows from there.

They chain more than they compete: the usual thing is that something has to exist first and then has to be held up. Starting with the one that solves what is in front of you today does not close off the other.