Transformation Is a System, Not a Project

Transformation is often described through projects: implement a platform, automate a process, launch a portal, move a service online.

Those things matter, but they are not transformation.

Between 2016 and 2020, I worked with the team at the University of Toronto's Comparative Education Service (CES) through a substantial transformation of its operations. CES assesses international academic credentials for their Canadian equivalency, supporting people pursuing immigration, employment, professional licensing and further education.

Over several years, application intake and output tripled. Revenue increased 198%, from $1.95 million to $3.86 million. Profit increased 329%, from $643,000 to $2.12 million, while operating margin increased from 33% to 55%. Cycle times and backlogs were substantially reduced, customer service improved, and a service that depended heavily on manual and paper-based processes became increasingly digital and scalable.

There was no single project responsible for those results. We progressively changed the way the service operated—measuring performance, identifying constraints, redesigning processes, introducing technology where it could make a difference, and measuring again.

The technology mattered. So did the analysis. But neither would have produced the same result without a team that increasingly embraced change and developed its own capacity for continuous improvement.

That experience changed how I think about transformation.

The first problem was intake

When the work began, much of the credential-assessment application process was manual. Applications, payments and supporting information required significant administrative handling. Information moved between people and systems, data was re-entered, and customers had limited visibility into the status of their applications.

The initial project focused deliberately on intake. We introduced an online application capability intended to standardize data collection, reduce manual handling, simplify the application experience, improve status visibility and provide better operational information.

The results were measurable. Average initial application review time fell from 4.6 days to 1.6 days. Median application completion time fell from 81 days to 31 days during this early phase. Average weekly applications opened increased from approximately 40 to 59, while assessments dispatched increased from approximately 69 to 95.

The project addressed the problem it had been designed to address.

It also exposed the next one.

Improving the front end changed the system

Making the service easier to access increased demand. During one measured period following the introduction of online intake, application submissions increased approximately 52% compared with the same period a year earlier.

That growth put pressure on the processes behind the new digital front end. Applications still had to be reviewed, documents received and verified, international credentials researched and assessed, missing information resolved, customers supported, decisions reviewed and reports produced.

We had increased the capacity to accept work without making an equivalent change to the capacity of the service as a whole.

That distinction became important. The question was no longer how to improve application intake. We needed to understand how the complete operating system behaved.

Making the system visible

We undertook a detailed analysis of CES operations. We looked at demand, volumes, process capability, cycle times, workload, productivity, backlog, financial performance and operational risk.

The level of detail was intentional.

It is difficult to improve a service when you cannot distinguish the visible problem from the constraint producing it. A backlog can appear to be a staffing problem when the underlying issue is workflow. Customer inquiries can appear to be a service problem when customers simply cannot see what is happening with their applications. Long cycle times can result from unnecessary handoffs or administrative work rather than the professional work itself.

The analysis gave us a much clearer view of where work accumulated, what consumed capacity and which changes were likely to make a material difference.

It also gave us a baseline against which subsequent changes could be evaluated.

Within months, output had increased by approximately 30%, and the rate at which the backlog was growing had fallen substantially. That did not mean the transformation was complete. It demonstrated that changing the operating system could change its performance.

Redesign the work before automating it

As the work progressed, our focus expanded from intake to the complete credential-assessment workflow.

That included application and payment, document receipt, validation, missing information, credential verification, research, professional assessment, review, customer communication, report production and delivery.

We began separating work that required professional judgment from work that was primarily administrative.

Credential assessment depends on expertise. Determining the Canadian equivalency of an international credential requires research, experience and professional judgment. Checking whether required information has been provided, applying routine business rules, sending status notifications, transferring information between systems and repeatedly entering the same data generally does not.

That led to a practical design principle: automate administration while preserving judgment.

The objective was not automation for its own sake. It was to use the available capacity more effectively. If technology could perform or eliminate routine administrative work, professional staff could spend more of their time on work that actually required their expertise.

This distinction became increasingly important as volumes grew.

Customer service was part of the process

Customer communication was another source of administrative effort.

Much of it had historically taken place through email. Staff responded to customers and then had to reconstruct or share correspondence so that other members of the team could understand the history of an application.

We introduced Zendesk and began treating customer communication as part of the managed service workflow rather than as a separate activity occurring in individual inboxes. The team had a shared service history, customer interactions became more visible, and service performance could be measured more consistently.

We also worked to make communication more proactive. Customers should not need to contact an organization simply to find out something the organization already knows.

Status notifications, clearer information and better visibility reduced that dependence. Over time, approximately 80% of inquiries were being resolved at first touch, while response times improved by roughly 40%.

The technology helped, but the important change was operational. Customer communication had become part of the design of the service.

Institutional knowledge was also capacity

As administrative processes improved, another constraint became clearer.

CES had decades of institutional knowledge about educational systems, institutions, credentials and previous assessment decisions. Much of the value of the service came from that expertise, but knowledge that must repeatedly be rediscovered consumes professional capacity.

We began making more of that knowledge reusable.

