Business Model Canvas for Government ICT

Over the last few years we’ve spent time modifying the Business Model Canvas for use in the design and development of government systems. For those of you unfamiliar with the Business Model Canvas it is a strategic management tool that creates a shared language for describing, visualizing and assessing business models.

It was invented by Alex Osterwalder, a Swiss business theorist and entrepreneur as part of his PhD research. The tool was specifically designed to address the needs of businesses. It has been adopted widely by startups in Silicon Valley as part of the lean startup movement and has replaced the traditional business plan due to the rapidly evolving and fast changing nature of digital technologies.

The principles used by the Business Model Canvas provide a useful framework for government ICT projects which are notorious for high rates of failure with reports of 70%-80% rates of failure. However the Business Model Canvas needs to be adjusted for use in the government context. We have spent several years modifying and battle testing the Government Business Model Canvas for use in the public sector. Here is what we have developed.

Overview of Government Business Model Canvas

 The Government Business Model Canvas is made up of 3 assessments that answer 3 very critical questions when designing and developing government systems. These are the:

  • Desirability Assessment: What is actually needed by the users? (as opposed to what they say they want)
  • Feasibility Assessment: Do we have the resources needed to implement what is needed?
  • Viability Assessment: Once it is built can we sustain it?
The business model canvas for government systems
High level view of the Government Business Model Canvas for use in the design and development of government systems

Why is the Government Business Model Canvas important?

As mentioned before the failure rate of government IT projects is very high and this has remained unchanged for decades. The business model helps reduce by:

  1. Providing a battle tested set of steps that structure how people assess, design and build systems in government
  2. Ensuring people from different disciplines share a common understanding of the issues and are on the same page
  3. Enabling practitioners to harnesses the talents of multi-disciplinary teams via efficient and effective communication during the implementation of systems

How do we apply the Government Business Model Canvas?

Step 1: Conduct a Desirability Assessment

The desirability assessment (aka needs assessment) involves the end users of the system. It helps everyone involved understand what the users need as opposed to what they say they want. The steps are:

  • Map out the process on a process map (or bpmn) to assess the scope. Identify who is involved (the roles), and for each role identify what they do (the tasks).
  • Map out the data fields on a data definition canvas that need to be captured as input into the process and as output from the process to assess the data structures. 
  • Use the process map to create empathy maps to assess what the users issues are. For each role, Identify the pain points for each task and what the gains would be if we solved the issues.

Prioritise the pain points using a pain vs frequency matrix to understand which issues are most important to users. Categorise which issues can be solved with technology.

Step 2: Conduct a Feasibility Assessment

The feasibility assessment involves the dev team (i.e. people with the skill sets required to develop solutions) and it helps assess whether the solutions needed to satisfy the users needs are feasible given the resources available (i.e. timeframe, budget, capacity i.e. knowledge/skills/experience). The steps are:

  • Use the pain vs frequency matrix to map out on a value chain map what components are needed to implement solutions to each pain point.
  • Plot the value chain onto a Wardley Map based on market conditions to assess technical feasibility.
    • Optional: The dev team may occasionally need to spin up small projects to develop Proof of Concepts (PoC) to validate technical feasibility of a specific value chain
  • Use the Wardley Map to cost out each component and develop the subscription list (rent), the procurement list (buy) and the feature list (build) to assess financial feasibility.
  • Use the Wardley Map and the Pain vs Frequency Matrix to do an impact vs effort matrix to assess what is feasible with the skills, capacity and knowledge available.
  • Use the wardley map to decide on what implementation methodology (lean, agile or waterfall) to use on what components in the value chain.
  • Breakdown the value chain into tasks and place onto Kanban Board or Gantt Chart or Resource Planning
    • Assign the tasks to the dev team based on knowledge, skills and experience [implementation]
    • Request budget, timeframe and resources to implement the project [implementation]

Step 3: Conduct a Viability Assessment

The viability assessment involves the management team and it helps assess whether the system is viable once it is built. The steps are:

  • Use the Wardley Map to map out the cost structure of the systems value chain
  • Identify the revenue streams that will be required to cover the cost structure  
  • If revenue > cost structure then the system is viable. If not then the system is not viable.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: