Once you decide to create a successful end-to-end IoT application development project, you will inevitably face the question: who will be your tech partner? Even if you have an experienced trusted team, it may lack expertise in certain areas or have insufficient human resources to nail it.
So first you start with the question whether you are going to:
- Work with a single vendor and transfer the full project development cycle to this company; or
- Find several vendors with niche expertise for separate project areas and contract each of them individually.
The complexity and quick development of the IoT sphere is putting an end to the one-stop shop practice. Adopting new technologies in this domain requires scale, flexibility, and expertise, which are hard to find in a single software development company.
However, dealing with multiple providers exposes a product owner to other risks, first of all, governance-related ones.
How to overcome these risks and achieve a perfectly synchronized team?
Below, we offer a10-step guide to putting in place the most effective project management system in cases, when multiple service providers are concerned. But first, what are the tradeoffs in working with multiple partners versus a single partner?
Multi-Vendor vs. Single Vendor
A complex IoT ecosystem includes many levels of functioning:
- Hardware level, where objects turn into “smart things”, enhanced with firmware/embedded systems and smart sensors function.
- Infrastructure, where sensor data is stored, analyzed and processed, be it cloud-based or in-house.
- Mobile application, establishing a connection between a “smart” object and the project’s infrastructure, for the former’s control and management.
Let’s be honest: it is pretty hard to imagine a software development company capable of delivering such projects, relying solely on its in-house team. And even if you start working with a primary tech partner, soon you may face one of the following situations: new requirements are coming up, and the vendor doesn’t cope with them; you need additional manpower to speed up the development process; you are trying to avoid risks of vendor lock-in, etc.
At the same time, many customers are still seeking a technology partner, who will take over the A-to-Z development process, as this appears more manageable and localized.
That’s why the “single vendor vs. multi-vendor” dilemma regularly pops up in the IoT world.
Disadvantages of Multiple Suppliers
- Added complexity. Managing and coordinating different units is not an easy task. When you work with a single vendor, it is logical to assume that the vendor will manage the ongoing processes himself. In case you opt for multi-vendor development, you become the coordinating point, managing the cooperation between different teams.
- Reduced developers’ collaboration. At Softeq Development, we often see situations when communication between the engaged teams doesn’t function properly. As a result, development activities are slowing down, and vendors happen to start finger-pointing at each other.
- Variations in technologies & process management. Even if the assigned teams work with the same technology stack, they work with it in their own way. That is why it will take additional time and effort to define standardized rules the chosen vendors will comply with, to avoid incompatibility in business processes and technologies.
- Added costs. A multi-vendor project is typically more expensive than a project with a single vendor – at the very least because you have to factor in additional administrative and management costs.
Disadvantages of Single Sourcing
- Lack of expertise. As mentioned before, an IoT project is always a complex multi-faceted infrastructure, with a lot of innovative custom solutions in place. In practice it can be quasi impossible to find a developer, skillful enough to manage such a project all by themselves.
- Limited functionality. Stemming from the previous point: you can hire a great team with outstanding expertise in the cloud projects – but their testing team is not that impressive. Or, maybe, their designers don’t catch up with the required level. Would you agree for such a compromise when starting cooperation with them? We seriously doubt it.
- Dependence risk. Once you work with a single technology partner, you rely heavily on them. It is getting harder to negotiate rates and budgets. Another risk: once your partner faces a human resources trouble or any other type of misfortune – and your project is in danger as well.
When a Multi-vendor Environment Pays Off
Going with a single or multi-vendor approach often comes down to customer’s human and financial resources. An experienced IoT development team like Softeq finds that sometimes choosing a single vendor is the best option, despite the above mentioned limitations of this approach.
This strategy would minimize project management costs and bring about a stable result, if you pick up the right vendor and establish effective cooperation with him.
If a customer has already invested resources into product development and now seeks a stable and reliable operating environment – a single-vendor strategy would be a winning solution.
However, if a business has enough resources at its disposal, has a clear idea of the challenges of a multi-vendor approach, and is ready to manage this complex affair – it will leverage all the benefits of this strategy.
- Getting the best-of-breed products and services. When choosing experts in specific domains, you have all the chances to get not just a functional, reliable and predictable product – but something truly innovative and, who knows, groundbreaking.
- Multithreaded work on the project. When managed right, different elements of the project can be on the go at the same time, accelerating product development processes.
- Driving competitiveness. Working in synergy, vendors are constantly raising the bar of their services and expertise – and the client reaps the benefits from it.
10 Steps for Managing a Multi-vendor IoT Project
So, the principal advantages of choosing a multi-vendor IoT development strategy are clear. But the question remains: how to manage such a complex environment and get the wished-for result?
Here is a step-by-step guide to establishing an efficient multi-vendor governance framework.
- Defining the scope of the project. Before delegating tasks to vendors, product owners must assess their project properly and figure out overall business goals and how they are planning to achieve them. Without this, requirements will be changing too often, and this will prevent developers from keeping focused on the ongoing project. Once you complete this step properly, you will have: a high level picture of the project vision, the required skill sets for vendors, the technologies to be used, and the main requirements for the success of the project.
- Select the best tech stack and processes within the allocated budget. Resources are always limited, so you’d better choose the technologies you can afford, right from the start. Let’s take a simple example: sometimes economizing on a server-based solution and going for the cloud can be a better solution than assigning most of the resources to the project infrastructure, while neglecting the upcoming mobile app development or cutting costs on the design.
- Engaging providers. Your first task here is choosing the most skillful and suitable providers. The second – establishing a standardized infrastructure, unifying processes and key performance indicators (KPIs) of each team into a single set of service requirements and optimal performance metrics for each task, usually defined in service level agreements (SLAs). To streamline effective cooperation between their teams, vendors can sign internal operating level agreements (OLAs) with each other, to specify co-working processes between them
- Establishing the right KPIs. Speaking about KPIs: once you engage a few vendors, it is as risky to monitor too many metrics (and drown in the received data) as it is to go on with a project with no monitoring at all. Instead, start with figuring out the most critical elements in your project (timely product delivery; compliance with laws and cybersecurity requirements; cost minimization, etc.), and then establish qualitative metrics based on a minimum acceptable required level of performance and quantitative metrics, which would be both realistic and achievable for vendors.
- Roles & responsibility assignment. To minimize functional overlaps and dependencies, each vendor’s team needs a clear idea of their individual scope, activities, deliverables and level of responsibility.
- Putting in place communication and task delegation framework. To manage overflow or workloads, as well as avoid one team stepping into another’s domain, product owners need to all teams with the rules of how vendors communicate with each other, how they transfer their parts of work, share knowledge, receive feedback and final approval – and what happens next.
- Encouraging the “one-team” approach. This step is often neglected. But let’s face it: communication troubles are often caused by the fact that different teams, without knowing each other, have to cooperate on a complex project. Promoting team culture becomes a must, and can be backed up by regular sessions and interactions, online meetings and team retrospectives.
- Issue & risk management. A product owner should not only specify the rules and regulations vendors adhere to, but also define penalty clauses for non-adherence, for example, financial guarantees for late delivery or for poor quality deliverables. This will lead to better accountability and ensure that vendors don’t pass the buck to each other.
- Performance reports. To keep track of a performance level of each vendor, one should enforce regular reports, containing an update on progress, accomplishments, and upcoming work.
- Establishing incentives & penalties. Once product owners figure out how to encourage service providers and what will push them to deliver their part of work properly and on time, they can create a motivating and supporting infrastructure, including incentives for performance or a penalty for non-performance of the SLA.
Alex Makarevich is Content Manager at Softeq – a US custom IoT development company and an Inc. 5000 honoree. Having worked in the publishing house Éditions Techniques de l’Ingénieur (Paris, France), gaining experienced in editing texts both in English and French, she has switched now to topics associated with IoT, web and mobile development.