Business globalization, the popularization of international partnerships, and modern communication technologies provide companies with access to top talent from around the globe. Outsourcing to multiple software development vendors, you can engage software engineers, UX/UI designers, and QA specialists with the most relevant competencies and ensure the end product’s high quality.
On the flipside, multi-vendor project coordination is a taxing job that requires fail-safe service delivery, timely feedback, regular meetings, and discussions —all for multiple parties globally. Ignoring this complexity and relying on the established management approaches can undermine the result so that even an innovative idea and best-of-breed technical specialists would not secure the project’s success.
Here we outline the recommendations that Itransition has accumulated during our long-term outsourcing experience and describe the ways to prevent each of the potential bottlenecks. Let’s take a made-up multi-vendor project as an example.
Avoiding Internal Chaos
The situation. Imagine a startup brainstorming an innovative IoT system. The CEO approves the idea and asks to be regularly updated on the project’s progress. The CFO estimates the project budget yet is left unsatisfied with what she gets. The CMO finds the market niche. In essence, each player does their part of the deal, yet no one takes responsibility for the final decision and instructions for designers, developers, and testers. In the end, the project gets put on hold.
The solution. From the get-go, decide who is involved and who will make decisions. Whenever possible, select a leader to be a single entry/exit point for all project activities. Ideally, the person should be competent enough to understand the technical specifics of the project, have sufficient managerial skills, and be available for regular meetings.
In most cases, everyone will benefit when the VP of Engineering volunteers to take charge of the project, saying: “Guys, I know you’re all professionals and I have trust in your expertise. But let me be the one responsible for decisions and outcomes. Let’s meet every two weeks: you will update me on the project progress and I will collect your feedback, filter it, and pass it on to contractors. Does Monday sound good for everyone?” And the project will take off.
Improving Visibility
The situation. Our startup orders the IoT device prototypes from a factory in China employs a UK team to do the UX and the frontend contracts US engineers for backend development and chooses a Canadian firm to perform quality assurance. The backend team starts work immediately, while the frontend developers and QA specialists run into difficulties and start lagging behind.
As a result, confusion ensues. The backend and the device are finished, but the frontend team is in the dark about this. At the same time, testers can’t go further and keep bombarding the project manager with questions. The teams are wasting their time, while managers are unaware of the project’s status.
The solution. To maintain more control over the project, divide it into one- or two-week stages (sprints). All vendors should have a list of tasks to complete by the end of each stage. To avoid confusion, we at Itransition layout all the phases as a Gantt chart, but with a little trick.
The standard diagram lists tasks in lines and time in columns. But if the team has recurring tasks throughout the project, the chart can grow too long. Instead, we advise recording the repeated steps in columns. This will make the chart shorter and provide a clear view of what teams do at each particular stage.
Ensuring Cohesive Communication
The situation. Before the interface goes live, the API should start transmitting data from the database to the frontend. The backend team fails to meet the deadline, as neither the API nor the database is finished on schedule. Without the API transmitting data, the interface doesn’t go live. The frontend developers and testers had nothing to work with, and managers learned about the problem all too late.
The solution. First and foremost, rely on tools for task scheduling and document storage from the outset. We usually use Atlassian Jira and Confluence, but any other issue tracking solution will do.
To monitor whether the project goes as planned, it’s advisable to schedule regular video calls with vendors. Before each call, the project leader needs to formulate the meeting agenda and make sure the selected time suits all the participants. You will break a sweat picking a convenient time for both China and Canada but, on the bright side, all sides of the project will be accounted for.
During these calls, discuss in detail the project’s status, achieved milestones, and occurring challenges, and work out how to best address them. At the end of each meeting, you can give vendors another task to complete until the next call.
Planning Well
The situation. The backend team launches the API, prepares the databases, and has everything ready to be tested. At this point, it comes to light that the Canadian testers can’t work with foreign legal entities, so the lawyers need to review the contract’s wording. The project comes to a halt while lawyers spent days polishing the contract and sending emails back and forth.
The solution. To meet product release deadlines, make sure to reserve time for unexpected circumstances before the project takes off. In this case, having enough leeway, you can hold an emergency meeting with QA engineers and lawyers to work out the legal niceties together. This way, the testing team can get to work faster and has higher chances of making up for the lost time.
It’s impossible to make provisions for every possible disruption. You can’t predict whether the senior developer catches the nasty flu right before the release, but you can still draw up a strategy for this type of emergency that would outline how to resolve the ensuing bottlenecks and mitigate risks.
Taking Care of Technical Documentation
The situation. When half of the backend is ready, it turns out that even though the device is great, for some reason the data gets sent to the backend using FTP, not TCP as it was agreed, because the backend has been erroneously designed to fit TCP. As a result, a considerable amount of code has to be rewritten, and the project is again put on pause.
The solution. Technical documentation is an indispensable part of any successful development project. When drawn up at the early SDLC stages, it should catalog the end product’s logic and architecture, technology stack and feature set, business functions, and usability.
Also, you should record everything vendors say during meetings. The perfect scenario is to have every responsible party on the same call, if not in the same room, and discuss each mission-critical implementation before it happens. But the world is not perfect, so when vendors do agree on some technical issues, write it all down word for word.
Without documentation, each party will do as they see fit. In our example, the backend team used TCP, because it was an easier and more logical choice. The hardware team preferred FTP because otherwise, they would not have been able to create that kind of device. The project leader should always take care of bringing all parties together, protocol the solution, and make sure everyone follows established requirements. Although it is time- and effort-consuming to document every technical aspect, without vital agreements put down on paper, each party involved is doomed to struggle with the project.
Multi-Vendor Project Orchestration: A Checklist
By examining the case of a fictional company struggling with their multi-vendor outsourcing, we identified the key practices for setting the project on the right course from the very beginning:
- Appoint the decision-makers from the get-go
- Divide the project into small phases
- Constantly review the progress
- Reserve time for unexpected problems in advance
- Create technical documentation and note down vendors’ discussions
