What are the lessons learned from Shared Services Canada?

What are the lessons from the government of Canada shared service experiment?

Few government technology initiatives have attempted to change the operating model of government on the scale of Shared Services Canada (SSC). When the organization was created, the ambition was straightforward but enormous: take a fragmented federal IT environment spread across dozens of departments and agencies and consolidate common infrastructure, networks, telecommunications, data centers, email, and other technology services into a shared enterprise capability.

The original case for consolidation was compelling. In the early 2010s, the federal government was dealing with hundreds of data centers, thousands of networks, and more than 100 email systems. The logic was that duplication was expensive, difficult to secure, and increasingly unsustainable. Consolidation promised economies of scale, better security, standardized technology, improved reliability, and potentially hundreds of millions of dollars in savings.

More than a decade later, the most interesting lesson is not whether the original consolidation succeeded or failed. It is that the nature of the problem changed as SSC matured. What began primarily as an infrastructure consolidation program evolved into a much broader enterprise technology organization responsible for connectivity, hosting, cloud, cybersecurity, workplace technology, telecommunications, enterprise architecture, procurement, service management, and digital capabilities.

SSC's own current evaluation framework reflects this evolution. Its 2025–30 evaluation plan identifies four major service areas—connectivity, hosting, digital services, and cybersecurity—and emphasizes the need to examine systemic issues, enterprise approaches, customer satisfaction, stewardship, and outcomes for partner departments. It also places considerable emphasis on using evaluation evidence to improve people, processes, and technology. (Canada)

For governments considering shared services today, this makes Canada's experience particularly valuable. The lesson is not that centralization is inherently good or bad. It is that shared services work when governments get the operating model, governance, economics, service design, and balance between central control and local autonomy right.

From IT consolidation to enterprise government

The original SSC proposition was based on a familiar public-sector problem: government departments had accumulated their own technology estates over many years.

The 2013 analysis of SSC described an environment containing more than 300 data centers, approximately 3,000 networks, and more than 100 email systems. The proposed transformation sought to dramatically reduce this duplication, consolidate telecommunications, create common infrastructure, and move toward a much smaller number of standardized platforms.

The strategy was deliberately narrower than attempting to consolidate all government applications. That distinction was important. Business applications are deeply connected to departmental mandates and operating processes, while infrastructure such as networks, hosting, email, and telecommunications is much more amenable to standardization.

This remains one of the strongest lessons from SSC: shared services should begin with capabilities that are genuinely common.

Trying to centralize everything at once creates unnecessary complexity. Governments should distinguish between common platforms and differentiated business capabilities. A health department, tax authority, border agency, and social services organization may all need secure networks, identity, cloud infrastructure, cybersecurity, and collaboration tools. They do not necessarily need the same case-management systems, analytical applications, or service designs.

The objective should therefore be to build a common digital foundation rather than impose uniformity across every layer of government technology.

The first lesson: consolidation is not the same as transformation

The early SSC program was driven heavily by consolidation. The underlying assumption was that fewer platforms, facilities, contracts, and networks would translate into lower costs and better services.

That assumption was directionally correct, but consolidation is only the beginning.

A shared-service organization changes the institutional relationship between the center and departments. Technology decisions that were once made within individual organizations become enterprise decisions. Budgets, procurement, architecture, operational risk, service management, and technical skills move across organizational boundaries.

That means the hardest part is not moving servers or networks. It is changing decision rights.

A department that previously controlled its own infrastructure may be willing to accept enterprise standards if it receives a reliable, responsive service in return. If the centralized provider is slower, less flexible, or less responsive to departmental needs, the department has a powerful incentive to create workarounds.

This is why shared services should be designed as an operating model, not an IT project.

Before technology is consolidated, government needs to establish who owns the service, who funds it, who sets standards, who accepts risk, who determines priorities, and what happens when the provider and customer disagree.

The second lesson: standardize the foundation, not everything

SSC's experience demonstrates the value of distinguishing between standardization and uniformity.

The case for standardizing infrastructure is strong. Common networks, security controls, hosting environments, procurement arrangements, collaboration platforms, and technology standards can reduce duplication and improve interoperability.

But government organizations operate in different environments. A national security organization, border agency, scientific agency, tax authority, and citizen-facing service department have different requirements and different operational risks.

SSC's current program structure illustrates how far the organization has evolved. Its program inventory now encompasses networks, security, workplace technologies, telecommunications, data-center IT operations, cloud services, and enterprise service design and delivery. The latter includes enterprise architecture, digital innovation, service portfolio management, service management, customer service, project management, portfolio management, and enterprise IT procurement. (Canada)

