Walter Haas, Application Lifecycle Management Advisor, SOS Children's Villages
Michael Kohlegger, Finance & Controlling Business Analyst, SOS Children's Villages
After a consulting project with Accenture in 2012, SOS Children’s Villages started to professionalize the practice of business analysis and develop a more unified approach to software projects. The project included the development of processes and methodologies and the training and internal certification of Business Analysts (BAs). Today, SOS Children’s Villages has 45 internally certified BAs, 50% of whom work in regional and national offices around the world.
The SOS Roadmap towards Business Analysis
How did the project come into being?
In 2010, SOS Children’s Villages International began to develop an organization-wide network of BAs and an Application Lifecycle Management (ALM) process to standardise the practices and tools that had been developed by various software projects over the years
The top priority of this development was to seek acceptance from both the business domain and information communication technology (ICT) realm. To achieve this goal, both business stakeholders and ICT staff were invited to become part of the project team. SOS also made sure the initiative was in line with established practices such as project and process management.
In 2012 the rising demand for software solutions and professional software requirements led to a second project supported by Accenture. The goal of this project was the improvement of a future-oriented, professional and effective software development unit at SOS. One key management insight of this project was that there was a high need to strengthen the practice of business analysis within the organization. To disseminate this idea, a presentation campaign was launched, attracting participation from over 150 staff. An image video was also created as part of the campaign to raise awareness among stakeholders: https://www.youtube.com/v/CR0LC2zpiqg.
How was the project implemented?
The actual implementation of business analysis practices at SOS Children’s Villages started in the same year, 2012, by defining the responsibilities of BAs within the ALM process. One major lesson learned in the early stages was that there are pitfalls to a lack of well-defined roles within the ALM process. In the second step of implementation, it was made certain that the roles of the BA (on the business side), the product advisor (on the ICT side), and the project manager were more precisely defined. The BA’s profile was clearly established and emphasised his/her professional responsibilities as (1) being located in and managed by the respective business domain, (2) being the link between business and ICT with good understanding of both domains, (3) being responsible for validation and verification of requirements as well as user acceptance (i.e., testing), (4) being responsible for product support, and (5) being well informed within the project and process landscape of the organisation.
The following roadmap illustrates SOS’s approach to implementing business analysis into its work:
How do ALM and the BA structure in SOS look today?
BAs undergo a multi-day training, followed by a certification, to ensure qualification for their professional tasks. This certification has been developed together with external partners (e.g. Zühlke) and has been verified against the guidelines of the International Institute of Business Analysis (IIBA). The ALM process itself has been assessed against CMMI standards.
Today, 45 SOS team-members are certified BAs. Half of them are located in Innsbruck and Vienna at headquarters, while the other half work in regional or national offices all around the globe. These regional or national BAs either work on their own local projects, or as first or second level support for global software systems.
Business Analysts at SOS Children’s Villages
Mission accomplished - value added?
The established ALM process enhances transparency and predictability in new software projects and ongoing maintenance work. Departments are now able to actively plan the implementation of their requirements.
Thanks to the new process, the productivity of the internal software development team was raised by 30%.
Developers can now focus on software development rather than defining requirements and providing support. In addition, change requests have been reduced by 30% as a result of carefully analysed and documented requirements. Software requirements consider the needs of the user and also focus on the business perspective. As a result, software solutions are more relevant and valuable for business processes.
Standardised tests and acceptance processes ensure that software is not only working (verification), but that it also full-fills user and business expectations (validation).
Processes have been defined and streamlined and communication between the business and ICT domains has been improved. BAs act as multipliers, strengthening IT literacy in their business domain.
Lessons learned and further improvements
While some departments have picked up the BA idea immediately, others have been slower to implement the new roles and processes and are subsequently targets of intensive marketing strategies. There is also a need to have one or two “pool BAs” that can stand in and fill the gaps in these departments that don’t yet have BAs.
According to the original methodology, requirements should be comprehensively defined and finalised before development starts. This is, however, rarely possible as development and requirement specifications often go hand in hand. SOS therefore needed to adjust some components of the methodology to enable an iterative, increasingly agile development cycle.
Typical high-risk projects with a major impact on important business processes can still follow a waterfall-like development process where requirement gathering is temporally separated from development. In contrast, change or innovation driven projects need to be handled more flexibly. Beside in-house development, the adoption of an agile methodology has a big impact on acquisition software projects as well – solving the legally motivated standoff between having a fixed price yet still developing in an agile manner.
Another major lesson learned is that – even if it is initially well defined – there seems to be a tendency to overload the BA role with too many responsibilities related to project management, process management, or responsibilities that need a certain amount of IT know-how and go beyond the experience of regular users.
Another insight from the implementation of BA roles and ALM is that educating existing staff on business analysis does not seem to be sufficient as a stand-alone approach; hiring new staff with BA experience proved to be highly “fertilizing” for the internal team, as in all other business domains.
Some BA responsibilities, such as formulating change requests or performing tests, need to be forwarded to software project team-members. It can be valuable to create a “light version” of the BA role to take care of these tasks. This is why SOS initiated “ALM light” training for project and support team-members, which was attended by 50 colleagues from different departments.
Establishing a new process and its professional environment can always bear the danger of “ivory tower syndrome” and become an academic discussion out of touch with the “real world.” It’s important to make sure the process is applicable and fits its environment; the responsible team should be continuously involved in “real world” projects.
An interview with Peter Ouma, Business Analyst for SOS Healthcare-Management system project in East and Southern Africa Regions.
Where do you see that BA knowledge can help solve specific NGO or ICT4D related software project problems?
Business analysis knowledge is a key skill to deliver results for NGO/ICTD4 related projects. The broad analytical skill set connects business needs and is supporting software, technology and programming resources for business decision making. Capturing the big picture, BA knowledge can help NGO/ICTD4D leverage technology investments more effectively and spend less to maintain them. BA knowledge will help in ensuring there is a cross-functional and reusable lens to solution design. The BA can connect the dots between stakeholders from different programs and between solutions across different technology systems.
How can business analysis help identify or measure the values of software projects, especially in the area of ICT4D?
The main result is lower risk and more cost effectiveness. Projects for ICT4D will be managed in an appropriate framework model based on good practices. Such a framework model can be an effective tool for communicating the required process of a software initiative, and helps define the roles who are working on ICT4D projects.