Tag Archive: ICT

During the Q&A session following Secretary Clinton’s speech on the Internet and freedom (previously discussed here), she said something that warmed my young heart: “We need the guidance of technology experts. In my experience, most of them are younger than 40, but not all are younger than 40.”

I was reminded of this recently when a colleague from a competitor firm bragged to USAID that his entire team was under 30.  His theory, which was greeted by sage nodding from the USAID delegation, is that most people who operate technology in South Sudan are under 30 and that their cultural deference to older people would make it difficult to create the peer relationships necessary to understand – and solve – IT challenges.  His approach was to take smart, young people who are interested in working in Africa and release them into the provinces of South Sudan with a laptop, a Sudanese colleague, and a boda-boda driver.  Good intentions, quick thinking, and the ability to quickly build rapport would win the day.

Deloitte’s approach (and the USAID approval process) prefers more experience.  For example, we are in the process of deploying a Financial Management Information System in South Sudan and our entire team has worked on similar problems for decades.  They have the grey hair to prove it.  There are manifest advantages to having a team that knows what it is doing: they remember what has worked (and failed) before, they understand the range of applicable solutions, and they don’t have to reinvent the wheel.  In this model, subject matter expertise, the ability to anticipate future challenges, and gravitas carry the day.

These options are not mutually exclusive.  Successfully deploying a new system requires teams that include both members with significant experience and younger members for whom it will be easier to connect with local IT staff.  (This is also a great way to get analysts and consultants out of the home office and into the field.)  While every project requires a different mix of capabilities, I think that the right team can be formed based on the following principles:

Understand the Audience. I am uncomfortable arguing that age alone determines the ability to forge successful relationships, but I think that it is a factor.  The guy in the server room, the computer operator, and the analysts (i.e. the people who use the technology) are young.  The managers and the political leadership (i.e. the people who make decisions about the technology) tend to be older.  Understanding this dynamic and structuring project teams to effectively work with this range of technical capability and leadership experience, is important.

Furthermore, as part of our efforts to build capacity, it would be incredibly valuable to match junior-level IT personnel with junior-level advisors, just as we match senior policy makers with experienced practitioners.  The IT environment – its security, reliability, and accessibility – has a huge impact on our ability to deliver effective solutions.  Mentoring the guys in the server rooms and working with them to provide a better infrastructure could be multiple the impact of the project.

Understand the Technology. The public sector in emerging markets tends to have limited infrastructure and technical capacity.  While deploying a client-server (or even a cloud-based) architecture may be the preferable long-term solution, this approach requires whole-scale modifications to the operating environment.  These modifications are costly, complicated, and chancy.  For example, a 2006 survey on eGovernment in developing countries found that only 15% of implementations were fully successful.  Today in South Sudan, the government relies on a primarily paper-based process for recruitment, appointments, and payroll.  Admittedly, this process is inefficient, inaccurate, and inflexible, but it still exists 60 years after it was implemented by the colonial government.  

While I disagree with solutions that reduce everything to an Excel spreadsheet (much less paper), simple prototypes that can be designed, developed and deployed quickly can be more effective.  Designing these prototypes requires a deep understanding of the problem, but doesn’t require extensive technical skills.  Deploying staff that gravitates to the simpler, less disruptive and (potentially) longer-lasting solutions can help implement technology that is more sustainable over time.

Understand your Goal. eGovernment systems achieve multiple goals: they streamline (and sometimes create) processes, they improve data quality, and they allow governments to perform new services.   They require inter-disciplinary teams that are able to understand the regulatory environment, improve the existing business processes, develop systems, and provide training on the solution.  If you think about these projects as purely technology – or, worse, structure your team with only technologists – you will be less likely to succeed.

I have no clue whether this broad scope means that teams should be younger or older, but I think it is a powerful argument for diversity.  Technology projects demand teams with varied competencies and (some) of these skills can be best provided by younger staff.


On Saturday night, in the mess in Juba, the members of my project started discussing how best to use ICT to promote development.  Here’s my answer: develop platforms and encourage the local government and private sector to build on those platforms.