This is no longer simply a centralized IT department. It is an enterprise technology platform.

That distinction matters for other governments. The goal should be federated standardization: centrally govern the capabilities where scale and security matter, while allowing departments sufficient autonomy to design and deliver services appropriate to their missions.

The third lesson: customer experience is a strategic issue

One of the most persistent risks in shared services is that the provider begins to think like a monopoly utility rather than a service organization.

From the provider's perspective, standardization is efficient. From the customer's perspective, standardization can become a constraint if the service does not respond quickly enough to changing business requirements.

SSC's recent cloud evaluation provides a particularly useful example.

The evaluation found that SSC's cloud services contributed to consolidation and standardization and helped departments access enterprise-level procurement arrangements and pre-certified cloud providers. At the same time, the evaluation identified a significant problem with agility: the average completion time for cloud-related requests was 278 days, while the standard business-request process was described as complex and lengthy. (Canada)

That finding captures a central challenge for shared services.

A service can be efficient from an enterprise perspective while still being frustrating for the organization consuming it.

The implication is that customer experience cannot be treated as a soft measure. It needs to be managed alongside cost, security, availability, and standardization. The right metrics should include time to provision, incident resolution, service availability, customer satisfaction, cost per service, security performance, and the time required to support new government priorities.

SSC's current evaluation plan recognizes this shift by explicitly incorporating customer satisfaction and externally facing outcomes into the selection and sequencing of evaluations. (Canada)

The fourth lesson: centralization creates concentration risk

The economic argument for shared services is powerful because consolidation removes duplication. But consolidation also creates concentration.

If dozens of departments depend on a common network, hosting environment, authentication service, telecommunications platform, or cloud capability, an outage can affect government at scale.

This creates an important paradox: shared services can make individual systems more resilient while making the government enterprise more systemically dependent on a smaller number of platforms.

The implications are significant for cybersecurity and national resilience.

A centralized provider needs stronger redundancy, segmentation, disaster recovery, incident management, change control, and operational monitoring than an individual departmental IT organization might require. It also needs a clear understanding of the dependencies between government and external telecommunications, cloud, software, and technology providers.

Recent experience involving the Canada Border Services Agency illustrates the point. CBSA has worked with SSC on a joint plan following significant IT disruptions, with measures including stronger change controls, integrated incident and change management, improved communication with industry partners, and clearer protocols for outages affecting border operations. (Canada Border Services Agency)

This is an important evolution in the shared-services model.

The question is no longer simply whether the shared platform is cheaper. It is whether government can operate it safely when the platform becomes part of national critical infrastructure.

The fifth lesson: cloud changes the shared-services equation

Cloud computing has exposed one of the weaknesses in traditional shared-services thinking.

Traditional infrastructure consolidation was relatively straightforward conceptually. Government could consolidate data centers, networks, email systems, and telecommunications infrastructure and establish common standards.

Cloud is different because it offers departments more direct access to technology capabilities. It can also reduce the need for government to own and operate every layer of infrastructure.

This creates a tension between enterprise control and departmental agility.

SSC's cloud program initially used a relatively light-touch brokering model, giving departments access to enterprise-level cloud providers and procurement arrangements while retaining significant departmental autonomy. The evaluation found that this approach helped departments access secure, pre-certified suppliers and supported consolidation, but also allowed departments to pursue non-standard approaches that created challenges for consistent security and standardization. (Canada)

The response has been a move toward greater centralization of hosting services.

This provides a broader lesson. Shared services need to evolve as technology changes. A model designed for physical infrastructure may not be appropriate for cloud. A model designed for cloud may not be appropriate for AI.

The governance model must therefore be periodically redesigned rather than treated as permanent.

The sixth lesson: shared services need enterprise architecture

One of the most important capabilities in a shared-service environment is not infrastructure. It is architecture.

Enterprise architecture provides the framework that determines how networks, data, applications, identity, security, cloud, infrastructure, and emerging technologies fit together.

Without it, consolidation can simply move complexity from departmental environments into a centralized organization.

SSC's current program inventory includes enterprise architecture and digital innovation as formal components of its enterprise service design and delivery function. (Canada)

This is an important development.

The role of the shared-service organization should increasingly be to create reusable platforms and common standards rather than simply operate centralized technology.

That distinction becomes particularly important with AI. Government will need common approaches to identity, data, model security, computing, procurement, monitoring, and responsible AI. But it will also need space for departments to experiment with different use cases.

The enterprise architecture function becomes the mechanism for connecting these two requirements.

