After my post on sustainability last week, I wanted to go for the next buzzword: scalability. This is yet another word that is in all RFP and in all proposals, but usually not very well addressed. So at least I can write down my thoughts, and see if I can get interesting comments.
Scalability is about increasing impact of a given intervention by expanding it, most of the time geographically, or at least in terms of number of people affected by the intervention. From my perspective, there are two quite different strategies that one can adopt to scale-up a project:
- Expanding footprint
This first strategy is about expanding the number of users of a given system. There are numerous examples of this strategy. E.g. mobile service few years ago: operators started in the capital cities then expanded to other major cities then to rural areas. Mobile money today in terms of value-added ICT services (VAS) is another example.
This model, in some cases, is essential for 3 major reasons:
- Sustainability (aka economy of scale): There are lots of systems and services that have relatively high running costs and that need to reach a high scale before they are sustainable. One example is hotline (e.g. farmer hotline service). See the graph below that shows that you need to reach at least 50.000 villages before breaking even (see details in a previous post I wrote about this case).
In such cases, there is no other choice to ensure a long term sustainability of a service
- Equal Access: The second reason to go for such a strategy is to ensure that the impact of a given service is able to reach all people in a given place (region, country, etc.). For instance, mobile service is providing enough social value that government pushes (through e.g. licenses) for countrywide deployment. This would prevent expansion or creation of a rural/urban divide or inter-regional divide in terms of development opportunities
- Impact: Some services are meaningful if and only if they are able to reach a big part of a population in a given geography. Best example here is mobile money. One of the key reasons of the success of mPesa in Kenya is the fact that Safaricom has 80% of the market share, allowing most of mobile users to exchange money between them. There are also other examples, like e.g. census operation, that by definition have to be country wide because it is a centralized process.
Obviously, such approaches have limitations. I believe that the maximum size of a given deployment is a country. This is arguable, but given existing regulations, given also that mobile operators are country-centric (different business entities in different countries), it is not possible to have a roll-out covering more than one country. When this is happening, it is usually two separate services replicated in different countries.
Such approaches also have some specific challenges. At least I see three challenges:
- Service hosting challenge
- Technical challenge
- Context challenge
About hosting challenges, as soon as you want to reach a high number of people, it is almost impossible to work without some kinds of partnership with an operator (see a previous post I wrote about partnership with mobile operators), or at the very least without a professional hosting infrastructure such as a data center. Making deals and adapting to mobile operators requirements is a challenge by itself particularly for relatively small structures. There is no other suggestion here than either learning from doing, or learning from others.
About technical challenges, this is one of the tough parts. Obviously, there is the basic purely technical part to ensure that a given implementation can support heavy traffic. This is easy, as far as you can deal with an IT professional that can help designing a robust architecture. The major difficulty, which is often overlooked, is how to engage new users.
The first thing, and this is obviously controversial, is a kind of mantra for me: rely on what is available in the field and in people’s pocket. Any deployment of hardware or infrastructure is just, imho, a no-go in terms of scalability. The problem is not really the cost of the hardware or the deployment, but it is the lack of an ecosystem that needs to exist to support any ICT appliance. E.g. mobile services: You have now in all town in all African countries people that are able to repair all the phones. You have people selling prepaid card everywhere. This is a working ecosystem. But it took time to appear and be setup. They are drivers of adoption of mobile services, and not results of the process. It cannot be top-down driven, and rely on entrepreneurial spirit. That’s why I tend to think that it is just impossible to centrally organize such an ecosystem building.
But even when one relies on what people have in their pocket, there is a huge challenge with is remote training. Having a pilot service in a small region where it is possible to talk to each user, train them face to face, etc. is relatively easy. Increasing the footprint means that such a face2face approach is not possible anymore. All the service training and the pitch to potential users have to be done remotely. This is really a critical element. How to integrate a new service without a face2face link presents also other types of issues such as trust building by users. How to create a trusted link with the users is another challenge that need specific strategies: using trusted intermediaries e.g. the mobile operators, or an advertisement on TV or radio with a well-known voice/actor, etc. There are lots of different ways to build trust, and it is not the purpose of this post, but it is again essential to integrate this dimension in a scale-up strategy.
Finally, the last challenge is related to the management of the context. A successful service is always a service that answers a specific need in a specific context. The context includes the culture, the language, the specificity of the area (e.g. type of agri products in a given region), etc. Obviously when a service wants to expand, it absolutely needs to take into account the change in the context, and the change in the service that must happen. In very very rare case, the service is generic: e.g. mobile money: exchanging money and goods is the same all over the World. But even in such cases, language is one of the dimensions that must be adapted. Here again, it is essential to have a fine-grained analysis of the elements that may change depending on the region, and adopt a strategy to take into account these factors and ensure that the service can adapt to it.
All these strategies to ensure that a given service can be scaled-up have to be defined and integrated at the very early stage of the service design process, and surely not after the pilot phase.
The second strategy is a totally different model of scale-up. Here, the principle is to reach a global effect by a sum of local ones. A given service is made available for replication by anybody who is interested. Then the proliferations of replication of the original service create a global impact. The best example for me is the Web: Few billions users, a global communication space, but through few millions small nodes. Everybody in his/her room can add a node, install a web server and extend the space. In the mobile & ICTD domain, there are quite a few examples: Ushahidi, frontlineSMS, Freedomfone, just to cite the famous ones ran by friends.
The key features here in the approach are: light-weight and low-cost solutions that are accessible individuals and small organizations. The objective here is to design a service as small as possible, as low-cost as possible that fits are specific needs.
The major strength of such approaches is the ability to reach high impact by small organizations. E.g. The Web (first Web server and first browser) was written by Tim Berners-Lee in his office at CERN. FrontlineSMS was written by Ken Banks in his room, Ushahidi was developed by a small team of people witnessing Kenya’s problems during 2008 election.
Such approaches, by enabling others to use the product (and sometimes extend it), prevent them to reinvent the wheel and just use what’s available. In order to leverage this effect, it is essential for the product to be open:
- Open license (aka free to use) so that people can test and use
- Open format: the service or product should be based on open standard, at least for input and output, so that it can be integrated with other products
- Open source: the service should, in the best world, be open source, so that users and adopters can extend it further.
Those three levels of openness are, from my perspective, sorted by importance, but all three are essential for a global effect.
This strategy has also a set of challenges that need to be taken into account. The first one is the definition of the service. The worst case in such approaches is when wrong expectations are raised from the re-user. It is essential to identify the context in which the system is supposed to work, as well as the exact service it is delivering.
The second challenge is the customization. Right at the design phase, the scale-up strategy has to be clear so that the product is designed in a way that it could be customized to adapt to specific context (e.g. multi-lingual approach, multi-operator approach, etc.). Here again, keeping in mind that the objective is adoption by a great number of organizations in different countries and cultures, the product should be able to adapt to the specificities and the varieties of contexts.
The third and probably biggest challenge is outreach. The success of this strategy is based on a large adoption by others. Outreaching to potential re-users is the key point for success or failure. Raising awareness is relatively easy. The hard part is convincing people to test the product. Obviously it takes time, but there are paths that are easier than others. In my experience, the best way to go is a domain specific approach (crisis management, agriculture, media, etc.). ICT platforms are usually applicable in multiple domains as they are developed to facilitate communications and exchange of information between people. However, those platforms are just tools to help solving problems. Mainstreaming mobile in operations is not a goal. It is obvious for organizations that are focused on development impact. It is far less obvious for organizations and people developing technology. They are usually trying to convince people about the intrinsic quality of their products that will solve all problems of the World. This is a very difficult exercise, particularly when talking to non-tech people. In my experience, you have to go the other way: explain in a given domain how a specific mobile or ICT tool can help solving a specific challenge of the domain. It is a mix of understanding the domain as well as using its references and vocabulary. It is often also not only a marketing exercise, but also the need to bundle a couple of other tools, or understand specific usage pattern that are relevant to the domain and that need to be implemented as shortcuts in the product. This is often the only way that people can understand how a given ICT tool can be useful for them, and therefore be convinced to try and integrate it in their operation.
Obviously, a given platform can be “instantiated” in different domains, without major change, leveraging further the impact. Here again, the half-dozen of frontlineSMS versions for different domains (aka frontlineSMS family) is an example of how a single platform can be adapted to specific domains.
I will stop here for now. I could spend ages on refining this post, but this is surely enough for now. Obviously, the two strategies I’m developing here are not exclusive. That said, given the objectives, they are radically different. Big solutions like designed in the first strategy are hardly replicable without heavy investments. Those investments can only be provided by major players (governments, big ngos, big corporations, etc.) and are surely not relevant to small NGOs. So those systems may be replicable but it is another type of replicability then the one described in the second strategy, which is focusing on low-cost lightweight grassroots approaches. In the same way, you can try to scale-up a small platform designed as part of the second strategy, but it is very unlikely that the design will be able to cope with heavy load and high number of users. Of course, there is a complete spectrum between the two strategies and it is always possible to be somehow in the middle.
To finish, my heart is definetly with the second type of approaches, but to be fully honest, they are cases where the first strategy makes more sense.