by Thomas Behrens, Thomas.Behrens@endava.com
Introduction
The number of outsourced distributed software development projects increases continuously. During the set-up of these projects, we tend to focus on the developers and testers, less on the business analysts. The risk of failure resulting from inappropriately managed requirements (and their owners) for these projects is as high, if not higher, than their locally-delivered counterparts. Agile trends move the emphasis from written to verbal communication. While desirable from different perspectives, it complicates matters further.
The consequence is that distributed outsourced software development projects usually do not leverage the capabilities of a business analyst effectively. Why is that so? What can you do?
Why do distributed outsourced projects not leverage the business analyst?
Let us look at a simplified, but usually typical, structural set-up and the resulting flow of requirements in such a project.
There are a few observations to make. Usually the role of the Business Analyst is kept with the outsourcing organisation (“outsourcer”), whereas the service provider provides the developers and testers. The IT / implementation independent business knowledge is often viewed as a competitive advantage, which the outsourcer wants to keep in-house. The organisational boundary is well-defined. The geographical boundary usually coincides with the organizational boundary, but it can be softened through mutual visits or secondments for specific stages of the project. This depends on the distance and is easier for nearshoring than for offshoring projects. The proximity of the Business Analyst to either the “Business” or “IT” depends on the organisation and the type of project.
Written and verbal communication is the traditional medium used to convey requirements, context and rationale from the business to the developers. Geographical and organisational boundaries from the outsourcer – service provider relationship require additional focus on this communication flow. The increase of agile or hybrid methodologies puts more emphasis on verbal communication. However, verbal communication across organisational and geographical boundaries is even more challenging than verbal communication with collocated teams. The business analyst role is most affected by this challenge. The role may be called Product Owner in agile contexts, but that does not reduce the exposure difficulty of achieving effective communication in this situation.
Organisational alignment between the outsourcer and the service provider often overlooks the business analyst or at least ignores options for a better integration and set-up. The reason is that most organisations look at the business analyst as a role. If you look at the entire value stack of the business analyst it ranges from understanding the unique characteristics of the organisation for whom the product is developed, covering processes, systems and stakeholders at the top, via business domain knowledge and expertise to the business analyst’s core skills, as promoted through the curriculums of the IIBA, BCS or IREB. This latter set of core skills can be further broken down and allocated to either the outsourcer or the service provider team.
Only a few organisations ask – or are asked by their service providers – questions like the following:
- How much business domain knowledge does the team at the service provider require and how frequently? How can this domain knowledge be made available? (There is a significant difference in the demand for domain knowledge in the case of a structured derivatives trading platform, compared to an e-reader device.)
- Can the outsourcer’s internal business analyst cover the additional communication overhead? Does this align with his or her personal strengths? As more communication – and discipline to communicate – is needed, does the business analyst have the capacity?
- Who maintains the backlog and ensures the quality of the backlog? Is the business analyst (Product Owner) experienced to do so? Does he/she have the time? Is this covered by his/her understanding of the role?
- Due to the nature of distributed projects additional requirements related artefacts may be needed, e.g. in agile SDLCs to supplement user stories. Who is responsible and accountable for those?
- Are the right business analysts involved? If you engage business analysts, used to being involved in strategic thinking with senior business stakeholders in detailed solution driven projects, disappointment and lack of engagement is inevitable.
- What are the communication interfaces between the two organisations? How are these managed? Who manages the stakeholders?
What can you do to improve the role of a business analyst in distributed outsourced projects?
Start with asking questions like those in the list above that are related to the flow of requirements and the capabilities of the individuals. Answer them honestly to the best of your knowledge. This should provide a good basis to define the right organisational boundaries between the outsourcer and the service provider.
Consider the specific delivery model (software development lifecycle) and project specific challenges, such as size and complexity. Look at the details! Although Scrum should be Scrum, the way it is embedded into different organisations can have wide-ranging impacts on aligning two organisations. Consider as well the need for business domain specific knowledge and an understanding of the outsourcer’s organisation. Based on this knowledge, derive the implications for the business analysis process. Define which of the skills (not roles!) you need and ensure they exist in the overall composition of the team(s).
Be prepared to step away from a set of pre-defined roles (such as System Analyst or Product Owner) and define the demand based on specific business analysis skills required (“core skills”). Look beyond those business analysts core skills (Figure 2) at the first two layers and agree which information can be communicated across the organisational boundary on demand or must be present in the service provider’s team. In small efforts, a multi-skilled software developer may well exhibit those skills and therefore be the answer to the problem. In other cases, you may need a dedicated person as part of the service provider team to act as the local (to the service provider’s team) source for business domain knowledge and to maintain a holistic view of the requirements improving the overall communication. Ensure that the expectations on the individuals are managed and they are capable and motivated to perform those activities.
With increased scale and complexity, additional challenges of a quite different nature arise that impact the business analyst. You must address those. Here are two examples: Scale may lead to functional dependencies across different teams that need to be managed. Complexity can arise from establishing continuous delivery, requiring additional teams with new demands to be integrated into the overall process. This does not only lead to additional communication interfaces to be managed; it adds the need for new skills to the business analysis portfolio of that project, e.g. the skill to partition requirements in the case of multiple teams or the support for test automation in the case of continuous integration.
Summary
The role that is most “distributed” across the organisational boundaries in a distributed outsourced development project is that of a business analyst. In order to effectively leverage the business analyst stop thinking purely in terms of roles. Identify skills that are needed or missing and where they are placed best in the combined organisation of outsourcer and service provider. Be prepared to adjust when necessary!
If the outsourcer and the service provider collaborate to solve this problem by fine-tuning the skills and responsibilities of business analysts, further benefits will arise on both sides. Knowledge transfer about the outsourcer’s needs, organisation, systems and processes to the service provider will result in an improved understanding. Over time, the service provider will be able to add business value beyond the implementation of solution driven projects. Business analysis skills are essential to this evolution.
Author’s Bio
Thomas Behrens is Group Head of Analysis for Endava (www.endava.com). Thomas has held different positions and roles in the software development life cycle for various organisations over the past 25 years since having earned his degree in computer science. He worked in the domains of investment banking, telecommunications, mobile payments and embedded systems. Over the past two years, he focussed on setting up distributed software development teams mainly in agile contexts and shaping the business analyst force at Endava. Thomas delivers training and speaks at conferences on topics related to requirements engineering.