Hedging for major government IT projects

Big IT projects are likely to fail. Less than 7% of IT projects over $10M succeed. These failures often include missed deadlines and overstretched budgets. More frequently – and more critically – these failures also include delivering something that does not help the people it was intended to serve.

Established Government of Canada funding and project management processes incentivize the creation and execution of large IT projects. Moreover, dozens of large ($100M+), multi-year IT projects are in flight at any point in time across the federal government. Their execution is an ongoing risk to the effectiveness and reputation of the government.

Hedging is a way of introducing optionality to large, in-flight IT projects: instead of only betting big on a single approach, a small slice of the project funding is dedicated to trying another method. This hedge amount (between roughly $1.5M and $5M) is small compared to the overall project cost, and decreases the risk of failure.

With hedging, if the big IT project fails, there will be another team focused on delivering a quality service that meets the needs of the people who use it. Furthermore, by using modern design research techniques, this hedge team can generate a wide range of insights (from research and prototyping with users) that can be taken up by the primary project team, even if the decision is eventually taken to discontinue the hedge effort.

From traditional IT investment to modern service delivery

• Large government IT investments are funded according to a project mentality: a fixed amount of funds for a fixed period will deliver an output defined and locked-in up front. There is a clear end point, after which ongoing work ends – even if that output does not achieve meaningful outcomes.

• Modern service delivery rejects the idea of an end state, in favour of continuous improvement. It emphasizes ongoing operational funding – funding a team, instead of a project. This team is tasked with pursuing research-informed outcomes, and continuously improves the service it is responsible for in order to achieve these.

• Hedging provides a bridge from the traditional investment model to modern delivery methods. It recognizes that many large projects are already in-flight, and new ones may still be initiated — and it provides a low-risk, low-cost way to introduce modern methods on the same service.

Source of funds

Hedging amounts should be diverted from an initiative’s total funding envelope (for initiatives that have large IT-enabled project components). Diverting funds directly from the initiative ensures that:

• Funds are used in connection with the reason for their appropriation (rather than pulling from excess funding elsewhere within the department).
• Existing IT work for the initiative is done more efficiently.

Under most circumstances, funds for effective service delivery already exist within the system but are poorly allocated.

Use of funds

The hedge amount (at minimum, $1.5M/year and at maximum, $5M/year, scaled to the size of the overall project) should be enough to fund at least one multidisciplinary delivery team.

Hedge funding covers the staffing and operational costs of that team. The team would include a product manager, design researchers, designers, developers and technical architects, and a policy analyst.

These positions must be filled with top talent with recent delivery experience, from either the private or public sector. When bringing talent in from the outside, internal services involved in hiring (e.g., HR, security) should be directed to prioritize these candidates, to staff the team as quickly as possible. Recruitment should be conducted by professionals with experience in digital talent management, not as a “business as usual” departmental staffing action. The team should also include key individuals, hand-picked in consultation with the product manager, with extensive knowledge of the existing service space, embedded full-time on the hedge team.

Expected outcomes include the following:

• Creation of a multidisciplinary team, including hiring of the roles described above.
• Discovery research on the problem space; existing IT, policy, and process ecosystem; and (most importantly) the needs of end-users.
• Development of working prototypes and functional software that can achieve the aims of the initiative (or the primary IT-enabled component), tested and used by end-users incrementally and as soon as possible.

This takes place while traditional IT work for the initiative continues (e.g. continued investment in legacy systems maintenance and upgrades).

Enabling requirements

Funding and creating a team will not generate results if the team is not able to operate in an effective enabling environment. This includes:

• Clearance from traditional project management and reporting requirements (project briefs, requirements documents, gating plans, architecture review committees, etc.).
• Unrestricted access to existing data and systems.
• Autonomy over product decisions, deployments, and software tools.
• Office space and equipment optimized for modern, collaborative work.
• Direct and unfettered access to users of the service, to participate in research and usability testing.

The Secretary of the Treasury Board and the departmental deputy head responsible for the initiative could agree to lift all policy and reporting requirements not connected to specific legal requirements (for example, obligations under the Privacy Act, Official Languages Act, and accessibility standards would still need to be fulfilled). This provides maximum latitude to demonstrate new ways of working and potential outcomes for service investments. In turn, the hedge team would commit to public, outcomes-based reporting (appropriate to the nature of the service) and working in the open.

The hedge team should report to a single top-level executive in the responsible service department who can provide air cover for new ways of working, advise on priorities, and clear barriers as needed. This executive should have regular touchpoints with the deputy head and be exempt from existing, traditional governance committees (project management boards, IT review committees, etc.). Instead, service assessments against the Government of Canada Digital Standards – conducted by a separate, independent delivery team – would be used to evaluate the progress of the team at the conclusion of each project phase.

Timelines and costs

Initial work to stand up a hedge team would take 4-6 months, between the decision to hedge and a team being funded, recruited, security-cleared, and operational. This includes provisioning the office space and tools required for an effective working environment, described above. Costs of this setup time would depend on existing departmental resources and the speed of hiring and onboarding — and would likely be in the $150k to $300k range.

Following that initial setup work, committing to a 12 month period (as little as $1.5M for one small multidisciplinary team) provides sufficient time to test the hedging model for a given initiative. This includes roughly 2-4 months of initial discovery research and 8-10 months of prototyping, iterating, and scaling.

As this period comes to a close, senior leadership could assess the value delivered by the team (in context of the larger initiative). Options for moving ahead would include:

• Renewed hedge funding for the multidisciplinary team.
• Wind-down of the hedge team, if it is not delivering value or if its value can best be harnessed by folding its lessons into the main project.
• Scaling down the ongoing traditional IT investments in favour of scaling up the multidisciplinary approach.

Depending on the scope of the initiative, more than one team may eventually be required. Subsequent teams should be added only as needed, based on the assessment of the value delivered by the initial team.