Business Case: Lessons from software implementation which put head office directives before stakeholder needs.
This business lesson was learned at a US non-government organization (NGO) operating refugee camps and support services in East Africa. A few months prior to my arrival the NGO selected an accounting system to be implemented at all local offices. Instructions and software were sent out from the US head office, and my predecessor had been gamely trying to implement the new system but falling behind a little each month. We crossed paths in Nairobi as I was inbound to Mwanza, a dusty town on the shores of Lake Victoria. He was clearly stressed and anxious to be going home. What was I heading into?
NGO’s operate on private donor funding and from US government grants. Money was provided in US dollars and was spent in local shillings. Financial reports are provided in US dollars to the head office and for donor reporting, and in shillings for local authorities. Multi-currency accounting was not the cause of their current issue, but added complexity to the implementation.
The software was installed but a backlog of configuration work and data migration had been created and this was consuming the efforts of the finance office. Production of the donor reports were months behind and the NGO was at risk of losing or disrupting the funding to aid the thousands of refugees in their camps. Payments to local suppliers and workers were also in arrears as time had been consumed by the software change.
The new accounting system was rolled out by the head office to support a strategy for global standardization of accounting and reporting from their international offices. The implementation strategy could be called “out with the old and in with the new”. Use of the old system was abruptly ceased while the new software was installed, and production of the monthly donor reports would be resumed from the new system once the install and data migration was complete. There was no local planning for the initial rollout.
The approach of this paper is to use this business case to illustrate the benefits of applying business analysis tools and techniques to all software projects, regardless of size or location.
Planning– identify stakeholders and business analysis approach.
Always look for all the stakeholders. The NGO head office is a stakeholder in the Mwanza project, and they communicated a business need to achieve global accounting standardization. The funding donors are also stakeholders in the project. The rollout strategy was based on an assumption that the new accounting system was the number one priority for this local office – but donor funds are the life blood of non-profit organizations and any hint of not being able to account for how the money is being spent can cause delays or withdrawals of support. The number one business need for this Finance office was the timely and accurate production of donor reports.
Local workers and suppliers are also stakeholders in the accounting system. Timely reimbursement for labor and materials is needed to maintain the supply of both to run the refugee camps.
It is easy to overlook the need for business analysis in small projects, but this case illustrates the risk of implementing software without some basic analysis of scope and flows. A simple context diagram and stakeholder map would have provided a better perspective for implementation planning.
Requirements – identify all the functional and non-functional requirements.
The requirements given to the local office were:
- Install new software
- Migrate historical data
- Recreate reports
Recognition of additional stakeholders leads to the additional requirements –
- Maintain accurate and timely reporting to donors.
- Avoid disruption to the delivery of monthly donor reports
- Ensure consistency in donor reports
- Maintain payments to local vendors and workers
- Avoid delays of vendor and worker payments
Strategy – identify the business need, address that need, and align the change strategy within the enterprise.
The business need which dictated the implementation strategy was to achieve global accounting standardization. The missing business need was to maintain continuity of operations during the software change. A new strategy was required that gave equal priority to both needs.
Under the new strategy all work was stopped on the software configuration and data migration until the monthly reports and daily operations were up to date, then these were maintained in parallel during conversion and testing until a clean cutoff was possible. This was achieved within 3 months and there was no disruption to the NGO’s funding or local operations.
Create a Context Diagram at the start of the business analysis process then share this early and often with your known stakeholders to help identify what might be missing.
Identification of all stakeholders is key to successful requirements. Timely identification of all the stakeholders at the start of the project avoids delays and rework when new requirements are identified while development or delivery is in progress.