Government as a Platform: Rethinking government in Massachusetts.


Towards a Massachusetts 2.0
Governments everywhere are faced with increased complexity in delivering a good standard of service in the context of global challenges such as natural disasters, economic turbulence, climate change, trade wars, energy shortages and demographic changes among other factors. This has a bearing on the federal authorities as much as it affects state governments and the state of Massachusetts is no exception. In light of these dynamics, harnessing technology to deliver services to increasingly discerning state citizens becomes a necessity for efficient service delivery. This memorandum explores what implementing government as a platform (GaaP) in Massachusetts entails, criteria for deploying services on the platform and governance model for managing the service. I shall call this Massachusetts 2.0.

GaaP: What it entails for the State of Massachusetts & the Criteria for Deployment.
GaaP is one way Massachusetts can gravitate towards an open government. Open government enables the government to co-innovate with citizens, enable mass collaboration and networks the government with other system-wide stakeholders, building trust in the process. The underlying principle and philosophy behind GaaP is that government information is a national asset and that the information as well as a services must be delivered to citizens when needed. As suggested by Tim O’Reilly (1) , GaaP enables the government to be a convener and enabler rather than the initiator of civic action.

To move towards GaaP, the state will have to do work on a number of issues. First it must establish a set of standards. These are a set of rules that help anyone to develop any programs and applications that communicate and cooperate with the state’s platform, Massachusetts 2.0. Second, everything must be centered on simplicity. It means Massachusetts 2.0 must be stripped of elaborate features to a core set of minimal services so that feature filled innovations are farmed out to private innovators. Third, the platform must be open by default. This means that it must be designed to enable participation by anyone who can access the public data and use it for public good in line with set standards. Fourth, the platform and the state must make provision for mistakes and errors as various stakeholders experiment and play around with the platform. This means that citizens must not be unduly punished for mistakes as they experiment with public data, as Massachusetts 2.0 evolves. Sixth, citizens should be allowed, whether private players or non-profits, to mine data to extract insights and innovate around it in more ways than the state government can imagine. Seventh, and last, we can lead by example, by using the same standards to start deploying some services to show how far other players can go. In other words, we will be creating a public, sophisticated and far more liberal and open version of Apple’s App Store, which allowed the state government to collaborate with citizens.

Deploying Massachusetts 2.0.
The first step is to be to develop a comprehensive set of standards. To allow collaboration of the state with citizens, this can be triggered by issuing an executive directive to that effect by the Governor. This directive provides a framework within which the state can function and evolve under the clear direction that it is guided by open government. It is not necessary to recreate standards. Instead, the state can adopt and adapt existing open standards as well open source solutions.

The next step would be to build a simple platform that exposes the underlying data from the state’s systems. This entails ensuring that Massachusetts state internal systems are service-oriented. It is necessary to first audit this and improve it prior to exposing the underlying data.

Once the platform is set, the state can start deploying some of its services on the platform, to lead by example. The state was a leader in providing universal healthcare in the entire United States. One of the services that can be built by the state on the platform is a healthcare service. This would also allow other players to come in and mine data for various other applications and uses, in line with set standards. Other state-mandated services such as licencing, state taxes among others can be deployed on the platform.

Governing model.
Europe and other countries like China favor extensive regulation by the state to achieve what they call platform fairness (2). The state has a duty to regulate the conduct of citizens, natural or corporate. This is to ensure that use of public data and all public assets conforms to the set standards and is not contrary to good public policy. In the same vein, it important for the state to ensure platform fairness to facilitate and engender anti-trust monopolistic behavior in a manner that stimulates innovation and competition.

The governance model proposed is a consultative one, where a mechanisms such as a board, is facilitated through the Governor’s directive order. The board will have representatives of the private sector. The issue of control of servers in this situation becomes paramount. Given the public nature of data exposed by the platform, it is recommended that the state retain control of the servers, while ensuring that the consultative board collects all feedback from consultations to ensure the feedback is implemented promptly by the state.

In conclusion, the Internet is an open platform and its evolution has created immense opportunities to deliver more open forms of government that harness the collective wisdom of citizens. For the state of Massachusetts to harness that wisdom, GaaP is the way to go. Such a platform will ensure that the private sector and talented individuals can in multiple ways leverage public data to create service innovations that can change the state in ways unimaginable.

1. O’Reilly, T (2010). Government as a platform. 2. The Economist (2016). Regulating technology companies, taming the beast.  (retrieved on 2/10/2018)

Lean starting up and how to be agile: A lesson from the past.


Success is great. But failure can be greater, if you take the lessons! This is not to say failure is not annoying! It is annoying. Yet when you fail, you learn. You learn how to fail, and how not to fail. Better still, failure gives us lessons on how things should have been done, had we known better. Being in business school making armchair analysis gives you an air of invincibility, but getting into the actual act of managing projects, running a business or setting up one is a different ball game, which provides hard lessons. I call it a university of hard knocks. Here is a typical story of failure, from which I learnt lessons on what to avoid in my subsequent ventures. This account emphasizes two approaches relevant to executing projects, namely the agile approach, as contrasted with the waterfall method.

