Before You Start the Next Engagement

If a previous technology initiative didn’t deliver, the next decision matters more — not less. These five questions were built from real delivery failures in institutional asset management. They separate partners with genuine capability from those who will discover the hard parts on your timeline.

Most Vendor Evaluation Fails Before the First Meeting

The standard approach to evaluating a technology partner — capabilities presentation, reference check, proposal review — is designed to surface what vendors want to show you. It rarely surfaces what you actually need to know: whether they can deliver in your specific environment, with your specific constraints, at the level of precision your business requires.

In institutional asset management, that precision gap is where most projects fail. The vendor knew how to build what you asked for. They didn’t know how your compliance team would respond to a mid-stream requirement change. They didn’t have a rollback strategy ready when the go-live window closed early. They hadn’t worked in an environment where every cutover carries real regulatory exposure.

“The questions that matter aren’t about what a vendor can do. They’re about how they perform when conditions stop matching the proposal.”

Five Questions. One Standard.

01

How is risk validated before rollout?

Validation at go-live is too late. By that point, the cost of changes is prohibitive and the tolerance for delay is near zero. A delivery model that treats testing as a phase — rather than a continuous practice — will transfer that risk to you at the worst possible moment.

  • Red flag: “We run QA at the end of each sprint”
  • Right answer: Validation is embedded throughout — with specific checkpoints before each environment transition

02

What happens when requirements change mid-project?

Requirements change in every asset management technology engagement. Compliance frameworks evolve, business priorities shift, and systems reveal undocumented dependencies once work begins. A vendor with a fixed-scope model will treat these changes as contract amendments. A delivery model built for real conditions will absorb them.

  • Red flag: “Changes go through our change request process with impact assessment and re-scoping”
  • Right answer: Specific examples of how the team adjusted delivery mid-engagement without resetting scope

03

Who owns the outcome?

Not who does the work — who is accountable for the result the business needs at the end of the engagement. In fragmented vendor models, no single group carries that accountability. Work gets done. Tickets close. But no one is standing behind the final outcome as their responsibility.
  • Red flag: Vague answer referencing the project manager or “the team”
  • Right answer: A named individual or defined team with explicit accountability for delivery against business outcomes — not work product

04

How is rollback handled?

At go-live in an asset management environment, the window for failure is effectively zero. If something goes wrong during cutover, the ability to reverse instantly and cleanly is not optional — it’s the only acceptable posture. A vendor who hasn’t documented their rollback strategy before deployment begins hasn’t accounted for the real risk profile of your engagement.
  • Red flag: “We’d assess the situation and work through it with your team”
  • Right answer: A specific, pre-defined rollback procedure with tracking and confirmation steps — built before deployment, not after something goes wrong

05

What similar work has this team completed?

Not what they can build. What they have built — in this industry, in production, for firms managing comparable AUM, using systems your team actually runs. The gap between a vendor who has delivered in asset management and one who is learning it on your engagement shows up in how quickly they understand the problem and whether they can earn internal credibility with your business team.
  • Red flag: Case studies from adjacent industries or generic enterprise technology
  • Right answer: Specific, comparable projects — same systems, similar firm type, outcomes in production

How These Questions Emerged

The framework above was built backward from delivery failures: real projects in institutional asset management that reset, overran, or produced outcomes the business couldn’t use. In each case, the answers to at least two of these questions would have identified the gap before the engagement began.

The full brief documents the specific delivery failures that informed this framework, and includes two anonymized case studies of projects that succeeded — one a platform migration from per-client to multi-tenant architecture, one an automated configuration migration tooling engagement that replaced a manual, high-risk process. Both are in production. Both were completed on scope.

If you’re currently evaluating partners, starting a new initiative, or rebuilding after a failed engagement — this framework and the case evidence behind it are in the brief below.

Download the Full Brief