My observation is people often take the view, “no one else can do a project better than we can do it ourselves,” which is often false. The Government of Canada (GC) needs to recognize its propensity to take on significant risk, e.g., as the systems integrator on information systems and digital (IT) projects, which seems founded in:
- A view GC is most knowledgeable and capable to direct and perform the work, while not understanding it lacks necessary experience or the risks associated with the work.
- Not recognizing GC has more options to mitigate risks through competition and contractual controls than doing the work itself, i.e., there are no equivalents to contractual controls or penalties for failure to perform within the public service.
- Not making a distinction between GC’s responsibility to ensure services are provided versus the risk of being the service provider of such services.
- A severe distrust of industry.
World class service providers and SIs have the resources and experience to perform this work which by comparison no public service can match. This is NOT a failing of governments. Governments simply are not exposed to the repetitive experiences that build a sustainable competency in performing work of the complexity and scale that world-class providers sustain.
Service providers and SIs do this for a living – governments do not.
Do-It-Yourself Risk — “Can I have a cup of Cloud with a side of Agile?”
The risk I am describing applies when the Government attempts roles it does not have the experience or resources to perform, particularly at significant scale or complexity, e.g., create or develop solutions, integrate systems, transform environments or provide services. This is compounded by decentralized management and random approaches. By example, imagine IT as buildings. Do you really want a city built where every building developer and maintainer is using their own building code or no code at all? Where GC organizations own their own application architecture, development and maintenance, this is exactly what is happening. Under poor implementations of ‘Agile,’ each floor of a building would be built on a trial and error basis. Frameworks like “Agile’ and ‘Waterfall’ are neither good nor bad, however, their implementations can range from great to catastrophic. Certainly, the ‘Agile’ approach is not a panacea for all ills.
World class providers are held to best practices with certified processes in development, testing and management, e.g., CMMI Institute – usually at Levels 3-5. These practices and certifications have been in use for several decades, however, I am not aware of any GC organizations achieving such certification.
In this day of robust solutions and services, GC should not engage in its own development efforts. (In software parlance, “why would you ever try to write a line of code unless you absolutely had to?”) Major software firms spend billions of dollars on software development and testing. The Government simply cannot, and should not, compete with this robust industry – the risks and expense are not justifiable. Experienced CIOs and CTOs of large enterprises know full well the risks of doing their own development, to the extent they often have policies stating in-house development will be the course of last resort.
“Measure twice, cut once” is an old adage, and nothing in the 21st century has changed its applicability. Experienced solution providers know one of the real challenges is to get requirements correct before providing a solution. Unfortunately, there is a predilection up through the most senior levels to chase “shiny objects” and jump to conclusions on solutions without first defining the need and requirements. Many delays, failures and overruns can be attributed to this tendency.
Public servants can go their entire career and only be involved in one or two transformational programs. Asking these people to participate in or lead some part of a Phoenix-type project is not realistic or fair. Contrast this with the world-class firms whose employees do these types of projects every year and sometimes work on more than one in a year. It is this calibre of experience the Government must obtain when needed. It is riskier for GC to take a do-it-yourself approach than to leverage a market of experienced providers.
To continue the construction metaphor, enterprise IT projects can be viewed like the recent completion of the West Block of Parliament, which was a massive undertaking. The GC used a competitive process to award a contract for the design to a reputable firm with qualifying experience to do such architecture work. Likewise, the Government awarded a contract to perform the construction and associated project management, including a transition to Government management, to a reputable firm with qualifying experience for such work. The Government defined the requirements, managed the contract and prepared to receive and manage the facility once the work was completed. Saying we should have experimented our way through the work of West Block does not make sense, a la ‘Agile’. Large projects can be done, even in IT, providing appropriately experienced people and organizations are engaged. SSC was established to be the central provider of IT services and should continue to build its capacity to manage complex projects as the center of this expertise for the Government, and not have it distributed across several organizations. A topic for another time…
I am not saying all work should be taken to industry. My view at SSC was and continues to be that all decisions should be based on valid business cases where the GC option is the baseline for comparison. There have been cases in GC IT where this was not the approach.
Email Transformation Initiative (ETI)
The objective of ETI is to move ~550,000 mailboxes of 43 partner organizations from 63 email services to a modern, consolidated, secure, more reliable and cost-effective email system. Yes, the program suffered problems. The point here is to understand how the approach fared when things went wrong. Some key points:
- The GC contract was a performance-based service contract where the vendor is the systems integrator and paid for outcomes.
- As the vendor did not initially achieve the contracted outcomes, they worked for two years without being paid while bringing additional resources to bear at the vendor’s expense.
- Eventually, the vendor produced the majority of the service, and the GC used and paid for the service while also gaining credit for missed capabilities or milestones from the provider.
- If the Government had attempted to deliver the service itself:
○ GC would have assumed significant risk as its employees did not have the experience developing and providing such a service of this complexity and scale.
○ When something went wrong, there were no other resources to replace or supplement the workforce.
○ If the GC option failed, GC would have provided additional funds to recover the project – although employees may not have succeeded, they still have to be paid.
- GC had contractual and financial levers to deal with the situation – not available when the Government pursues such projects on its own
- To put the risk factor in perspective, I know at the time this project was initiated there were maybe a half dozen companies on the planet capable of providing an email service of this complexity and scale
Phoenix (Please, don’t cringe)
It is not my intent to dissect Phoenix here. The only point I will make is that the Government took on the role of systems integrator and thereby most of the risk.
One of the key themes here is about risk management, which is how to mitigate risk AND deal with problems when they arise. Not all projects will perform as expected. It is not a matter of ETI not performing as expected – the point is GC was in a much better position when something went wrong. Also, leveraging industry provides an opportunity to leverage the service providers’ ability to self-fund the work. The Government should embrace SSC’s ETI approach by default.
By the way, these risks are not mitigated by the current trend to ‘agile’ or only pursuing small projects and then scaling them later as GC is still assuming the risks by conceiving and doing as much of the work as possible.
The Government of Canada should take immediate and strategic steps to mitigate its risk posture in digitization and IT projects and services, e.g.:
- Formalize a policy whereby GC will no longer play roles such as developer or systems Integrator.
- Pursue COTS solutions and commercial development with GC development as a last resort.
- An appropriate level should be established above which this policy would be in effect, e.g., projects with a total cost above $250,000.
- This policy must accommodate SSC’s role given it is a systems integrator and managed services provider.
- GC needs appropriately experienced leadership and staff to provide digitization and IT services for Canadians and itself.
- Proper business cases should be used to guide decision making with GC options as a Baseline.
- Departments should stick to their core competencies – SSC is the only department where
IT is its core competency; to this end, the Government should continue the consolidation theme of the Shared Services Act to achieve better effectiveness and efficiency.
OK, Another Word on Phoenix
I have been asked many times about Phoenix and what should be done. Given my varied background, including military service, I would like to clarify something: payroll is a commodity service. You have labour categories, rates, types of employment and payroll rules. Saying the world-class payroll providers or solutions won’t work for the Government of Canada, and the Government, therefore, must create its own, is factually incorrect. Companies like ADP do this on an exponentially larger scale than the Government, e.g., ADP services 35,000 businesses in Canada, and 650,000 businesses and 34 million people globally. Other companies, such as Oracle, successfully provide such services as well – there is a robust competitive market to leverage. If a new system is necessary after Phoenix is stabilized (hopefully, based on a well-vetted business case), the best thing for the Government to do is procure it as a service. I think the question for GC employees is, do you want a system proven year after year over thousands of customers or one developed in a hackathon?
A final note. While most of my focus is on IT, many of the issues also apply to non-IT areas, making the issues here much more pervasive than just the IT arena.
About the Author
John Glowacki has the distinction of having held key roles for delivering and procuring solutions within the Governments of Canada and the United States, most recently as COO of Shared Services Canada, as well as during his time in the private sector as the Chief Technology Officer of one of the largest IT firms in the world. https://www.linkedin.com/in/johnaglowackijr.