Why this article exists

Implementation is one of the most misunderstood roles in technology. Job adverts describe it in wildly different ways. Some call it "Technical Account Manager," others "Onboarding Specialist," others still "Solutions Consultant." The titles obscure the work.

This article cuts through that. It describes what implementation actually is — the real work, the real responsibilities, and the real challenges — in enough detail that someone who has never done the job can understand it completely, and someone who has can recognise themselves in every paragraph.

The simplest definition

Implementation is the process of taking a software product that has been sold to a client and making it operational within that client's organisation.

It sounds simple. It is not simple. Between "sold" and "operational" lies a complex sequence of discovery, configuration, integration, training, testing, change management, and support that can take anywhere from two weeks to eighteen months depending on the product and the client.

The Implementation Manager (IM) owns this process. They are responsible for ensuring the client goes live successfully, on time, and in a state where they will actually use the product.

What an Implementation Manager is not

• Not a developer. An IM does not write production code. They may configure software, but they are not building or debugging the product itself.
• Not a salesperson. An IM typically enters after the sale is closed. Their job is not to sell — it's to deliver.
• Not a support agent. An IM handles onboarding and adoption, not ongoing break-fix support.
• Not a project manager in the traditional sense. The IM runs the project, but their primary accountability is business outcome, not deadline.

The three fundamental tensions

1. Client needs vs. product capability

Clients often arrive at implementation with a mental model of what the product will do for them that doesn't perfectly match what the product actually does. Part of discovery is closing this gap — either by adjusting the client's expectations or by documenting genuine gaps and escalating them to the product team.

2. Speed vs. rigour

Clients want to go live quickly. But implementation done too quickly fails. The IM must hold the line on minimum viable rigour while being commercially aware enough not to gold-plate unnecessarily.

3. The client's technical team vs. the client's business team

In most enterprise implementations, the IM is working with two different client audiences simultaneously: a technical team who cares about how the system is configured, and a business team who cares about outcomes. The IM must translate between them.

The four core responsibilities

1. Scoping and planning

Before a single piece of configuration is touched, the IM must understand exactly what the client needs, what success looks like, and what resources are required to achieve it. Poor scoping is the root cause of most implementation failures.

2. Stakeholder management

The IM is permanently in the middle of competing stakeholders: the client sponsor, end users, the IT team, the vendor's product team, and the commercial team. Managing these relationships is a full-time job within the job.

3. Technical bridging

The IM doesn't need to be technical. But they need to be technically literate — able to understand what their engineering team is telling them, translate it into business language for the client, and translate requirements back into technical terms.

4. Change management

Software implementations don't just change technology. They change how people work. The IM who treats their job as purely technical almost always encounters post-launch adoption problems. The IM who treats their job as organisational change facilitation builds implementations that last.

Before the phases begin

Implementation doesn't start at a kickoff call. It starts the moment a deal is closed. The best implementation teams are involved in late-stage sales conversations to ensure that what's being sold is actually achievable.

Why case studies matter in implementation interviews

The most common barrier for career changers is this: every job description asks for 1–2 years of implementation experience, but you need the job to get the experience. The way through is to demonstrate that you can think like an Implementation Manager — and the most compelling way to do that is to show your work.

Using your completed exercises as portfolio evidence

These three exercises, completed to a high standard, constitute a genuine portfolio of implementation capability. Reference them in applications, walk hiring managers through them in interviews, and share them with a mentor for review before your next application.