What was the day-to-day like for DSTI?
The development of digital products for Sierra Leone includes a range of practical challenges that impact the day-to-day execution. Throughout this process, we have been fortunate enough to work with partners and service providers who are committed to improving the day-to-day lives of Sierra Leoneans. Even with this commitment, there have been several practicalities that have had to be understood and managed to improve the daily workflow and outcomes. Although there are similarities across both projects, there have also been unique complexities that have required special technical solutions to solve challenges. This entry will highlight challenges faced while initialising the projects, DSTI’s approach, and routine considerations encountered by DSTI in this project.
Project initialisation
In Sierra Leone, there are a limited number of tech companies able to deliver on the development of an MVP for the government. For those able to deliver (meeting technical and governance requirements) many saw the size of tender (circa 30k USD), too small for them. Additionally, many of the capable firms are constrained by a limited capacity to take on additional work. As a result, DSTI could only attract a few bids for the development of each product. All of this resulted in us securing a supplier for the NRA project but left us unable to attract a qualifying bid for the OARG project.
The OARG procurement process resulted in DSTI seeking the enactment of a sole sourcing mechanism to supply. Upon finding a suitable company, we then needed to convince this company to start development on a product via goodwill, as we followed protocol. Effective project management remained a challenge throughout the duration of the project for several reasons, related to this starting point. Due to the increasing cost of living throughout 2022, particularly around the price of rice (the Sierra Leonean staple) and fuel, firms were keen to negotiate favourable terms and payment. Agreeing on terms that support the supplier but also manage risks has been a challenge of note.
What was DSTI’s approach to supporting the development of the MVPs?
To support the completion of the MVP, the team at DSTI focused on six distinct areas to inform discussion and decision-making. These points are detailed below with the key related subcomponents included:
1. Product Discovery
– Understanding and defining the problem through context-specific research
– Identifying Stakeholders
– Calculating the value add and monetary savings products provided to end users, the ecosystem and the government
– Defining the product vision and mission
2. Product Planning
– Developing the Product Roadmap
– Developing the Product Requirement Specification Document
– Defining Product Success Metrics
3. Product Development
– Managing developer tasks
– Providing input on UI/UX designs
– Executing Scrum Master Duties
4. Testing Products
– Creating Test Scripts
– Testing features and documenting bugs and defects
– Exploring user experience
5. Support Product Rollout
– Developing end-user materials (user guide, troubleshooting manual, tutorial videos, etc.)
– Conducting training and onboarding of new system users
6. Product Maintenance until the end of its lifecycle
– Monitoring Success Metrics
– Providing data-driven product enhancement suggestions
Additionally, underpinning the guide for product development were two main values with which the organisation guides development within this dynamic context. Firstly, the human element specifically around human-centred design (solving a problem for our citizens) and secondly on providing an excellent technical architecture for a solution. By focusing on these two elements, we have personally found it easier to facilitate the development of solutions that are impactful for beneficiaries. These two main components do not act in isolation, influencing each other and the process to varying degrees, as explained below.
One of the first challenges we faced centred around developing an MVP that fulfilled the scope in a timely manner. To manage this, the team started by trying to identify, understand and manage the competing interests. One example of this included a request from the client to include an extension to the OARG search component, which included a paywall for users. Although relatively simple in principle to build, the integration of this module into existing payments of the National Revenue Authority (NRA) proved complex. Although the value add to this feature was clear, it was put in a ‘nice to have’ bucket due to resource constraints. By identifying and grouping features across both projects, the team was able to help stakeholders focus on the essential components needed to prove the viability of the product. Additionally, identifying this in the design phase also influenced how the respective development teams constructed the product, allowing the base architecture to allow opportunities for future additions. Ensuring all stakeholders bought into decisions remained a challenge throughout the entire process.
Related to this, the challenge created by time pressures was an ever-present consideration. Time related challenges are always a significant factor for any project, but they became even more significant within this project, due to complexities faced within the initialisation phase. Once the advertisement and procurement process began, it became clear that it would be a challenge to deliver by the agreed due date. Due to this, the firms selected started work after our planned initialisation date. Instead of completing their own in-depth needs assessment, the firms built upon the initial documents supplied by the OARG and NRA. This trade-off whilst essential also produced a grey area around project management requirements and responsibilities as contracts had not been finalised before firms started work, absorbing the risk themselves. Within this landscape, we found technical issues had to be resolved via a quicker-than-usual decision-making process. As a result, one of the key considerations from the project management team was to ensure compliance with the design specification without allowing project overrun. In short, although not ideal and not without consequence, the team was still able to facilitate the building of two MVPs which ended up being fit for purpose by keeping due dates at the centre of discussions.
As a consequence of the above and considering trade-offs and time requirements respectively, the product economics (for want of a better term) were also brought into consideration. Due to the relatively small amounts of money available to deliver the MVPs, the firm itself could not increase output beyond the limiting factor of human resources assigned. With respect to this, concessions had to be made as a direct result of the budget available for the project. Within this, the team sought to deliver the highest quality product with the resources available. To help achieve this, the project management team tried to make the correct decisions during the product design phase, by bringing in a range of our developers and product managers to lend specific expertise. Although this put pressure on other government projects, a particularly difficult challenge for DSTI considering the election was less than 9 months away, it was deemed a priority to help minimise future development costs. As always, the desire to deliver continues to drive the team.
By Kahil Ali