Open Data: A product approach

Purpose

What is open data? Believe it or not, this is a very common question, and rightfully so. Many people are unaware of the decade long open data movement that has been going on in Toronto, longer elsewhere in North America. Governments around the world are making an effort to make data available to the public free of cost under an open license. There are many reasons for this, such as:

• enabling economic opportunities
• improving operational efficiencies
• increasing transparency
• stimulating innovation

With such noble intentions why are so many people unaware of the open data movement? One reason could be the initial target audience, application developers. The early days of open data in Toronto focused on releasing data with the hope that software applications would be developed to improve social services. While there have been some successful applications developed from the City of Toronto’s open data (i.e. Rocket Man) the level of application development did not reach the desired level, meaning the positive news and linkage that would accompany the promotion from an app did not occur. The second, and maybe the more likely reason, people are scared of data. The majority of people do not search out data for the sole purpose to perform analysis or to build software applications. Most people are intimidated by data and are unaware of how to begin working with open data; let alone understand how to perform statistical analysis, machine learning, or complex visualizations. The open data movement, like many technology related areas, has a marketing problem, they couldn’t communicate the “how will this help me” question that is so important to go mainstream.

Open data at the City of Toronto has been up and running for a decade this year, with an amazing and active community. However, this is not the case everywhere, and outside of our exceptional community, open data is still unknown by many. With this in mind the City of Toronto’s Open Data team decided to look at changing the conversation around open data by implementing a product management approach to the Open Data Master Plan project, with the hopes of improving communication and adoption of open data not only within Toronto but also worldwide.

Within this story we will outline our product approach to the Open Data Master Plan and how we are approaching productization.

The Open Data Master Plan

On January 31, 2018 the Open Data Master Plan was unanimously adopted by City of Toronto Council, endorsing the four year strategic direction and roadmap for revamping the City’s open data initiative to be more inclusive and benefiting a wider audience, including individuals with a minimal technological background.

The Open Data Master Plan (ODMP) was co-developed with the community and consists of four themes and twelve actions that provide the direction needed to shape the future of open data in Toronto. Keeping with the name of the team, information about the plan is openly available here, including artifacts collected during the Open Data Master Plan process. Specific detail about the plan can be viewed here.

Productization

The Open Data Master Plan was developed to be consumable and actionable, outlining 76 deliverables to be tackled over a four year period. During the first year of the ODMP project the team undertook the work typical to many IT projects:

1. build a workplan
2. develop a schedule
3. prioritize work tasks
4. work on tasks
5. test developed components
6. deploy components
7. report

While this method may be successful for other IT projects it wasn’t working for the ODMP, which was diverse and meant to be co-executed with the community. Furthermore, defining the scope of many of the deliverables was difficult, making reporting on progress a challenge. The project team quickly realized that a change was needed. Being nimble and passionate the team was up for the challenge.

With data in our name, Open Data team, we decided to take some data analysis principles to get a better understanding of the project and began classifying each deliverable in three areas:

• type (technical or non-technical deliverable)
• owner (primary responsibility for making decisions and input)
• priority (low, medium, high, and critical)

Looking at the results of the classification exercise was very telling. Immediately we realized that the vast majority, ~60%, of the deliverables were non-technical, a surprise for an IT project. With the additional three pieces of information (type, owner, and priority classification) we were able to dissect the project and gain a greater level of insight than before.

Figure 1: Deliverable types

Like with many projects one of the first things we wanted to know was the breakdown of the priorities. While understanding the distribution of priorities was important, grouping the priorities with the delivery type was extremely telling. Very quickly we were able to see two valuable insights:

1. Low priority deliverables were primarily non-technical
2. The vast majority of technical deliverables were medium to critical

This information was very valuable, it provided us with the ability to plan and communicate, based on data, contingencies within the project. For the first time we were able to built “what if” scenarios that we could communicate to project stakeholders, senior executives, and the community at large. This information empowered us, we were able to make evidence based decisions on what deliverables would not be completed if changes or unplanned events influenced the project.

Figure 2: Delivery type and priority level

While the classification approach provided valuable insight to understand and improve our planning process, it did little to alleviate the challenges associated to defining scope, reporting progress, and communication the value of open data. A different approach was required.

Product Alignment

