When Nandan Nilekani and Srikanth Nadhamuni started eGovernments Foundation in 2003, their focus was to use technology to improve urban governance: to decrease the friction in transactions involving the government, improve transparency in the system, and increase the efficiency with which services were delivered to citizens.
15 years ago, egovernance was not a term that people knew or understood; but the founders believed that technology could help local and state governments achieve the above goals. Since then our journey to scale—450 cities, six state governments and four crore citizens—has been winding and uneven, and dotted with challenges and learnings. We’ve had to change our approach, and pivot our business model several times, so that we could stay true to our original goal of improving urban governance.
Based on those 15 years, here are some lessons on how to scale while working with the government:
Lesson #1: In the beginning, go for depth not breadth
We started in Karnataka, in smaller urban local bodies (not Bangalore), and initially the focus was on generating revenue for the government bodies—property tax, water, sewage—and addressing public grievances.
We spent time on the field, addressing 1,500 revenue officers saying ‘this is how you go and assess property, this is how you assess tax, this is how you build rules’. It was as basic as that.
[quote]We needed to expand our understanding of the entire governance mechanism.[/quote]While doing that, we soon realised that if we wanted to cover big cities, we needed to go beyond the four to five applications we were using, since a metro needs more than the basic revenue modules that urban local bodies (ULBs) can make do with.
We needed to expand our understanding of the entire governance mechanism and build for that—workflows around financial activities, asset management, equitising tax management, works management payments to contractors, and so on.
But the question soon became, how do we go beyond a city? How do we scale?
Lesson #2: Applying for government RFPs doesn’t work for nonprofits
Requests for Proposals (RFPs) can be a hit and miss. We won Chennai via an RFP but despite it being a success, when the state-wide RFP for Tamil Nadu came out after four years, we didn’t win that.
For a nonprofit there is a lot of uncertainty in the RFP process; since there are other forces at play, you don’t know when you will qualify and when you won’t. As a nonprofit, you can’t build a sustainable business model around this approach.
Related article: Scaling: How to go from x to 10x
Lesson #3: You need political will to scale
For us, the first point of scale came in 2015, when Chandrababu Naidu (Chief Minister of Andhra Pradesh) saw the work in Chennai, and wanted it to be available to the citizens of AP. Because of his backing, we won AP as a state, our first state-level win—the whole state, on one platform.
[quote]It is important to have sponsorship both at the political and bureaucratic level for your programme.[/quote]We’d had learnings from having worked in cities like Chennai and Nagpur, but to make the technology work across a state, we required existing processes and systems to be standardised. This is usually not the case with most states as different ULBs have different systems. But because the project had the backing of the CM, the bureaucrats changed the rules and processes to make sure that they were standardised across all the ULBs.
This was key for reaping the efficiency benefits of technology; if we had to customise the technology for each ULB, it wouldn’t have worked. It is therefore important to have sponsorship both at the political and bureaucratic level for your programme.
Lesson #4: Ask yourself: Will the change you are driving make people’s lives easier?
When it comes to changing or putting in a new system, the government isn’t any different from say, a private sector bank. Adoption of new technology stands a chance only if it helps the employees directly.
A government employee usually spends 30-50 percent of their time looking for files. When they get the file number, they go back to the physical files, and search for the information. With a tech-based system, they just have to type the file number to get the required data.
One of our applications also showed employees their daily task lists. Officers knew what they had to work on every day and were able to prioritise that work. Ultimately everyone wants to do a good job and a system has to help them do that
When the new system was evaluated by a third party, it showed that employees saved 19 hours a week, and that the citizens’ confidence in government had gone up by 79 percent.
Related article: Societal platforms: Re-imagining development
Lesson #5: Make the solutions open source
When we initially made our code open source, we didn’t see much uptake. Nonprofits didn’t have the ability to build on it and commercial entities didn’t want to work on it because they wanted to charge the government for the projects they undertook.
Picture courtesy: Wikimedia Commons
The concept of open source only worked when it was presented to the government. Senior officers realised that if it was open source, they could determine how the system was built.
[quote]Other large systems integrators set up monoliths that work in silos and create barriers to data exchange.[/quote]This was in contrast to other large systems integrators, who, when working with the government would set up monoliths that worked in silos and didn’t ‘talk’ to other departments or municipalities. They created barriers to data exchange, which made it harder for the government to align their systems or change them if they needed to. The government though, preferred an open source model because it gave control back to the government.
Lesson #6: Align yourself to government sector incentives
It is a myth that the government doesn’t have incentive systems; theirs just happen to be different from those in the corporate world. Recognising and aligning with these incentives makes it easier to manage the engagement.
Everybody wants to do a good job, but visibility is important too, as is personal accountability. An officer cannot just turn around and blame the city, the onus is on her as well; if there are 45 complaints against her, how many has she actually closed?
[quote]Everybody wants to do a good job, but visibility is important too, as is personal accountability.[/quote]This is why we built the system, so that officers are rated. The government is supposed to be accountable to its citizens and if there is one clear source of data, then there can’t be multiple truths and multiple interpretations about performance and results.
There was of course resistance, from existing power-centres, from entities with vested interests in having leakages—but once people see that this is how the government is going to operate, they align themselves with it.
Related article: The government as a partner: Making it work
Lesson #7: Simplify what you are offering; don’t build monolithic solutions
The traditional way of building a solution is to load it with everything. We tend to build in all services within one application. The problem with this approach is if you need to change something, the entire system architecture has to change as well.
If instead you build in a solution that is modular, you can pick and choose what needs to be tweaked, changed or removed. It allows the changes to be made quickly, which then makes the implementation cycle faster.
Take for example a revenue management services application: it has an assessment engine (where you assess based on the rules) and a separate billing engine, another one for collection, and yet another for payments). Because these are not dependent on each other, you can change one without having to change the entire code or hardware.
Another key element of this thinking is to help the government get up and running with a functional system that meets the majority of their needs in a rapid manner. When we looked at the data, we realised that 90 percent of citizen transactions and 80 percent of revenue came from a limited pool of services. By delivering these upfront, we helped the government achieve wide enough coverage, with the option to build more capabilities over time to cover the remaining 10 percent of transactions.
Lesson #8: Work with the government to help them leverage their own capabilities
When we take this model to government bodies we offer to train them, define what they need, create tool-kits for them, and generally handhold them for 12-18 months. After that it is up to them to either outsource it to somebody else or hire us on a commercial basis.
What this does it, on one hand it builds the governments capacity. On the other, it relieves the pressure on our team. Take for example, AP, where we needed 35 people from our team, versus Punjab, where we only have two people working because the state has dedicated 25 of their own people.
So, simplify the product, do it on cloud so that there isn’t investment and maintenance of hardware, create tool-kits (in the local language) that the government can use to teach themselves. Once this is done, they are ready.
Lesson #9: Change your mindset
We were so used to working in the trenches with the government, that moving away from it to thinking big picture and building platforms was a big change for us. We were used to solving problems in depth with large teams working on the ground.
Pivoting to become an ecosystem organisation was a big, hard-to-adjust-to change. We now have to think of how can we get different players on board to make urban governance better instead of thinking about how we can do it ourselves.
Initially, we would go wherever people welcomed us, but we have also learned to say ‘no’ now.
We have also learned to say ‘no’. Initially, we would go wherever people welcomed us, even if it was just an ULB. But now, we remind ourselves that unless it’s a state level conversation, it is not for us. Most importantly, internalising this new philosophy has to start at a leadership level.
Lesson #10: As your organisation strategy evolves, your team will also need to evolve
Until two years ago there was just one of us (Viraj) and one senior VP; the rest were all technologists and people who worked in municipal corporations. Today, we have built a product management team, a marketing team, a policy team. We realised that if we have to build the ecosystem, we need these capabilities.
A bigger team comes with changes in culture. In our case, because we spent a large part of our 15 years working in the trenches it was hard to let go of the idea that learning happens on the field. We also had to invest a great deal in organisation development to make some of this mindset change and allow skill set upgradation to happen.
We will continue to apply these hard-earned insights as we scale this open-source, modular, ecosystem approach across the country. There will however be much more that we will have to learn and unlearn on this journey of transforming urban India.
