Implementation Consultant Assessment

Why Implementation Consultants are hard to hire well

This is the job where a signed contract becomes a working system, and it sits on a fault line between two disciplines that hiring processes are used to assessing separately. One half is technical: configuration, data mapping, integrations, migrations, the practical understanding of what the product will and will not do. The other half is consulting: running a workshop with people who disagree, writing something precise enough to sign, and telling a sponsor their existing process is the reason the project is going to be late. Candidates are almost always strong in one half and passable in the other, and a CV describes both halves in the same language.

The market compounds the problem by using one title for wildly different depths of work. An implementation consultant on a self-serve product may be running four two-week onboardings at once, mostly training and configuration. An implementation consultant on an enterprise platform may spend six months on one customer, with data migration from a legacy system, three integrations, a security review and a cutover plan. Both say they led end-to-end implementations. The second job is closer to delivery management with hands on the tooling, and someone who has only done the first will discover this in month two of their first real project.

The most damaging misreading, though, is treating this as a delivery-side version of pre-sales. Solutions consultants and implementation consultants share vocabulary, tooling and often a career path, but they are optimised against opposite pressures. Pre-sales work is rewarded for finding the version of the truth that keeps the deal alive. Implementation work is rewarded for finding the version that survives contact with the customer’s actual data. Hiring a strong pre-sales profile into a delivery role tends to produce a consultant who agrees to things in workshops and then has to unpick them, which is exactly how a project acquires a scope problem it never recovers from.

What separates the best from the rest

The strongest implementation consultants write the requirement down in a form somebody can disagree with. A weaker consultant leaves a workshop with pages of notes and a shared sense of goodwill, and turns them into a build that reflects what they understood at the time. A stronger one leaves with a document that states what will be configured, what will not, what the acceptance criterion is, and who signed it. That document is not bureaucracy, it is the only mechanism by which the customer’s expectations and the delivered system can be compared at all, and its absence is the root cause of most rework in this role.

They also manage change instead of absorbing it. Every implementation attracts new requests, and each one on its own is small, reasonable and easier to say yes to than to price. Consultants who absorb these silently look accommodating for about five weeks and then miss a date they never renegotiated. Consultants who refuse everything look rigid and lose the room. The skilled behaviour is neither: it is making the cost of a change visible in days and risk, quickly enough that the customer can make a real choice, then honouring whichever choice they make. That is a persuasion skill applied to people who do not report to you.

The third difference shows up at handover. A deployment is not finished when it goes live, it is finished when somebody else can support it. The best consultants build the runbook, the configuration record and the enablement material as they go, because they know they are the single point of failure until those exist. It is the least visible part of the job, it is invariably the first thing sacrificed when a project is late, and it is the difference between a customer success team inheriting an account and inheriting a dependency on one person’s memory.

Why interviews alone fall short

Implementation interviews reliably test the wrong artefact. They ask what the candidate has configured, which systems they have integrated, which migrations they have run, and every serious candidate answers well, because those are facts about their history rather than judgements about a live situation. Tool familiarity is worth a few weeks of onboarding. It tells you almost nothing about what somebody does when the customer’s data turns out to be inconsistent in a way nobody disclosed at kickoff.

The project stories are cleaner than the projects were. A candidate describing a difficult go-live is describing it from the far side, where the sequence of decisions is legible and the risks that did not materialise have been forgotten. The interesting moments in an implementation are the ones where two credible options existed and the information to choose between them did not, and those moments do not survive being retold. What you hear instead is a narrative shaped by the outcome.

There is also a medium problem. The core outputs of this role are documents: a requirements specification, a data mapping, a test plan, a cutover runbook. Interviews are conversation. A consultant who explains a design fluently in speech and produces vague, unsignable documents is a common and costly profile, and a conversational process will not catch it. Putting every candidate through the same scoping decisions, the same scope-creep pressure and the same go-live judgement gives you comparable evidence about how they think when the information is incomplete, which is the state the work is actually done in.

Common hiring mistakes in implementation recruitment

• Hiring the pre-sales profile for a delivery role - the two jobs share a vocabulary and reward opposite instincts about what to promise
• Over-weighting technical depth - configuration ability is necessary and is rarely what causes an implementation to fail
• Treating documentation as administrative - the specification and the runbook are the deliverables that outlive the consultant
• Never testing change control - a consultant who cannot price a change request will absorb it, and the timeline pays for it later
• Assuming project management from a job title - owning a plan, a critical path and a cutover is a distinct skill from having worked on projects
• Skipping the data migration question - legacy data is where confident implementations go wrong, and CV lines about migration rarely say who actually did the reconciliation
• Ignoring the pace of a services team - running four accounts at different stages with constant context switching is a real condition of the job and suits some strong candidates badly

The work this role is assessed against

• Run discovery workshops and document current/future state processes
• Create configuration, data mapping, and API/integration specs; validate via Postman and iPaaS
• Prepare and execute data migration and transformation using SQL/Excel
• Coordinate and facilitate UAT, triage defects, and manage change requests
• Develop and deliver admin/end-user training; produce runbooks and SOPs
• Plan cutover, lead go-live, and provide structured hypercare with success metrics

Tools and outputs this role works with

Salesforce and HubSpot as target platforms and records of work, Jira, Asana, Monday.com and Confluence for plans, defects and specifications, Notion for runbooks and SOPs, Zendesk and ServiceNow for support handover, Excel and Google Sheets alongside SQL on PostgreSQL or MySQL for data migration and reconciliation, Postman for API validation, Workato, MuleSoft, Boomi and Zapier for integration build, Okta and Azure AD for SSO and SAML configuration, Lucidchart and Miro for process mapping, Tableau and Power BI for adoption and success metrics, Gainsight and ChurnZero for handover into customer success, GitHub and GitLab for version-controlled configuration, and Slack, Microsoft Teams and Zoom for workshops and hypercare.