Business Analysts in a Multi-Vendor project set-up

It is not advised to put all your eggs in the same basket. Big Businesses abide by it.

It has been a common practice for large organizations to engage in multi-vendor set-up, for 2 primary reasons one is to defer the risk and two is for niche capabilities for a large technology portfolio. While on one hand, the key to substance and growth for all technology partners is to ensure excellent customer success thereby increased customer reliance. On the other hand, they always run a higher risk of losing the Business under non-performance, financial viability and other such issues. Honestly, to work in a multi-vendor set-up, does keep you on your toes for making a project an exceptional success which is the only factor desired, appreciated and valued by the customers. However, it can lead to several other challenges as well. Let’s talk about two of the preferred benefits which customers look for, Productivity and Transparency. However, there are constant concerns of information hide-outs and lesser coordination among the teams because the vendors become competitors.

As a Business Analyst, you are most likely to face the challenge of coordinating with multiple teams, inside and outside the organization and need to make sure the requirements are conveyed clearly with non-recurrence and non-violation. The fact of the matter is, coordinating with the people in your organization even though cutting through geographies, is much easier than dealing with people sitting next to you and belonging to a different organizational set-up. This is one of the most challenging situations which a Business Analyst may need to address and it becomes difficult to juggle between different issues at hand or priorities. There is no thumb rule or any prescribed right or wrong way to approach these kinds of challenging situations and deliver the Business Value.

As a Business Analyst, while working in multi-vendor project set-up, there is a constant need to categorize your attention and recognition to certain areas of Software Life Cycle, some of them are -

1. Keeping the independent work logs –

While detailing the requirements in terms of User Stories or Functional Requirement Specifications, special attention should be given to detailing the stories in such a way that while assigning for implementation there is the least possible dependency on any two modules. Let me be practical, not 100% elimination of dependency is possible when multiple teams are working on the same project, but reducing it to an extent may help you in avoiding the discrepancies. It is generally advised to manage multiple backlogs for different teams even though their execution period is the same. Keeping the work logs independent of each other will save you the time and efforts for bringing the teams to the same pace of execution.

2. Communicating with the stakeholders –

As mentioned earlier, when you communicate with project teams across the organization. You need to be very specific in your approach especially when you have a limited time-frame. Most efficiently this can be done when you make the requirements are conveyed in visual form like wireframing, prototypes, etc. rather than only documenting it. To avoid the gaps in understanding it, the following actions can be taken –

• Ask the developers to explain what they have understood in the sprint planning sessions rather than a BA trying to explain the requirement repetitively. This way you easily know, where the misinterpretation lies and you can certainly resolve it.
• Ask for effort estimation from different teams at an early stage. This will help you in figuring out if there is a huge disagreement in the time and efforts which you have estimated and what your team has provided, then there is a gap. You need to find it out and resolve it.

3. Issues and Risk Management –

There becomes a high probability of Risks and Issues going undiscovered, unattended, and unresolved when the work is distributed among multiple teams. There needs to be a constant focus on issues tracking and triaging. If the Risks and Issues are not managed well, all the parties can be forced to face the critical outcomes. To minimize the risk and issues going unattended, the following actions can be taken

• There is a need to create a centralized space for logging Risks and Issues which will be shared amongst the teams. There should be constant monitoring of issues and risks identified and the impact of it on the project deliverables.
• There should a Responsibility matrix created before commencing the work in which the project team members should be assigned responsibility in taking the Module or an Epic to the final stage/production.

4. Change Management –

Change Management has always been a critical part of the project. Since it has to do with project timelines and cost. All organizations may have it defined their way. When it comes to Change Management, there are a lot of factors associated with it, these are, change in project scope, change in implementation/project management approaches, timelines, resource allocation and cost of execution, etc. There is a presumption that a BA should be defining and managing the whole change management process, but there has to be a clear distinction made as to what a BA is accountable for in the process. A Business Analyst has to do with requirement analysis and prioritization, gap analysis, impact analysis, and defining the to-do implementation, but how that is handled at the execution level is entirely the Project team’s responsibility. When it comes to multi-vendor project execution, having a shared responsibility between a BA and a Project Manager or a BA and a Test Engineer is not advised.

These are some of the ways, which can make the project go in an easier and supervised fashion when working with multiple teams. I’m sure there can be other ways too, please share your thoughts on the same.