Learning what a completed project leaves behind

The first support incident I remember clearly was not a technical outage. A client employee needed to complete a routine administrative step after a software installation, but the person who had demonstrated it was no longer on site. There was a manual, and the manual described a screen the employee could not see. I was new to the support team. My instinct was to locate the correct screen. A more experienced colleague asked why our record did not tell us which version the client was using. That was the more consequential question.

I joined Telbracken Software in June 1997, shortly after completing a computer-systems diploma at Avermont Technical College. My work involved reproducing reported problems, checking access and recording how a case had been resolved. I did not decide the software roadmap or control the client's environment. I learnt to distinguish those boundaries early because an explanation that sounded authoritative could send someone towards a change they were not authorised to make. I also learnt how much useful knowledge could remain in a colleague's memory without ever reaching the next person handling the same issue.

In January 2003 I moved into implementation management. My team of twelve specialists worked with clients preparing to adopt new administrative systems. I had wanted the role because I thought better preparation would reduce the problems we saw in support. That proved partly true. It also exposed a different problem: a project team could meet its documented acceptance conditions while leaving the client's permanent staff uncertain about ordinary work. I began asking who would receive the first question after our team left, and whether that person had practised using the material we were about to hand over.

I joined Velmoraine Systems in July 2009 to lead service transitions. The company needed a repeatable way to take responsibility for client environments without assuming that the outgoing team had recorded everything important. I resisted the temptation to build an ever longer checklist. A checklist could tell us whether a document had arrived; it could not tell us whether it described the environment we would actually support. We introduced short practical demonstrations in which the receiving team used the documentation to answer a realistic request. That exercise often revealed a missing dependency before the transfer date.

By the end of 2015, I led 38 colleagues and had responsibility for a C$6.4 million transition-function budget. I had also learnt a commercial lesson. When knowledge transfer was left outside the priced scope, someone still paid for it: our support team through unplanned effort, the client through delay, or a specialist through repeated calls after leaving the project. I became more willing to put that cost into a proposal and risk losing work. The alternative was not free service. It was an obligation whose owner had not been named.

My appointment as chief operating officer in January 2016 broadened the remit to 260 operations colleagues by 2020. Language coverage became one of the issues that changed my management practice. A headcount report could show enough bilingual people across the company while a particular contracted window had no dependable cover. I asked for a view tied to actual rosters and the kinds of requests those colleagues were equipped to handle. Some managers regarded the detail as unnecessary, but our client promise existed at a particular hour, not in an annual average.

The board asked me to become chief executive in January 2021. The founders remained significant shareholders, and they were understandably attached to parts of the business that had established its early relationships. I recommended reducing a licence-resale activity whose gross revenue made the company appear larger without contributing proportionately to the work we needed to fund. We discussed the loss of purchasing influence and the possibility that clients would move their support elsewhere. I did not present the decision as a simple improvement in a margin percentage. It was a choice about which relationships we wanted to own and what capability they required.

Today I spend more time asking how people test what they believe they have transferred. That applies to a client handover, an executive succession or a board paper describing a completed programme. I want evidence that another person can continue the work under realistic conditions. My experience does not make me an expert in every technology a client uses. It gives me a practical way to ask whether responsibility, knowledge and authority have moved together, and to notice when a completion date conceals unfinished work.

Open to Board appointments

Languages / English · French