What is the best question to ask a prospective partner?

What went wrong on their last engagement of this kind and what they changed afterwards. A specific answer demonstrates recent work and a willingness to be candid; a general one about methodology usually means the specifics are not available to be discussed.

How do we tell whether the handover actually worked?

Somebody internally makes a change without calling them, and it works. That is the only test that distinguishes a genuine handover from a well-received training session, and it is worth running deliberately before the engagement ends rather than discovering it afterwards.

Should the contract have an end date?

It should have a definition of done that somebody can check. A date alone slips and a scope alone expands, whereas a stated condition for completion gives both sides the same picture of what finishing looks like and makes an extension a decision rather than a drift.

Glossary

Implementation partner

An outside firm that gets a tool working in your organisation and then leaves, which makes leaving well the thing being bought.

In plain terms

Somebody who has done this before, brought in to do it here. The value is partly the work and mostly the mistakes they already made somewhere else, which is why the useful question is not what they will build but what they know that you do not.

Why it matters

Because most organisations adopt this kind of tool once and a partner has done it repeatedly. That asymmetry is the entire proposition, and it is also why the engagement is hard to judge from inside: a buyer cannot easily tell whether they are being told what usually happens or what the partner would like to be true.

How it works

The engagement has an end, which is the property that distinguishes it from every arrangement it resembles. It is meant to conclude with the organisation running the thing itself, so any structure that quietly makes the partner permanent has become something else without anybody deciding to buy that instead.

Handover is the deliverable and is usually treated as the last item on a list. What somebody internally can now do, and what they can now explain, decides whether the engagement worked, and that is a different thing from whether the system was built well.

Their pattern knowledge is the most valuable and least invoiced part. Knowing which integrations always take longer, which internal objections arrive in week three and which configurations look sensible and cause trouble later is worth more than the hours, and is what a buyer should be extracting deliberately rather than hoping for.

Incentives point towards a longer engagement, and that is not a criticism so much as a fact to structure against. Nobody has to behave badly for a project to grow: scope naturally expands, dependence naturally builds, and a contract with no defined end will find one much later than it needed to.

In this category their experience dates unusually fast. What was true about the tools eighteen months ago may not be, so recent work matters more than long experience, and a partner's honesty about what they have not done recently is a better signal than a list of everything they have ever touched.

Two engagements that cost the same

The right-hand column is the common outcome and it is nobody's fault in particular, because every incentive quietly favours it. The partner is measured against a specification, documentation that describes what exists is easier to write than documentation that explains why it is like that, and the moment for a real handover arrives exactly when both sides are tired and the budget is nearly spent. What separates the two columns is deciding early that somebody internally owns the thing, and then having that person do the work rather than watch it. That costs the engagement some speed, which is the actual price and is worth naming, because a partner working alone finishes faster and a partner teaching somebody finishes better. The test at the end is short and worth running before the final invoice rather than after: ask the internal owner to make a small change unaided. If it works, the engagement ended well. If the answer is that they would rather ask, the organisation has bought a system and a future dependency, at the price of the system alone.

Seen in the wild

A partner configuring an assistant deployment and training the people who will run it afterwards.
ChatGPT
Bringing in help for the connectors a search deployment needs, then taking them over.
Glean
An automation build handed over with somebody internally able to change it without calling anyone.
Make

Common misconceptions

People assume

The build is what you are buying.

In fact

The build plus the ability to carry on without them is what you are buying. An engagement that produces a working system nobody internally understands has delivered half of it, and the missing half is the expensive one to acquire later.

People assume

Long experience is the main credential.

In fact

Recent experience matters more here than in most categories, because what was true about these tools eighteen months ago frequently is not. A partner clear about what they have not done lately is telling you something more useful than a long list.

Questions

What is the best question to ask a prospective partner?: What went wrong on their last engagement of this kind and what they changed afterwards. A specific answer demonstrates recent work and a willingness to be candid; a general one about methodology usually means the specifics are not available to be discussed.
How do we tell whether the handover actually worked?: Somebody internally makes a change without calling them, and it works. That is the only test that distinguishes a genuine handover from a well-received training session, and it is worth running deliberately before the engagement ends rather than discovering it afterwards.
Should the contract have an end date?: It should have a definition of done that somebody can check. A date alone slips and a scope alone expands, whereas a stated condition for completion gives both sides the same picture of what finishing looks like and makes an extension a decision rather than a drift.

Key takeaways

The engagement is meant to end, which is what makes it this rather than a managed service.
Handover is the deliverable, not the final item on the plan.
Their pattern knowledge is the least invoiced and most valuable part.
Recent work matters more than long experience in this category.