I recently read about the problems that Target’s new website is facing. The problems include people who are unable to complete their purchases and people who have lost their gift registries. Although any large, complex project will have difficulties, one line in the article particularly caught my eye: "Two years ago, the Minneapolis-based retailer decided to regain control over its online sales and enlisted more than 20 vendors…".
Based on my experience, enlisting "more than 20 vendors" to build a website seems like a recipe for disaster. I’ve found that even trying to get 3 vendors and a client to work smoothly together is challenging, especially from a Business Analysis and Quality Assurance perspective.
One Throat to Choke
One problem that I’ve seen when there are too many vendors is a diffusion of responsibility, which Kendra Cherry states "is a psychological phenomenon in which people are less likely to take action or feel a sense of responsibility in the presence of a large group of people." I have seen this effect on large projects that are internal to a single company; however, the effect seems to be exacerbated when the people working on the project are spread among many companies. Whenever a vendor gets behind schedule, their first reaction is often, "we’re dependent on another vendor to finish their work first." Typically, the other vendor will turn that right around and claim to be dependent on the first vendor before they can finish.
Generally, the claims of dependency have some validity, so someone in management at the client is left with the task of sorting out the schedule dependencies while the project languishes.
One of my clients explained that he likes to have only one vendor responsible for a project because he wants "one throat to choke" if something goes wrong. (As far as I can tell, he meant that metaphorically.) He said that when he hires a vendor, he’s hiring them to remove headaches rather than add headaches. If something went wrong, he wanted to deal with a single point of contact to resolve any issues. In order to have "one throat to choke", he gave that single point of contact a lot of power to resolve problems.
The Blind Men and the Elephant
From a Business Analysis and Quality Assurance perspective, I’ve found that one of the biggest problems with multiple vendors is that no single vendor grasps the overall vision of the project. Even though I have found that it’s important to break down complex projects into manageable parts, the project team needs to keep the bigger picture in mind so they can understand how the smaller parts interact with and affect each other. When the smaller parts are divided among different vendors, especially vendors who are not at the project site, the vendors tend to lose sight of the bigger picture.
The story of the Blind Men and the Elephant captures this concept quite well. Basically, since each blind man only feels one part of the elephant, they argue endlessly about what an elephant actually looks like. A marketing vendor, a database vendor, a security vendor, and multiple software development vendors will all tend to see their parts of the project quite clearly while losing sight of the overall goals of the project.
Avoiding the Problem
I believe that the best way to avoid the problem of having too many vendors is to do think very carefully about what vendor capabilities you’ll need before starting the project. Once you identify those capabilities, you should try to cover those capabilities with as few vendors as possible. Catapult Systems has recently added creative, marketing, and mobile services to our capabilities in order to address this problem.
Assuming that you find that you need multiple vendors, it’s important to have all of the vendors answer to the same internal customer. Any problems with seeing the big picture are magnified when the vendors are taking direction from different internal customers with different visions. Ideally, you will choose one vendor to be the general contractor to manage the project. This general contractor will be the "one throat to choke". However, you can only hold that vendor responsible for the project if you give them the power to truly run the project. This means that you need to involve that vendor in the decisions to hire any other vendors and give them some authority over any internal employees who are working on the project.
Finally, it’s critical to have a single repository across all vendors for documentation and code as well as a common test environment and bug reporting system. This helps force collaboration early on and ensures that all members of the team have visibility to all parts of the project.
I’d like to hear any of your experiences with working on projects that involved multiple vendors. What problems did you encounter? Did you find any strategies for solving those problems?