Well, you blew the project, and now you need someone to blame. You could blame the guy who just left or your archenemy in accounting, but blaming either would have consequences you don't want. The vendor - now that's an easy target. This column will provide you with a roadmap and talking points to transfer all your mistakes onto the vendors. This is an opportunity for you to export blame, a time-honored approach for those who are adverse to responsibility.

Blame the Vendor Top 10

  1. The products we chose did not work well together. Right there in the glossy brochure were products and vendors who are their partners. We assumed that meant that the products were integrated (whatever that means). That was good enough for me. Why else would they have listed them? The vendor is clearly at fault for misleading us.
  2. The performance was unacceptable. We tested with a small subset of data and looked at the response time of one query. We assumed linear scalability. The vendor didn't tell us anything about nonscalability. Once again, the vendor let us down.
  3. The support was terrible. When we called, the guy at the other end of the phone was not at all helpful. We asked where he was, and we found out the vendor outsourced their support to inmates in a state prison. The vendor told us that this was all a part of their diversity and community outreach program. While I understand and support the vendor's desire to be a good corporate citizen, they should have provided better support.
  4. The vendor filed for bankruptcy.  When we asked for their financial statement, they said it was proprietary, so we had to honor their desire for privacy. We really weren't concerned because in their presentation, they showed us a picture of their headquarters. We only learned later that the property was leased, the vendor was already four months behind on the rent, and their name on the building was the work of one of their more talented employees. It's a shame the talent did not carry through to the integrity of their financial staff.
  5. The product was very buggy. We were constantly working around the problem or waiting forever for the vendor to provide fixes. The quality of the product might have had something to do with it not being generally available. The truth is, we were experimenting with beta code on a new release that wasn't planned for general availability until the following spring. That might have been one of the problems with the quality of the code. The vendor had shown us four awards they had been given for the quality of their product. It turned out that the awards were internally generated. I don't think those are as good as those given by TDWI or DM Review. The vendor should have spent more time and effort in testing their product before making it generally available or, in our case, before making it available for beta testing.
  6. No other organization was running the product with our configuration. We did ask for references. They were promised, but we were in hurry to get started and the references never materialized. But we were asked to be a reference, and we started getting calls even before we signed the contract. Maybe they never had any good references.
  7. The salesman said the product would be a snap to install and use. It was far more difficult than he represented it to be. Our existing staff was unable to properly install and support the product, and we couldn't find outside contractors with enough skills and experience to be able to help us. Why didn't the salesmen warn us of this problem?
  8. We blew the schedule. The vendor said we could install the product in 90 days and, in fact, we did get it installed with a small proof of concept (POC), but management was expecting a complete system rolled out to all our users in the 90-day period. I think the vendor did qualify the 90-day effort to be just the POC, but they let management believe everything would be finished in that time period.
  9. The product required additional features that were not in our budget. It's true we never asked what else we would need, but it wasn't our fault. We were not in a position to tell them everything we needed because our requirements were not completely defined. That might have been one of our problems. And so we would have been charged for all those additional capabilities, but because we didn't have the budget, we went with the base product that really didn't meet our needs. The vendor should have been able to figure out what our eventual requirements would be.
  10. The individual consultants/contractors we used were inexperienced. We probably should have asked for their resumes. The contractors sent by the vendor seemed fairly young (one was dropped off everyday by his mother), but our consulting vendor assured us that young minds learn quickly.

You don't have to accept the responsibility for your failure. You have a ready scapegoat, the vendor. For your next project, you will choose a vendor who will be more responsible and be able to solve all your problems. Count on it.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access