At this point you may be saying “this is fairly basic project planning approaches” which would be correct. Applying different classification to the deliverables was beneficial for planning and risk mitigation, but it did not provide the information needed to assist with many other challenges. For this reason we decided to take a different approach, product.

What is a product approach? Before we get to the approach let’s look at what a “product” is. Some typical definitions of a product are:

• An article or substance that is manufactured or refined for sale
• A thing or person that is the result of an action or process

These definitions while good, did not fit with the principles of open data, so we decided to make a spin on product that reflected the values and goals of open data:

product: an application, artifact, or process that is created to provide civic value, available openly and free of charge.

With a working idea of what product meant in the world of open data we were set to align the deliverables to products. Six products streams were identified within the Open Data Master Plan:

1. Business Plan
2. Datasets
3. Framework
4. Pipeline
5. Policy
6. Portal

Deliverables, where applicable, were aligned to one of the six products resulting in 48 deliverables mapped to a product. The largest product stream is the business plan and the portal, each with 12 deliverables.

Table 1: Open data master plan products

Defining and aligning the deliverables to a product was the first step, the real work for productization was establishing the product level for all relevant deliveries over the four year project period. Product levels were identified as proof of concept, minimal viable product, version 1, and version 2. The following are the definition for each of the four product levels used within the Open Data Master Plan productization.

Proof of Concept (POC)

The purpose of a POC is to test the feasibility of an Open Data Master Plan deliverable. A POC is not meant to be used by users or in production, but rather gain insights to future development. An example of a POC could be process flow diagram, dynamic dashboard in Google Sheets, etc.

Minimal Viable Product (MVP)

The purpose of the MVP is to have a functional working version of the deliverable; not focusing on all the features that would be desired. An MVP allows for evaluation by users within a controlled environment.

Version 1 (V1)

The purpose of the V1 is to implement a feature rich stable product capable of performing in operational situations. The V1 has been tested and improved by minimal feature enhancements.

Version 2 (V2)

The purpose of the V2 is to add additional feature enhancements to the delivery. A V2 product is the highest expected level within the Open Data Master Plan.

The 48 product deliveries were mapped to one of the four product levels (POC, MVP, V1, or V2) for each year of the project, illustrating the planned product progression for the Open Data Master Plan. The majority of the deliverables are proof of concepts, with no version 2 deliveries.

Figure 3: Product tiers

Similar to the classification exercise, the product tiers were linked to the priority groups and product streams, illustrating valuable insight. The POC deliveries are primarily comprised of low and medium priorities, while V1 are made up of high and critical deliverables.

When looking at the product tiers across the product streams it clearly shows that POCs are distributed throughout all six of the streams. This analysis also identifies the four streams (business plan, framework, pipeline, and portal) that have version 1 products.

With product tiers and streams identified we had the pieces needed to communicate progress. Prior to the product approach we consistently came into the same issue “how do we report where we are on a deliverable” especially when they could occur over multiple years and may evolve unconventionally. The product tiers allowed us to apply a weighted score for each of the four tiers:

• POC — 1 point
• MVP — 3 points
• V1–6 points
• V2–9 points

By implementing the product tiers into our project management planning process we can now track the progress and report how the project is doing through a simple comparison of what was planned vs. what was delivered. For example, within Theme 4 there is a deliverable to implement visualizations of open datasets in the portal, which was planned to be a MVP in 2019, however a V1 has been implemented to date; making reporting a simple task:

2019 actual minus 2019 planned OR V1 (6) — MVP (3); product score of 3

This approach was performed on all deliverables that were aligned to a product tier and was built into a simple dynamic reporting dashboard outlining the Open Data Master Plan product performance (available here).

Next Steps

Like most new approaches there are still areas that need work or revisions. Within the productization of the Open Data Master Plan we plan to identify the features of each product tier for all product deliveries. This level of effort will allow us to identify dependencies and relationships between products.

Resources

The City of Toronto’s Open Data team works in a collaborative environment and tries to be fully transparent. We regularly commit to our publicly available GitHub site, publish articles on our Knowledge Centre, and report on the progress of the project. The following are links that may be of interest.

Open Data Knowledge Centre (available here)

Open Data Master Plan project performance dashboard (available here)

Toronto Open Data GitHub site (available here)