The use of technology by non-profits has rapidly evolved in post-pandemic times.
People see the value of it as a tool to create efficiency, improve productivity and drive results. Donors too are requesting proposals that have a strong component of technology into their programming to solve problems of poverty, inequality, livelihoods across all sectors.
There are attractive benefits to the use of technology, of course, like wider reach, scalability, innovation. Donors are also attracted to the possibility of getting high quality reports if technology is designed well in the program, and addresses problems of corruption and misappropriation if there are systems to foster transparency and accountability in place from the start.
Why you need foresight to deploy technology successfully
Whether global or local, all NGOs have been adopting or implementing ICT4D solutions to some extent to meet donor, as well as beneficiary community, needs. Such solutions demand time, resources and intersectional skills to make it a success. NGOs are not technology companies after all.
There are challenges at every stage, firstly with identifying and demarcating online and offline aspects of a program. Technology can quickly get very expensive in ways that may not be apparent at an ideation stage if the requirements are not clearly defined and understood by the people who are commissioning the technology.
After purchasing a new tool, you’ll need to customize it, improve it, add new features and support your teams with its adoption – all factors to be vigilant about when it comes to contracting as well as costing and pricing. Sometimes, what appears to be a simple ‘change request’ might turn out to be a complex task. Having strong technology and business skills in your team is then unavoidable.
Another area of impact may be contracts. Traditional ways of contracting are now challenged because one is compelled to include new negotiations concerning IT infrastructure components and their servicing, many of which may still be ‘new’ areas for the development sector.
What to consider when adopting a technology for use in your programming
Below are key points for you to remember if you have anything to do with implementing technology into programmes. Whether you are designing, costing, supporting, carrying out the work or overseeing contracts.
1. Insist upon “requirements gathering” right at the start
With multiple complex stakeholders and portfolio-based programming that involves several diverse implementing agencies, an aspect that gets frequently compromised is the user-requirements-documentation and community needs assessment.
An important question for you to answer: who gets to decide what purpose a technology must serve?
Often requirements get influenced by secondary factors, and with so many sources of influence, it is only natural for the requirements process to be distracted from the community end. However, a meticulously written requirements document will go a long way to ensure clarity and focus. Such a document should be published in the public domain for everyone to know what the community really wants, expressed in their own voices.
2. Make sure you have IT personnel who understand community-level challenges
Let’s say your program involves an app which captures citizen ratings of local services. Your team will need developers who are not only well-versed with technology, but also the core aspects of community monitoring. Knowing data entry problems will be as important as being aware of power imbalances. If the data entry for any reason is NOT entrusted directly with the community member, but is outsourced, then the possibility of compromise to integrity should be well-understood by your team. Such intersectionality will maximise your chance at success. Make sure you’ve understood the skillsets required.
3. Know the cost relative to the overall project
This can be difficult to answer. If you are looking at Software-as-a-service where a provider hosts everything and makes the solution available to community users, the price you are looking at could be all-inclusive. In other cases, there will be fixed costs, variable costs and service fees, which can be difficult to budget for
Finally, do you want to have in-house capability in the long-run, to manage the tool internally? If yes, start putting those resources in internally, so that from the beginning they understand how the design/development decisions are taken. Without costing this, true handover may be tricky.
4. Your leaders should envision ICT4D solutions as strategic asset
Rather than using technology in bits and pieces across multiple programs running the risks of silos, duplication and failure, a strategic outlook can help make your technology sustainable. Even when there is no donor funding for the continuation of digital technology, your leaders might find ways to allocate some resources for the maintenance and continuous dissemination of the digital technology to other similar projects for impact.
Innovation must be balanced. Experimenting for the sake of it should be avoided if it demands a lot from the community.
5. Use “do-no-harm” measures
How can you, as a program designer, ensure those participating in your programme aren’t harmed? Will passwords or two-factor authentication help? Or can we think of offline methods such as a common, safe, community place where they can use devices along with others as a group? In either case, it is clear that do-no-harm measures should be put in place.
Further, several studies have noted how technology can increase digital divide in society. It can also put power disproportionately in the hands of those who design or develop the technology platform or handling sensitive community data. It’s important to put measures in to prevent this.
6. Forecast and budget for costs of service, maintenance and support
Battery failures will happen. Electricity may be disrupted. Tablets may break.. All of this can disrupt your program, however perfectly designed.
Set up an IT Service Desk for all such incidents and budget for such support and service. Success lies in a lack of disruption to programmes. It is wise to have a system in place to help with any issues.
7. Contracting of Technology partners
When identifying a tool to use for your programming, if you decide against developing it in-house, it might be wiser to identify a partner who has a tool that has been tried and tested. If you are commissioning new technology, be clear, in the contract, who owns the intellectual property once the development and rollout is done and how you will carry out training and support to ensure every user is comfortable with the too.
Consider community rights of ownership if it has been developed with the beneficiary community. Put a system in place so that their rights to access are protected, regardless of project-closure.
8. M&E aspects of the tool
When implementing these tools, it should be clear from the ideation stage what kind of data will be collected and how it will be reported. The data to be collected should be aligned with the input, output and impact of the project to inform the key performance indicators. This will help demonstrate impact to communities and donors.
9. Donor’ commitment to digital principles, and not just the implementing agencies
Over 300 organizations and non-profits have endorsed the nine Principles for Digital Development, signalling that many feel the need to have a principled approach towards the use of technology. Donors can do a lot to facilitate the sharing of successful technological initiatives or reusing solutions.
For donors that often work with multiple agencies under a portfolio, checks can be put in place to make sure duplication of basic functionality is not occurring.