Platforms provide a common infrastructure, accepted standards, a consistent governance structure, and established service expectations.  Platforms can refer to computers or networks (the Internet is a platform) but also to a legal framework that regulates a sector of the economy or a microfinance program that provides credit to entrepreneurs.  It is a structure – occasionally physical, but also conceptual – that permits growth.  By articulating the rules of the road and building infrastructure that can be used by multiple stakeholders, development projects can meet the objectives of the donor while still creating space for local partners to pursue their own goals.

What would this look like in practice?

Common Infrastructure. In South Sudan, deploying an enterprise system faces three hurdles: limited local technical capacity, unreliable electricity, and inadequate connectivity.  Currently we address these problems in the context of our individual projects.  We deploy generators and V-Sat connections at each project office and Ministry.  When the Bank of Southern Sudan decides that it wants to allow local banks to make electronic transfers, it constructs a microwave mast.  When the Financial Management Information System project needs a local database administrator, it offers specialized training.   When the Human Resources Information System team wants to overcome the absence of connectivity in the regional States, it updates the system design to accommodate asynchronous information exchange by placing files on solid-state media such as CDs.  In each case, the project team adopts the most efficient solutions to its specific problem, but holistically this eliminates the incentives within the broader community to coordinate efforts and enjoy economies of scale.

By designing a single, comprehensive network and identifying technical competencies that can be used on multiple projects, we would be able to develop products that don’t rely on ad-hoc solutions and specific personnel.  In addition, by opening this infrastructure to the broader community, we could provide the scaffolding that other projects and local firms can use to build their own solutions.

Accepted Standards. The proliferation of technologies and standards, an unfortunate byproduct of ad-hoc infrastructure development, saps resources and prevents the deployment of scalable solutions.  In Juba, for example, there is limited interoperability between cell phone networks.  Beyond the inconvenience and expense of requiring people to use multiple cells phones, the competing options undermine the provision of new services such as m-banking.  By clearly articulating technical standards and ensuring interoperability between solutions, we will lower the barriers to entry and make it easier for local firms to take the initiative to provide services.

In addition, the adoption of standards serves as an auto-catalyst, accelerating the effects of incremental improvements as their benefits compound overtime.  For example, by employing data-exchange standards for financial transactions, we can connect the payroll system to the financial management system and ensure that they work seamlessly even if they were not originally designed to be interoperable.   Standards allow independent teams to build small pieces while making sure that the larger puzzle fits together.  They make sure that our solutions are flexible enough to adapt to future problems that we cannot imagine today.

A Consistent Governance Structure. Successful platforms attract a range of users and these users must be confident that the platform will not suddenly disappear under their feet.   Common infrastructure and standards require management that is accountable and transparent.  They require operational teams to conduct maintenance, compliance committees to provide oversight of the standards, and administrative ownership to ensure a reliable funding stream.

In the developing country context, a governance structure must be strong enough to maintain the existing investment and flexible enough to adapt to unforeseen developments. It is not enough to deploy hardware and hope.  Deploying a structure that engages local government, private sector, and the development community will increase the likelihood that the platform attracts users and provides benefits into the future.  It also increases the likelihood that the platform can adapt and become a sustainable asset for the country.

Established Service Expectations. Organizations build their own infrastructure due to a limited market for ICT solutions, a lack of confidence in the quality of services, and then absence of information to price offerings.  This leads to a situation in which each ministry and project creates its own infrastructure that is expensive and frequently inadequate.   In addition to the cost, this dynamic creates variance between the capabilities of different organizations and creates new obstacles to designing solutions that can work in multiple environments.

Service expectations specify the reliability, speed, and cost of a platform.  They allow multiple providers to emerge while ensuring that each provider adheres to a minimal level of accepted performance.  Over time, this will lead to a competitive marketplace that can provide basic ICT services to the government, the donor community and the private sector.

By promoting a common infrastructure, accepted standards, a consistent governance structure and established service expectations we can create an environment that leads to accelerated growth in ICT.   This moves beyond our current efforts at deploying specific systems and would help create a sustainable foundation on which our partners can build.