Infosys Microsoft Alliance and Solutions blog

« Some points to consider to leverage the benefits of MVC and jquery more | Main | Integrated Vehicle Management App (Part 1) »

Challanges in a Multi-vendor Project

Over the past 6 years I had the opportunity of working in multi-vendor projects. Apart from the complex nature of projects which is typical of multi-vendor projects, there are business and competitive aspects between vendors which present numerous challenges. This blog tries to analyses the structure of project teams in conjunction with multi-vendor setup and the challenges posed.

Typical parameters I would break this down are:

A. Customer Maturity:

1. Customer is IT mature - in the sense it understands the team dynamics, understands the vendor dynamics, understands and has laid out processes, roles and responsibilities

2. Customer is naive: here, there is not clear definition of roles, responsibilities, the dynamics of teams and vendors in the whole setup. And of course a customer can lie anywhere in this spectrum

B. Teams and their role in the whole project value chain:

1. Multiple vendors providing same value in the project - eg. There are Business Analysts of different vendor doing requirements OR developers of different vendors doing development.

2. Multiple vendors but providing different values in the project - eg. Vendor A is totally taking care of Business Analysis and Vendor B is taking care of development and so on

3. Where one vendor reports to another vendor - Cases where the customer PMO is handled by a vendor and other vendors have to report their statuses to it.

In this discussion, I am not considering independent contractors.

From experience what I have seen as high risk situations are:

Vendor service offerings overlap with each other



Highest Risk

L, H

Medium Risk

H, H


Medium Risk

L, L

Lowest Risk

H, L




Customer Maturity

The typical risks and mitigations in multi-vendor scenarios are:

Sr. No.


Mitigation steps by customers


Teams of different vendors not working in a constructive way - this typically leads to "leg pulling" and "blame-game"

1. Inputs and outputs from a team or team members are clearly defined

2. Include teams in common reviews and handover sessions to ensure all are on page and be specifically monitored by customer manager


Customers having overheads of dealing with the vendors account managers who constantly look for opportunities to expand their portfolio. Here the competing vendors will look for "failures" of others or try to interpret any failures to other teams and try to score from it

1. Do not entertain account managers who frequently present proposals to take over another vendor work. This exercise should be periodic (quarterly or as per budget cycle) and opportunity be given to all vendors.

2. Have periodic reviews (fortnightly or monthly) with account managers on current team project only


Different teams build walls in terms of trainings, ramp-up, hand-over of items etc.

1. Have clear output deliverables defined in handovers, trainings and handover

2. Ensure there is concurrence from receiving team

3. There is clear documentation available for above exercises


Teams covering facts and creating a perception which is not correct. This case is very specific to a scenario where one vendor is in powerful position (eg. of a PMO) and reporting to the customer

1. Have status reports of each team be submitted which should not be tampered by PMO. The PMO status report should be an extract form each of team reports

2. Have a communication channel with each vendor in terms of periodic reviews in presence of PMO. In this case the PMO should not be the anchor for the discussion, either vendor or customer manager should anchor

3. Create another forum of escalation above PMO but below steering committee for the vendors which should address operational issues if PMO is unable to facilitate

Apart from the above steps, in general the softer aspects of team building will always help the project:
- common event celebrations
- team building exercises
- making vendor teams our own - i.e. they should not be referred as vendors but "my team" or "XXX Project team". This will bridge the gap of "us" and "them", not only between customer and vendor but between vendor team members.

Over the next few write-ups, I will try and present some actual project situations where I faced these challenges and cases where our customer project managers effectively mitigated some.

Do share your valuable feedback on the write-up or post any relevant situation from your experience to add to the discussion.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter