Reflecting on the SPARK project

Share on facebook
Share on google
Share on twitter
Share on linkedin

SPARK has the ambition to become a data driven and future proof organisation. Implementing this ambition supports them to increase their impact and accommodate their growth. The first milestone was reached with the Go live of the new financial and project management applications. D4D has been a strategic advisor to support SPARK in the implementation of this transformation process. Nikolaos Koufos SPARK’s Monitoring, Evaluation and Quality Assurance Manager expressed his experience working with our CEO Maaike Blom: “She has profound knowledge of the aid sector and is a proven IT expert, which is a unique combination and highly valuable to us. D4D strategically advised the project in terms of its quality and risk management, so SPARK was able to get the most out of this organisational change!”

Now that the Go live of the new applications has been completed, we would like to take this opportunity to reflect back on this period together with Maaike Blom and learn from her perspective. 

You have been supporting the SPARK Foundation as a strategic advisor, can you briefly introduce the project and explain what was expected from you in this role?

SPARK had decided to replace their finance application and introduce a new project management application. The project is called ‘the IT backbone’ because they also needed to update the general IT infrastructure to be futureproof and better fit the new applications that they had selected. SPARK asked me to be a member of the steering group of this large and impactful transformation project, based on the experience of D4D with such projects. My role was to keep an eye out on the possible risks and issues they might overlook during the implementation and to provide advice on all types of specific documents, policies, etc. in the course of the project.

Can you describe the involvement of the SPARK Foundation and their carrying capacity during this project?

SPARK had installed a steering group consisting of the operations director, the finance director and the project lead who is also their Monitoring, Evaluation and Quality Assurance Manager. The project lead had a support team of a functional application manager, who had a more data related background and an IT team that supported the required changes of the general IT infrastructure. Also two internal project teams were appointed, one for finance led by the finance director and one for programs led by the project lead with representatives of the respective departments. The internal project teams were co-responsible to ensure that the applications would be in line with the organisation’s work and fit for purpose. As external advisor, I joined in at the steering group meetings where the strategic decisions were taken to make sure that the total transformation would stay within the envisioned time, scope and resources. 

What are the expected business benefits of the project?

The expected business benefits are that the organisation will automatise the key organisational processes, have a single source of truth and one place to go to for holistic program management. For the finance application, SPARK decided to delegate more financial responsibility to the regional and country offices to facilitate a decentral organisational model, in order for the local offices to manage the finances of their own projects and be less dependent on the head office. For the project management part, one of the benefits is providing up to date information about the budget versus the expenditure as well as the general progress of the project. Further, the project staff from all offices is now able to manage the projects under their responsibility in the same manner: the subcontracting of partners, the result reporting, the donor reporting etc.

Have these business benefits been realised?

In September SPARK was able to go live with the new applications (project management and finance), staff has been trained and data has been migrated. But the actual benefit of the project and if it’s going to work out to increase efficiency still has to prove itself because it is only now that all staff starts working within the new set up. 

A baseline survey was done at the beginning of the project about expectations. The results of a second baseline report will need to show if expectations have been met. Of course now that it is easier to find all the necessary data on a daily basis, it is easier to execute the key approval process and track program progress on a continuous basis. This is already beneficial and proves the success of the project. But it is a bit too soon now to claim that all expectations have been met, even when the project until now has achieved what it should have achieved within the planned time, budget and resources. 

What problems did you encounter while working on this project? How did you solve them?

One of the very interesting challenges (not just for SPARK, but for many other development aid organisations) is matching the reality of the finance reporting for your annual account and the project management for your donor reporting. These are two perspectives on the same reality, each following its own logic. On the one hand, the organisation needs to make sure that its finance administration is run in a proper way, following the accounting principles. On the other hand, proposals have been sent to donors whereby the budget as well as the reports follow the logic of the donor’s requirements. It is always a challenge to combine these two and align it into one aggregated annual accounting report. The reason for having the integration between the finance and the project management was that SPARK wanted all program staff to have access to the basic financial information of their program and not to be dependent on the finance people and their financial applications for that information.

The integration was the most challenging part of the project and still has not been completely finalised. Most of the delay has been caused by different interpretations and unclarity on what was to be implemented where exactly. Also the finance staff was in fact implementing a new application and a new way of working so they could not yet know all the ins and outs of the new set up. The problem remains abstract until you find out that actually making it work the way you had it in mind is more complex than you had anticipated. 

Not everyone within an organisation welcomes change, especially if this means they have to change to working with an unfamiliar system that can take time to adapt. How do you convince these users to embrace change and successfully transition to using a new system? 

In the context of SPARK the appetite for change was quite big, many people for example were very eager to participate in the testing of the applications. Also the training sessions had a high attendance and were valued very positively. In general the change was welcomed by most staff as also the baseline survey showed. In reality, the actual level of adaptation still has to prove itself when people start working in the new reality for a longer period. That is when they will perceive it as helpful or not. The fact that the project was really put high on the agenda and that the SPARK staff was highly involved (directors, finance & project managers, project & finance staff etc.) contributes to the chance that the adoption will be smooth. If you want such a large change to happen successfully, continuing to inform and involve people along the way with all the steps that you take is extremely important. Again, I think SPARK did this quite well, and it should contribute to the eventual success of the adaptation.  


What is your advice for organisations seeking to undergo a similar transformation process?

My advice would be to think out the project properly before you start. Often organisations focus on selecting the application without spending enough time on how they are going to implement the full change in the organisation and what impact it will have on their daily work in terms of time and resources. The tendency is to under budget and to over expect. Take enough time to think out the change from beginning to end, set up your governance properly, make sure you have enough resources. Not just in terms of funds, but also in terms of making staff available to participate in the project (project lead, project team members, testers, trainers, supporters, key users etc.) and ensure that they have enough time to do so. Securing involvement has a significant positive contribution to the level of adaptation of the application that you are going to introduce. I also would like to stress that it is very important to guarantee that the change is about the people and the processes of the organisation and not just about getting the technology up and running. So invest enough time in training people and supporting them when they start working within the new set up. And don’t forget to streamline your internal processes and procedures with the new existing reality created by the new applications. The step that the organisation has to actually change its way of working according to the new reality, is often underestimated or not sufficiently taken into consideration.