The seventh lesson: procurement can either strengthen or weaken shared services

The original SSC consolidation program also raised an important concern about procurement.

Large centralized contracts can create economies of scale, but they can also disadvantage smaller suppliers. Consolidating multiple departmental contracts into larger enterprise arrangements may favor large technology providers with the capacity to manage complex national contracts.

This creates a trade-off.

Government wants stronger negotiating power, fewer contracts, consistent standards, and lower administrative overhead. At the same time, it wants competition, innovation, supplier diversity, and access to smaller technology firms.

The answer is not necessarily to avoid enterprise procurement. Instead, procurement should be designed around modular competition.

Large strategic contracts can provide common infrastructure while smaller suppliers compete for defined components, specialist services, innovation challenges, software products, and professional capabilities.

This becomes particularly important in AI, where innovation may come from smaller firms that cannot compete for a single massive whole-of-government contract.

The procurement model should therefore preserve strategic choice rather than simply maximize contract size.

The eighth lesson: skills cannot simply be centralized

Consolidation changes the workforce as much as the technology.

The original SSC transformation inevitably affected departmental technology organizations. Moving infrastructure into a shared provider changes roles, career paths, organizational identity, and the relationship between business leaders and technology teams.

The risk is that government loses valuable institutional knowledge during the transition.

This is particularly dangerous where technology specialists understand highly complex departmental systems that cannot be documented adequately before migration.

The modern SSC model recognizes that people remain a critical part of transformation. Its current evaluation plan explicitly identifies people, processes, and technology as interconnected elements of its OneSSC strategy, with a focus on empowering people, optimizing processes, and leveraging technology. (Canada)

Other governments should take this further.

Shared services should create enterprise career paths for scarce skills such as cybersecurity, architecture, cloud engineering, data, AI, service management, and technology procurement. But departments should also retain enough technical capability to act as intelligent customers.

A government cannot outsource or centralize its understanding of technology completely.

The ninth lesson: evaluation must be built into the model

One of the more encouraging aspects of SSC's current approach is the formal role of evaluation.

Its 2025–30 evaluation plan describes evaluation as a management tool intended to provide evidence about relevance, effectiveness, efficiency, resource allocation, and program improvement. SSC's evaluation function reports directly to the President, while the Executive Committee performs the responsibilities of the Performance Measurement and Evaluation Committee. (Canada)

This is more significant than it might initially appear.

Large shared-service organizations can become difficult to challenge because they sit at the center of government. Departments depend on them, while the organization itself may control much of the information about costs, performance, incidents, demand, and service utilization.

Independent evaluation provides an important counterweight.

SSC's evaluation program has examined cloud services and Linux/Unix hosting and is also examining areas such as Wi-Fi and client service and delivery management, with cybersecurity evaluation also planned. The evaluation plan explicitly prioritizes systemic issues likely to persist over several years and evaluations that can inform decisions about enterprise approaches and externally facing outcomes. (Canada)

This should be regarded as a model for other governments.

Shared services should be designed with institutionalized challenge mechanisms, not merely performance reporting.

The tenth lesson: the economics need to be measured differently

The original SSC program was sold partly on the prospect of substantial savings. That was understandable. Consolidating hundreds of facilities and thousands of networks creates obvious opportunities to eliminate duplication.

But governments should be careful about defining success purely through budget reductions.

A shared-service organization may increase its own budget while reducing total government expenditure. Conversely, it may reduce departmental technology budgets while increasing the cost of centralized operations and creating new transition costs.

The relevant measure is therefore enterprise cost.

Governments should track the full cost of technology across the ecosystem, including shared-service charges, departmental IT, external suppliers, transition programs, licenses, infrastructure, cybersecurity, internal staff, and the cost of delays.

They should also measure the value created by consolidation.

Improved cyber resilience, faster provisioning, better interoperability, greater technology reuse, and access to scarce expertise all have economic value even if they do not appear as immediate cash savings.

This is particularly important as governments move toward cloud and AI, where consumption-based costs can easily obscure the underlying economics.

SSC's evolution offers a more useful model for the future

The most important conclusion from the SSC experience is that shared services are not a destination.

They are an organizational capability that must evolve.

SSC's progression from the original consolidation program to SSC 3.0 and subsequently to the Digital Together approach reflects this evolution. The current model encompasses connectivity, hosting, digital services, cybersecurity, enterprise architecture, service management, procurement, project delivery, cloud, and workplace technology. (Canada)

This is a much broader proposition than simply operating centralized infrastructure.

The future shared-service organization is likely to look more like a government technology platform.

