The Project

A large Canadian life insurance company had a significant and legitimate business problem.

Three legacy companies — London Life, Great-West Life, and Canada Life — had been operating separate segregated fund portfolios on a mainframe system. The separation had originally been a legal requirement. The legal requirement no longer existed. The business wanted one unified portfolio, modern technology, and a path off the mainframe.

A solution architect had been engaged, a vendor selected — Temenos, already used for fund accounting — and a project scoped. Six months of development. Three months for installation. Thirty percent new requirements, seventy percent existing functionality.

I was assigned as enterprise architect on the project.

Within weeks, I knew the numbers were wrong.

---

What I Found

The vendor was barely competent in the specific domain that mattered most — custom fund composition and calculation logic. This was not generic fund accounting. It was highly specific, proprietary business logic that had been running in the mainframe for decades, logic that made the company’s segregated fund portfolios work the way they worked.

The users who worked with the vendor’s system every day were not happy. They had simply stopped trying to fix the problems and built workarounds instead. In every meeting, everyone present — the project manager, the solution architects, the portfolio architect, the enterprise architect — heard the users describe their experience and concluded they were satisfied.

I heard something different.

You have to listen to the context, not just the words. A user who describes their system by explaining what they do when it does not work is not a satisfied user. They are a person who has given up expecting it to work.

The requirements analysis was inverted. The SA had characterized the project as seventy percent existing functionality, thirty percent new. My detailed examination found the opposite — seventy percent new, thirty percent existing. More importantly the missing thirty percent in the SA’s analysis was not minor detail. It was the core, complex, custom functionality. The three capabilities listed as non-existent in the requirements were the heart of the business problem the project existed to solve.

The six-month development estimate was not optimistic. It was fictional. The vendor had taken eight months to install an upgrade to their existing system. They were now estimating six months to develop significant custom functionality they did not yet understand.

The three-month installation estimate was more fictional still.

---

The Strategic Problem Underneath

But the deeper problem was not the vendor’s competence or the timeline estimates. It was the decision to use a vendor at all for this specific functionality.

The company was proposing to take the custom fund composition and calculation logic that had been running in their mainframe — the proprietary business logic that defined how their segregated fund portfolios worked — and hand it to a vendor who would own it, build it into their product, and sell it to everyone else.

The correct solution was a custom-built replacement for the mainframe. But the company had a firm organizational axiom against custom development, born from forty years of doing it poorly. The axiom was legitimate in origin. It was being misapplied here.

Not all custom development is the same. Developing generic functionality that vendors do well is one thing. Outsourcing your core business competency — the proprietary logic that differentiates your products — to a vendor who will commoditize it is another thing entirely.

I told my manager this directly. His response was equally direct: if I insisted on telling management that they were giving away their core business competency, the project would end, people would be fired including me, and the disruption would cascade through the organization.

I understood what he was telling me. The truth had a price and he was describing it precisely.

---

The Request

Before I submitted my enterprise architecture document, the architect who had conducted the original solution assessment came to me privately.

He knew what I had found. He knew the requirements analysis was wrong. He knew the timeline estimates were fictional. He knew the vendor competence assessment was generous at best.

He asked me, “Don’t throw us under the bus.”

It was not an unreasonable request from a human perspective. Careers were attached to the decisions I was about to document. The SA process had been conducted in good faith, even if the conclusions were wrong. The people involved were not incompetent across the board — they had simply missed the specific and highly technical domain gap that made this vendor selection problematic.

I understood his position. I also understood that burying what I had found would allow a fatally flawed project to proceed on false assumptions until it collapsed expensively in production — affecting the business, the users, and ultimately the same people the architect was trying to protect.

---

The Third Path

I kept everything in the document. Every risk. Every timeline concern. Every capability gap.

But I framed it carefully.

The requirements inversion — seventy percent new, not thirty — was not presented as an analytical failure. It was presented as a categorization problem. Three specific capabilities had been listed as non-existent in the original SA. Seven had been listed as existing. The difference was that the seven were minor details and the three were core complex custom functionalities that the vendor had not fully understood at the time of the assessment. That framing was accurate. It was also charitable. It gave the SA team a defensible explanation for how the error occurred without erasing the error from the record.

For the strategic concern — the outsourcing of core business competency — I found the only language available to me. I wrote that I had to accept the original vendor decision, even though I had my doubts about it, for the sake of the company.

That sentence was not a capitulation. It was a precise, documented statement that the decision was questionable, that I had reservations, and that I was proceeding under organizational constraint. Anyone reading it carefully would know exactly what it meant. The doubt was on the record. The constraint was on the record. The acceptance was conditional and attributed.

Every risk named. Every timeline fiction exposed. Every missing requirement accounted for. And a charitable explanation for how the errors happened, without erasing them.

Management got the truth. The architect got a face-saving frame. The project got the most accurate picture anyone had produced of what it actually faced.

---

What Happened Next

My manager told me I was on the project as long as it existed.

Two months into a year-long extension, a new COO arrived. He let everyone know who was in charge by firing all architecture contractors — two enterprise architects, an unknown number of solution architects. My manager never found the courage to tell me directly. I learned through rumor and inference.

I made one last honest attempt. I sent an email to the COO directly. I told him I was the only person who understood the business and technology end to end on that project. I told him the project would fail because too many core assumptions were wrong and no domain expertise remained.

When the COO received the email he had security escort me out of the building.

---

What I Know About That Project Today

I am confident it failed.

The roadmap read like a fantasy written by someone drinking past their bedtime. The business teams refused to talk to operations. The operations team was too busy to explain what they were doing. The project manager was happy to talk to everyone without ever solving anything. The business analyst worked as hard as he could against a vendor management team that could not understand the basic logic of fund composition — it was like Esperanto to them, a language they had never heard.

The vendor took eight months to install an upgrade. They were supposed to develop complex custom functionality in six.

This company is a large Canadian institution. Large Canadian institutions have a specific capacity that smaller or more competitive organizations do not — the ability to absorb dysfunction indefinitely without visible collapse. To continue operating in a state that would be fatal elsewhere, sustained by size and inertia and the absence of real consequences.

In Canada, terminal illness is not fatal.

The project failed. The organization continued. The people who made the decisions that produced the failure were not held accountable in any visible way. The COO who had me escorted out for correctly predicting the failure almost certainly considers that decision reasonable to this day.

---

What The Story Is Actually About

The architect asked me not to throw them under the bus.

I did not. I also did not bury what I found.

The third path — document everything accurately, explain charitably, record dissent in the only language available — is harder than either of the obvious choices. It requires holding two things simultaneously that most people treat as incompatible: complete honesty about what exists and genuine care for the people whose decisions created it.

I have been escorted out of buildings for telling the truth. I have had my contracts terminated for seeing things correctly. I have been ignored, bypassed, and managed out by people whose positions depended on not knowing what I knew.

I would make the same choices again.

Not because the outcomes were good. They were not. But because the alternative — learning to see clearly and then choosing not to say what you see — is a different kind of damage. The kind that does not show up in a termination letter. The kind you carry.

Some things are worth the escort out.

---