In late April 2016, I joined a team of Thoughtworkers to conduct an inception with the Ministry of Health of the Royal Government of Bhutan, a country whose population is significantly smaller than my hometown of Toronto. Though small in size, Bhutan is a role model in Universal Health Coverage (UHC), offering free healthcare for all. Despite being a role model for UHC, their processes are heavily paper-based, leaving the Ministry of Health to consider the systems of countries that are role models in digital health. Also, as a next step towards digitization, the Ministry is looking to implement Bahmni, an open source hospital information system, in their hospitals and clinics nation-wide. Going into the inception, we were aware that our methods would have to be different from the average Thoughtworks client. When we started the meeting outdoors due to a power outage, our hunches were further confirmed.
Inceptions are at the core of Thoughtworks’ approach to software delivery, and for a good reason - alignment. Alignment of vision amongst the stakeholders, of project requirements, of the path forward - inceptions encompass it all. We work across a variety of domains with a wide range of clients and for each client, our approach to software delivery is tailored, whether working with a global bank, a boutique retailer, or a social sector client.
Inceptions are used to surface differences between stakeholders, and help align priorities
Unlike many of our commercial clients who work in resource-rich and high-connectivity settings, our Global Health clients require practical, yet robust solutions - those that would work offline, work during power outages and work for users that have had minimal experience with technology. This forces creativity with traditional approaches. Our clients have little to no human and financial resources allocated to IT. As these resources are sparse, one approach we have used with Global Health clients has been to develop and implement reusable open source products, like Bahmni, which are adaptable to low-resource environments. Reusable products allow for a lower total cost of ownership, and require less customization and need for programming expertise as compared to fully custom solutions.
Due to the unique nature of our Global Health work, our approach to inceptions has to also be unique. Here is how:
Beyond Problem Solving to Product Thinking
In inceptions with our commercial clients, we often explore the problem statement with the lens of co-creating an answer to the question: what is the best solution for your requirements? In a Global Health inception, both parties recognize that an open source product is the best way forward; so the question we’re trying to answer is: how can we most efficiently and effectively adapt open source products to your requirements?
We need to go beyond problem solving and figure out the best way to match products to the requirements, because the alternative - extensive custom development - requires additional resources that our clients rarely have.
During our team’s inception, we visited Paro District Hospital and observed that the hospital outpatient services circle around one sheet of paper that the patient carries from registration to consultation to the pharmacy and then home. Problem solving asks: what can we build to make this process simple and efficient? Product thinking asks: what does this process look like in Bahmni?
Beyond Requirements Gathering to Requirements Validation
Observing the process flow from patient and registration clerk perspectives at Paro District Hospital.
Traditional inceptions are held in a large meeting room and begin with exploring the requirements of various individuals and groups. In a Global Health inception, we take requirements gathering a step further to spend time in the facility where the product will be implemented, because it is very important to understand the physical and social context in which the software will be deployed.
A large portion of our users have little exposure to technology compared to those working in hospitals in bustling, urban mega-cities. Additionally, there is ample research to suggest that “people make confident but false predictions about their future behavior, especially when presented with a new and unfamiliar design”. Therefore, it’s crucial that we spend time beyond the conference room, observing firsthand which processes could be enhanced and which would be disrupted by introducing technology.
While our team sat in the meeting room, we heard about the painful, manual processes for reporting and many requests to make this a priority. During our hospital visit, we observed doctors laying out and summing numbers from 4 or more different registers in order to fill out just one indicator for a report. Reports usually have over 20 indicators. This takes significant time and effort that could otherwise be spent treating patients. This observation greatly validated the need for strong reporting processes and gave us invaluable insights on how to best design for these needs.
Beyond Delivery Planning to Rollout Planning
One of the main outcomes of an inception is a roadmap. In traditional inceptions, the roadmap focuses on the design and development of the software - what features will we build for each release? With a product, the roadmap focuses on the rollout of the software - what features will we configure for this release? What is the process for releasing the software to a new ward or facility?
Global Health roadmaps go beyond typical planning for software releases. Our clients are usually making the shift from paper to electronic, so we begin by planning for foundational tasks like ensuring infrastructure is in place and conducting basic computer training for users. When planning for a national rollout, we weigh the pros and cons of piloting depth (various facilities in one region) versus breadth (similar facilities across various regions). We consider the environment in which each health worker operates and propose contingency plans for when the power is out, the internet is unavailable, or a backup is unsuccessful. These considerations go beyond the scope of most of our commercial clients.
On the last day of our inception, we wore the traditional dress of our client’s country to present our findings and suggestions on the way forward to the Secretary of the Ministry of Health. The Secretary began by recounting story after story of unsuccessful systems that the Ministry had implemented during his tenure - stories of open source software that brought about enormous support costs, of proprietary software that failed to pick up user adoption, and many more. It was a sobering reminder of the difficulties in successfully implementing software at scale and that what works in resource-rich environment cannot simply be implanted into low-resource environments.
The Thoughtworks team wearing the traditional dress of Bhutan - gho for men, kira for women.
With all this in mind, we continued with our presentation, presenting a user flow that would begin with registration in order to start capturing a longitudinal health record for each patient. We outlined details of the incremental feature rollout, exact infrastructure needs, and a training plan. By the end of the six days, we had everything we needed and everyone on board to get started.
There are an unfortunate number of examples of software being deployed in hospitals or clinics that never gets used, of hardware that collects dust and so on; we work with our clients to ensure that their systems do not become part of those statistics. We partner with our Global Health clients to find practical, affordable solutions that transform their care delivery, and work to empower our partners to take ownership of their systems. Our vision in building these partnerships is that access to quality health care will be a reality for the underserved.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
