Order management system selection follows a predictable pattern in almost every family office that goes through it. The COO or CIO identifies the need. A longlist is assembled, usually based on reputation and peer recommendations. Vendors present polished demonstrations of their systems performing flawlessly with carefully chosen data. A shortlist is produced. References are taken. A decision is made.

The problems typically emerge six to eighteen months after go-live. The system that performed beautifully with the vendor's demonstration data behaves differently with the office's actual instruments, structures, and workflows. The implementation that was scoped in three months takes nine. The integration with the custodian feed that was described as straightforward requires significant custom development. None of this was hidden — but the questions that would have surfaced it were never asked.

The questions that matter

The questions that vendors answer in demonstrations — what asset classes does the system support, what does the compliance module do, what does the reporting look like — are necessary but insufficient. The questions that matter are different:

  • What does a typical implementation actually take? Not the fastest implementation you have done, or the average across all clients. What did the last three implementations of comparable scope take, and what were the main sources of delay?
  • Who will be on our implementation team? Not the senior people presenting today — the actual analysts and project managers who will be doing the work. What is their experience with implementations of this type?
  • What does the custodian integration process look like? For each custodian the office uses, what is the standard connectivity, what requires custom development, and who bears the cost of that development?
  • What happens when something breaks post-go-live? What is the support model? What are the SLAs? How are critical issues escalated?
  • What has changed in the product in the last twelve months, and what is on the roadmap for the next twelve? This tells you whether the vendor is investing in the product or managing it.

What family offices get wrong

The most common mistake in family office OMS selection is optimising for feature breadth rather than operational fit. The system with the longest feature list is rarely the right choice. The right choice is the system that handles the office's specific asset mix, entity structure, and workflows reliably — even if it handles other things less impressively.

The second most common mistake is underestimating implementation complexity. A family office with multiple legal entities, trust structures, offshore holdings, and a mix of listed and unlisted assets is not a simple implementation. Vendors will not tell you this unprompted. A realistic implementation timeline and resource budget is essential before a contract is signed.

"The OMS you will live with for the next ten years is the one you have after implementation, not the one you saw in the demo."

The role of independent advice

Independent advice in an OMS selection process serves a specific function: it provides a reference point that is not shaped by vendor relationships. An adviser who has implemented multiple OMS platforms across different asset classes and organisational structures can ask the questions that the office does not know to ask, interpret vendor responses in the context of their actual implementation experience, and assess whether a proposed implementation plan is realistic.

This is not a case for outsourcing the decision. The office needs to own the decision and live with it. It is a case for ensuring the decision is made with complete information — including the information that vendors will not volunteer.

Building the right brief

The foundation of a good OMS selection is a well-constructed requirements brief. This document should describe the office's current state — what it has, what it does not have, and why change is needed — and its target state: not a list of features, but a description of what the office needs to be able to do operationally that it cannot do today.

A requirements brief that is grounded in operational outcomes rather than feature lists produces a different kind of vendor conversation. It shifts the discussion from "does your system have X feature" to "how would your system enable us to do X" — a question that reveals far more about implementation reality and vendor capability than any feature comparison matrix.