The recent introduction of the new Government of Canada (GC) IT Strategic Plan 2016-20201 and the Treasury Board Policy on Results2 provide an opportune time to test new approaches in creating better digital services for Canadians. This article lays out a simple seven-step model for transforming the way an organization can deliver Information Technology (IT) projects by shifting the focus from project metrics (outputs) to business metrics (outcomes).
According to a Harvard Business Review3 article, one in six IT projects has an average cost overrun of 200 percent. This is a clear sign that new approaches are required. Other reports from McKinsey4, Gartner5 and more recently Shared Services Canada have also highlighted the poor success rates of IT projects. We believe one of the root causes for low success rates is the strong reliance on project scope completion as a measure of project success. Success has traditionally associated with delivering on time, on budget and on scope. Perhaps a truer measure of a project’s success is whether it delivered the planned benefits at a reasonable cost. In fact, the Project Management Institute (PMI) just recently evolved its definition of project success by stating, in the opening words of the Pulse of the Profession 20177 survey: “The traditional measures of scope, time, and cost are no longer sufficient. Projects must deliver what they set out to do — the expected benefits.”
The recent release of the new Policy on Results and the (GC) IT Strategic Plan 2016-2020, prompt the exploration of new ways of delivering digital services. On one hand, applying a Results & Delivery (RD) perspective to this problem helps shift the focus away from the Outputs (the project scope, the product, the service) and more towards the Outcomes (benefits generated by the output). More specifically, the RD Manual,8 produced by Delivery Associates to help the public service apply RD thinking, encourages:
- The clear identification of outcomes
- The use of data to identify which strategies (the scope) to implement; and,
- The use of routines to confirm that the adopted strategies do indeed produce the intended outcomes. As also stated in the manual, RD is an uncompromising focus on outcomes.
Conversely, the new (GC) IT Strategic Plan 2016-2020 emphasizes the need for increased agility and recommends the adoption of Agile methodologies and cloud services. These recommendations are strong enablers of iterative approaches that embrace adaptive planning, continuous improvement and efficient response to changes by evolving requirements and solutions through the collaborative effort of self-organizing and accountable cross-functional teams.
The timing is ideal to combine approaches by focusing first on outcomes, followed by empowering project teams to iteratively refine what the scope is that will deliver the planned benefits. A paradigm shift may be needed as many IT project managers and investment management governance committees continue to focus on and expect upfront detailed scope documents instead of focusing primarily on the project outcomes.
Where to start? The following steps will help transform the way an organization delivers software solutions and digital services.
- Apply Outcomes – Management to IT project investments
As a leader, you are measured on how well your actions help deliver the organization’s mandate, and IT projects should be used as a means to achieving this end. Before creating business requirements – and especially before deciding which IT solution to implement – start by clearly identifying your desired project benefits and ensure that these strategically align with your organizational priorities and your Departmental Results Framework. The TBS Guide and Tools on Outcome Management9 and the Policy on Results provide great direction to identify good outcomes that are clear, measurable and properly “baselined.”
- Seed fund projects to take away the guesswork involved in writing business cases
Most IT gating models only release project funding once a business case is approved. When the efforts of creating a business case are not already pre-funded and part of operational activities, organizations tend to rush the business case to secure quick funding so they can staff the project team. To prevent this along with, trying to predict upfront what scope (and related costing) will deliver the planned benefits, release part of the project funding once the planned benefits are identified and approved. This seed funding will give an organization enough runway to gather insights and reduce the number of assumptions needed to finalize a more solid business case.
- Conduct user research and apply data-driven management
Use data to drive decisions. For example, if a department wants to increase the adoption of a digital service by 20 percent (outcome), the solution may be to:
- Attract more people to the digital service page; or,
- Optimize the digital service workflow to increase completion rates.
Either path could arguably increase adoption rates. Yet without proper user research, analytics and usability testing, it may be unclear which path (project scope) is best. Seed funding the project will let an organization gain these insights before prematurely finalizing a business case and making unnecessary assumptions about the needed scope.
- Apply RD thinking at the requirement level
Agile teams often define requirements in User Stories, which is like applying RD at the requirement level- User Stories focus primarily on the outcome of the requirement and not on the solution that will deliver the outcome. For instance, instead of writing a requirement as: I want a blue print button in the top right corner, rather capture the requirement as: I need to print weekly reports. Then let the team decide what the most cost-efficient way of developing the IT system to fulfill this business need is. User Stories should also be relatively prioritized based on the business value they provide and their ability to reduce risk.
- Gain user and sponsor feedback quickly
Take the highest priority user stories and start building a Minimal Viable Product (MVP). Building this small increment of the final product will continue to help the team gather data quickly. Start with a sketch and then develop a working prototype. Sharing these deliverables early with stakeholders will help generate great feedback and reduce the risk of poor user uptake once the product is launched. Creating a MVP also helps confirm that the suggested technical solution is feasible and assists in mitigating delays in procurement or development environment setup. Finally, the MVP will also provide early signs to validate the hypothesis that the planned solution helps deliver the outcomes.
- Adopt a measurement routine: build iteratively and deploy to the Cloud
If the only opportunity sponsors have of defining a product’s scope is early in the project lifecycle, they will tend to ask for everything that comes to mind to be sure it gets planned in. However, we often don’t know what we don’t know and it takes considerable effort and luck to precisely define a full set of software requirements at the beginning of a project. The RD approach encourages the adoption of routines to gather data and course correct if needed to reach the benefits.
By building the solution in the Cloud, an organization can easily establish that routine early in the project by making increments of the product available to users for testing. Then by empowering sponsors and users to adjust scope as the project evolves, an organization may run into the unthinkable scenario where sponsors realize that only 60 percent of the initially planned scope was in fact needed to generate the planned benefits. When sponsors, users and project teams work as partners to apply a simple Plan-Do-Check-Act cycle of iterative short-term planning, delivery, re-evaluation and adjustment, they reduce the risk of delivering irrelevant software products that miss business objectives or demonstrate failed agility to respond to changing market conditions.
- Focus your governance on the outcomes and trust your team
Governance committees should try not to manage the detailed scope of a project. If it strongly believes that it is preferable to deliver the intended benefits than to deliver the planned scope exactly, it should move ahead. The condition is that the project team operates within the needed constraints of time, cost, security, privacy and enterprise architecture. Rather, governance committees should focus accountability on reaching benefits and towards the sponsors, users and project teams who decide and iteratively adapt the project’s scope and increase the likelihood of delivering the planned benefits.
RD and Agile are not new concepts but, when combined, they will help fuel innovation and use taxpayers’ dollars more efficiently to deliver better applications and digital services faster to Canadians.
References
- https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/information-technology-strategy/strategic-plan-2016-2020.html
- https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=31300
- https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think
- http://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
- https://www.gartner.com/doc/2892218
- http://www.ssc-spc.gc.ca/pages/ae-ve-eng.html
- http://www.pmi.org/learning/thought-leadership/pulse/pulse-of-the-profession-2017
- https://gcconnex.gc.ca/file/view/23791295/results-and-delivery-manual
- https://www.canada.ca/en/treasury-board-secretariat/services/information-technology-project-management/project-management/outcome-management-guide-tools.html
Rick Koeller is the Manager, Project Management Office, Canadian Internet Registry Authority (CIRA). rick.koeller@cira.ca
Anthony P. Sheehan is the Director of Enterprise Architecture at Correctional Service Canada. anthonyp.sheehan@csc-scc.gc.ca