A precedence database introduced in 2020 allowed previous research and assessment knowledge to support subsequent work. Later work connected this thinking more closely with the broader country knowledge base.

Internal analysis associated the introduction of the precedence capability with an approximately 30% increase in output.

This was another form of transformation. We were no longer only digitizing transactions or workflow. We were beginning to make institutional knowledge part of the operating system.

The capacity improvement did not come from asking assessors to work faster. It came from reducing the amount of work that needed to be repeated.

That lesson has stayed with me, particularly in my later work with data and AI. Organizational knowledge has limited value if the systems surrounding the work cannot preserve it, retrieve it and make it useful at the point where decisions are made.

The team made the transformation possible

The numbers tell an important part of the CES story, but they do not capture one of the most significant changes.

The morale, mindset and disposition of the team changed.

Transformation can be difficult for the people doing the work. Established processes change. Familiar routines disappear. New systems are introduced. Performance becomes more visible. Roles evolve. And in a sustained transformation, one change is often followed by another.

The CES team embraced that process.

As improvements began producing results, the team increasingly participated in identifying problems and improving the service. New tools and processes became less about implementing somebody else's change and more about making their own work and the service better.

That created momentum.

It also changed the nature of the transformation. Improvement was no longer dependent entirely on a project or a leader identifying the next problem. The unit itself was developing a stronger disposition toward continuous improvement.

That is difficult to represent on a project plan, but it was critical to the outcome.

A well-designed process can create capacity. Technology can provide new capabilities. Data can show whether performance is improving. Leadership can establish direction and remove barriers. But ultimately, the people doing the work determine whether those changes become part of how the organization operates.

The economics had to work too

We also treated financial performance as part of the operating model rather than as a separate measure reported after the work was complete.

Demand, capacity, staffing, pricing, revenue, cost and service performance were connected. Increasing demand was not necessarily a success if the organization could not process it. Reducing cycle time was not enough if the resulting operating model was financially unsustainable.

That meant examining the economics alongside the workflow and using both to inform decisions.

Over the broader transformation period, application intake and output tripled. Revenue increased 198%, from $1.95 million to $3.86 million. Profit increased 329%, from $643,000 to $2.12 million, and operating margin increased from 33% to 55%.

Those results did not come from a single cost-reduction exercise or technology implementation. They reflected the cumulative effect of increasing capacity, reducing unnecessary work, improving service delivery and creating a more scalable operating model.

COVID tested what we had built

When the pandemic abruptly ended normal on-site operations in March 2020, CES still had some physical dependencies. Credential assessment had historically involved paper documents and the physical production and delivery of assessment reports.

But CES was not starting its digital transformation when COVID arrived. Much of the underlying service had already been redesigned.

The pandemic instead exposed the physical dependencies that remained.

Working with colleagues across the University, we introduced DocuSign into the final report process, allowing CES to provide secure, tamper-resistant electronic assessment reports. Other remaining paper processes also had to be addressed as staff worked remotely.

The distinction matters.

Resilience was not created in March 2020 by suddenly finding a digital tool. The ability to adapt quickly was partly the result of several years spent progressively redesigning the service.

COVID became an unplanned test of the architecture we had been building.

No single technology transformed CES

It would be easy to describe the transformation as a list of systems: online applications, Zendesk, workflow tools, knowledge systems and DocuSign.

That would give technology too much credit.

Each technology addressed a particular constraint or enabled a change in how the service operated. The transformation came from the cumulative effect of those changes across people, process, technology, information, customer service, professional judgment, capacity and economics.

The sequence was also important.

We measured the system and identified a constraint. We changed the process and introduced technology where appropriate. We measured the result. The change altered the system, which often exposed the next constraint. Then we repeated the process.

There was no point at which somebody could reasonably declare the organization "transformed."

It had instead developed a much greater capacity to change.

What I took from the experience

Six lessons from CES have continued to shape how I approach transformation.

Diagnose before you digitize. Technology applied to a poorly understood process can simply automate its problems. Understanding how the existing system actually behaves provides a much better starting point.

Design the service, not just the technology. Improving one component can move the constraint somewhere else. The unit of transformation is the operating system, not the application.

Use automation to protect human judgment. The objective is not to automate everything that can be automated. It is to remove work that unnecessarily consumes the capacity of people whose judgment creates value.

Make performance visible. Measurement makes it possible to distinguish activity from improvement and to understand whether an intervention actually changed the system.

Include economics in the design. Service quality, capacity and financial sustainability are connected. A transformation has to work operationally and economically.

Build the team's capacity to improve the system. Sustainable transformation cannot remain something being done to people. The strongest outcome is a team that understands the system, sees opportunities to improve it and has the confidence to continue changing it.

The detail mattered at CES. It allowed us to understand what was happening rather than rely on assumptions about what was happening.

But analysis was only part of it.

The more important lesson was that transformation is not the implementation of technology. It is the deliberate redesign of a system of people, processes, technology, information and decisions. The work becomes sustainable when the people inside that system develop the capability and disposition to continue improving it themselves.

That is when transformation stops being a project.