My first e-commerce project was in fact motivated by my business school research on retailing business models. At the time, Amazon was rising. So was Rakuten, the largest e-commerce business in Japan. The question on my mind was, why not explore that in Africa? I knew there were some known knowns, known unknowns and unknown unknowns in such a venture. For example, I knew the existence of retail businesses in Zimbabwe meant there were retail customers. I also knew there were no online payment options, and it was necessary to set-up one. I also knew there would be delivery hassles, among many others hiccups. In short, there was no e-commerce ecosystem. I was also clear about the business model to explore. I also knew I had to bootstrap the start-up, given lack of venture capital. But there were other things that were unknown to me at the time, the agile approach to executing such a venture. Had I known better, I would have executed it differently.

With my friend Mansour Ali, we mapped the project plan in his apartment in Fukuoka. After years of doing projects in banks, making sure there was a project plan prior to starting a new project had become second nature to me. Where is the project plan? Who is the project owner? Who is the project manager? What are the steps to the project? Which group of activities go first? What is the critical path?  These were key questions I sought to address first. It was all a silo and compartmentalized mindset acquired from previous experience running banking projects.

I was the project sponsor, Mansour was the project manager working on the platform development. I was to fund everything necessary, implement the project in Zimbabwe and lead the deployment, stakeholder management and business development. With hindsight, our approach was a typical waterfall approach: build the online marketplace, add as many features we deemed necessary as possible till it looks great, perform an internal test of the platform, then sell the platform to existing retailers so that they can sell their products to a broader audience online, find a payments solution and figure out how to execute delivery, then launch, and succeed!

The entire process took several months. It was complicated by the fact that we both had to work full-time on our other jobs. Mansour ran his other business while I worked separately elsewhere. It was worsened by the reality that he sometimes traveled halfway around the world to Oman, where he was developing a car exports business. Each time he traveled there, he would stop working on the project on account of internet controls in the host country. As the key developer and project manager, this caused serious delays. This complicated the waterfall approach we took as it took very long to launch the end product, an multiple merchant e-commerce marketplace. homepage

After over 9 months of working on the project, and an investment worth several thousands of dollars in time and money, we launched the online marketplace in the last quarter of 2014. We got fairly good media coverage in key technology websites and daily newspapers. At that point we had a handful of very good merchants in the country who signed up to run virtual stores on our platform, including a well established book publisher with a very rich catalog going back several decades. Getting merchants to sign up turned to be a complex task. It was a long pipeline that involved travelling across the country to make presentations to each of them. In each case, we had to explain the features and benefits of running a web-store. What became clear was that most of them vaguely knew about e-commerce, but had never thought about using the internet to sell their products. In general, they were not convinced they needed to have resources set aside to run a web delivery channel. This started creating several unknown unknowns we had never factored in our waterfall development approach. Though we got some merchants to sign up alright, the biggest unknown unknown was that we had to do much of the work ourselves because merchants neither had the time no human resources to either update their own catalogs or processes deliveries. This left us running from pillar to post to cover all the gaps. The work was tedious. Finding a delivery solution was also not easy. Fortunately, unlike other African countries, like Nigeria, Zimbabwe has an effective postal address system. We therefore partnered Zimpost (the national postal service), which delivered packages reliably at a low price. The price was low at the beginning, but was changed upwards a few weeks later. We did not have enough critical mass to negotiate the price downwards. All these dynamics were unknown unknowns.

After a few months working on the venture, it became obvious that we were bleeding money. Mansour was getting disillusioned. It became clear that we has to scale down the project. And we did. It was not necessary to continue bleeding more resources. marketplace

The question is what should we have done differently. It became clear several months later that Zimbabwe was just not ready for e-commerce. What were my assumptions, that made me proceed anyway with the project in spite of all its blind spots? I had proceeded because I believed that Henry Ford’s quip, “If I had asked people what they wanted, they would have said faster horses,” would be turn out true in our case. So we did not engage the market as we as necessary as we proceeded to implement our solution, at a huge cost.

Yet we could have done things differently. How? Had we been more agile in our deployment, we could have seen sooner, at far much less cost, that there was not much light at the end of the tunnel. How? Had we followed the agile lean start-up approach, we could have tested our idea before proceeding all pistons firing to implement it. We could have tested our assumptions and hypothesis first by engaging merchants/retailers to assess their appetite for online delivery channels. In addition, we should have sampled potential buyers first, to validate our assumption that they would somehow use the solution. We knew that buying anything online had not grown on our potential customers, but we assumed our efforts would change their behavior. We should have validated those assumptions through an agile approach. What else could we have done? Had we established some level of appetite from customers and some merchants, instead of spending months building a fully fledged multi-merchant e-commerce platform, we should have built a thin minimum viable product off commercial templates to prototype and validate our assumptions. We could have done this by setting the prototype platform one one merchant to gauge the potential interest from consumers.

As it turned out, we did not, at great cost in terms of money and time. Lesson: always implement any venture or project in agile fashion. Validate your assumptions, figure out how to prototype and deploy a minimum viable product, and be sure its worth proceeding before investing huge amounts of money that are irrecoverable way later. 

Hello world!


Welcome to my Weblogs at Harvard.