Are "Sustainable" TechDev Approaches Actually Hindering Development Partners? A Mini NDI Case Study

Macedonia Office

My visit to Macedonia last week for the eDemocracy conference presented an opportunity to check in on a long term project that our NDItech team has been involved with since 2005 - a little Access database for tracking MP casework in more than 40 constituent offices across the country. I wanted to assess this project because the approach we used in providing ICT support wasn't in line with our general sustainability guidelines - we provided software built by our team in Washington instead of coaching a Macedonian consultant or tech firm to build the software - as our sustainability strategy would have preferred.

The thinking here is that locally grown solutions will be more appropriate to the conditions in that country, better supported, and that investments in local IT capacity and firms is good for economic and business development.

Therefore, we try to limit our DC-based software development to “breakthrough” type innovations or solutions that may be replicable in multiple countries. In addition to being good international development practice, we don’t see any other practical approach as it’d be impossible for a small team of developers to provide tools to meet demand (NDI has nearly 100 programs in 70 countries, with increasing interest in technology-powered programs). The casework tool in Macedonia was eventually replicated in several other NDI program countries - with improvements and customization at each iteration - which is the main reason we decided to build not buy in this case.

On the question of tech for development, our ICT team prides itself on employing sustainable approaches, and one of the most important debates we have for many NDI projects that come our way is a tech4dev version of the classic question:

Buy or build?

Impose tech from afar, or encourage home grown solutions?

Is it more appropriate for an international organization like NDI to provide partners tools designed to achieve their goals, build their capacity and increase their overall effectiveness? Or coach the partner through the process of procuring IT services locally, work with local software engineers, develop local IT capacity, and establish support relationships - even if the process may not be as cost effective, efficient or the final product as polished?

Give a man a several year supply of fish delivered to his doorstep so he can raise a healthy family? Or teach him to fish in local waters even if it will present him with additional challenges, take more effort and result in him spending less time at home with that family?

Our Macedonia program provided an excellent case study.

I had a great conversation with a former NDI staffer, Gezim Jashari, currently working for a Macedonian NGO and NDI partner called the Institute for Parliamentary Democracy (IPD). Gezim has had both experiences – running a program with software provided by our ICT team in DC, and also software developed by a local database developer. Gezim was willing to share his candid thoughts.

Starting in 2005, Gezim worked closely with our ICT team in Washington as we built an Access database that has since been deployed in over 40 small parliamentary constituent offices around Macedonia. The project lasted for a period of about 2 years while the software was planned, developed, deployed and "burned in" for a while. The database is still used in the offices, one of which is pictured above.

In 2006, Gezim contracted with a local IT company to build a similar Access-based membership tracking database for Macedonian political parties.

The requirements for both systems were similar in terms of complexity and were trilingual, and they were being deployed in similar types of small office, single user environments.

Here is what I heard:

  • The software development process was difficult in both cases. Building databases and other software is always more challenging, resource intensive in terms of staff time required, and detail oriented than expected. It usually takes longer than our NDI program teams and NGO partners would expect, and often costs more.
  • Gezim preferred the DC-based approach because he essentially had a dedicated programmer who was very responsive and flexible when requirements changed or details were overlooked. Other major differentiators were that the NDI ICT developer understood the program goals so that explaining the "why" wasn't necessary to ensure that the functionality met the need, and the fact that the ICT team was committed to success on the non-technical goals of the program and was therefore flexible to change requests that led to better outcomes;
  • The local developer had the advantage of better communication, as the teams could sit down together and work through functionality. However, this developer had no interest in the broader program goals, built only what was required, and was less flexible in terms of changes without talking about additional cost.
  • The multilingual requirements made working with local developers who spoke at least two of the required languages a benefit. However, the NDI developer built translation tools that made on-the-fly translation by NDI Macedonian staff very workable.

Gezim didn't see the value in building his capacity to outsource locally, but instead preferred the easiest solution to meet his program needs. It seems he viewed engaging with local IT vendors not as a capacity building exercise that strengthened the organization, but more as a chore that required more work on his part, taking away from the organizations core non-technical activities.

So in this case it seems that contrary to our general sustainable strategy, providing the fish resulted in a good outcome since the program was successful and the software is still running 5 years down the road. The technology solution seemed appropriate to the environment, providing support from DC hasn't been a big challenge in the last couple years as the software is stable, and the partner doesn't feel that they'd have benefited from going it alone with local vendors.

I wonder how widely that view might be shared among other development partners - should we be re-thinking our approaches about teaching partners to fish when it comes to building software tools? Are our best intentions of building capacity actually burdening our partners with non-core technical activities that hamper their overall effectiveness?

Hmm.