It will provide common infrastructure and services that departments can consume through standardized interfaces. It will operate enterprise cybersecurity capabilities. It will manage common cloud and hosting arrangements. It will establish architecture and interoperability standards. It will support procurement and vendor management. Increasingly, it will provide common data and AI capabilities.

But the most successful model will avoid becoming a bottleneck.

Departments should be able to consume common services rapidly, experiment within defined guardrails, and build differentiated capabilities on top of the enterprise platform.

Perhaps SSC was not too centralized, but not centralized enough

There is another way to interpret the SSC experience.

The difficulties encountered by shared services can be used as an argument against centralization. But the opposite conclusion is equally plausible.

Fragmented government technology creates its own risks. Hundreds of departments operating separate infrastructure, contracts, security arrangements, and technical teams may achieve local flexibility, but at considerable enterprise cost. Fragmentation also makes it harder to establish consistent security standards, respond to national cyber threats, negotiate with major technology suppliers, and develop scarce technical skills.

The question, therefore, is not whether government should centralize.

It is what should be centralized, at what level, and under what governance arrangements.

This distinction is critical.

A government may want centralized cybersecurity controls but distributed security operations. It may want centralized cloud governance but decentralized application development. It may want common data standards but distributed analytical teams. It may want enterprise procurement frameworks while preserving competition among multiple suppliers.

The future is unlikely to be either a giant centralized IT department or complete departmental autonomy.

It will be a federated model built around common platforms, standards, security, architecture, and shared capabilities.

What governments should do differently

The Canadian experience suggests several practical principles for governments embarking on shared-services programs.

First, start with a clear service strategy rather than an organizational restructuring. Define the capabilities that should be shared and explain why.

Second, establish governance before consolidation. Departments need clear decision rights, service expectations, funding arrangements, escalation mechanisms, and representation in enterprise decisions.

Third, prioritize customer experience. A centralized service that takes months to provision can undermine the business case even if it is technically standardized.

Fourth, measure enterprise economics rather than departmental budgets. Include transition costs, operational costs, technology debt, cybersecurity, staffing, procurement, and the cost of slow delivery.

Fifth, design for resilience. Consolidation creates concentration risk, so redundancy, recovery, segmentation, incident management, and supply-chain resilience need to be designed into the architecture.

Sixth, retain intelligent customers. Departments should not lose the ability to understand technology, challenge suppliers, manage business requirements, or make informed investment decisions.

Seventh, preserve supplier competition. Enterprise contracts should be modular enough to allow smaller and innovative providers to participate.

Finally, institutionalize independent evaluation. Shared services should be continuously tested against their original objectives and changing technology conditions rather than being protected by their own institutional momentum.

The real lesson from Shared Services Canada

The history of Shared Services Canada offers a lesson that extends well beyond Canada.

The original proposition was simple: government had too many networks, too many data centers, too many email systems, too many contracts, and too much duplicated technology. Consolidation could create scale, reduce costs, improve security, and provide a stronger technology foundation.

That logic remains sound.

What the experience demonstrates, however, is that the hard part of shared services is not consolidation. It is operating the resulting enterprise effectively.

A shared-service organization must balance standardization with flexibility, scale with responsiveness, central control with departmental accountability, efficiency with resilience, and enterprise economics with service quality.

SSC's evolution also demonstrates that shared services must continually adapt to changes in technology. The issues that once centered on data centers, networks, email, and telecommunications have expanded into cloud, cybersecurity, enterprise architecture, digital services, service management, AI, and digital sovereignty.

This makes the Canadian experience especially relevant now.

Governments are once again facing pressure to consolidate technology, reduce costs, strengthen cyber resilience, modernize legacy systems, and build AI capabilities. The temptation will be to launch another wave of consolidation and assume that the organizational structure will solve the problem.

It will not.

The stronger approach is to build shared digital foundations with distributed innovation. Centralize the capabilities where scale, security, interoperability, and scarce skills create clear benefits. Standardize the things that government needs to do consistently. But allow departments to retain the autonomy required to understand their users, deliver their mandates, and innovate.

The ultimate lesson from Shared Services Canada is therefore neither "centralize" nor "decentralize."

It is centralize deliberately.

Shared services create value when they make government simpler, safer, faster, and more capable. They destroy value when centralization becomes an end in itself.

For governments now preparing for the AI-enabled public sector, that distinction could determine whether the next generation of shared services becomes a strategic digital platform—or simply another layer of government bureaucracy.

For more insights on digital government, technology strategy, AI, and public-sector transformation, subscribe to additional articles from George James Consulting at www.Georgejamesconsulting.com.