Clif's notes on architecture, leadership

10 Warning Signs When Dealing With Vendors

Hiring a wolf to guard the sheep? Ten red flags for project managers, architects, and executives when a vendor is in the driver's seat.

As an Enterprise Architect, it’s my job to know everything that happens in my enterprise. Well, that’s not exactly true, but it is important for me to be aware of, and be able to understand, everything in my particular domain in my enterprise. Does this mean that I have to start off as an unquestioned expert in all those things? Absolutely not. I just have to be able to learn, understand, and reason.

Because of the nature of my job, I often get pulled into initiatives where vendors are making a pitch or taking the lead from an architectural perspective. Having a vendor in the driver’s seat poses some significant risks to the enterprise regardless of how experienced and reputable a vendor may be. Even great vendors will make mistakes. When that happens, you’ll be the ones who have to deal with the long-term ramifications, not them.

It’s even worse when you have a self-serving vendor who is running an initiative or making a pitch. If you’ve ever been in this situation then you know what I mean. If you haven’t then don’t worry, you will. It is not a pleasant experience.

It is for this reason that I’ve put together this list of things for Project Managers, Architects, and Executives to keep on the lookout for when hiring a wolf to guard the sheep:

  1. Missing the forest for that other forest over there. Does your vendor have extensive expertise with a product that they are recommending for use in a non-traditional way (BizTalk as an ESB, SharePoint as a CMS, etc.)? If your vendor is doing this then they’re probably too invested in that product. Round peg, square hole. Pick a different product and a different vendor.

  2. That new car smell. Does your vendor have a brand new product (or new product release) that they say is exactly what you need to solve a problem or to replace some other product? If so, seek independent confirmation. Remember, every product has problems, especially at first. The question is whether the pieces you need are the problem pieces. Being a guinea pig is risky and you will have to make sacrifices. Make sure they’re worth it.

  3. Which comes first, the chicken or the egg? There is a right answer to this question and it’s not as complicated as it might appear. Does the vendor start with the plan or with the product? Do they start with the answers or do they start with the analysis? Don’t let them skip the legwork, because that’s the part that really matters.

  4. Overloading the switchboard, a.k.a. one system to rule them all. Is your vendor advocating centralizing many different functions in a single system? Why? Is this the correct approach, or would a best-of-breed approach provide a better, more efficient experience?

  5. Beware a vendor bearing gifts. Even more importantly, beware a vendor bearing gifts to your boss. Your boss wants to be approachable and available. They want to make the right decisions. They want the organization to choose the right solution. An expensive dinner or a golf outing is a great way for a vendor to get your boss alone and influence their opinions in a relaxed setting. This isn’t necessarily a red flag, but it is, at least, a yellow one. The product may be a good one, but remember: selecting the product before accurately defining the need is almost always a mistake.

  6. If it’s in the atlas then it must be true. Just as trap streets on paper maps were meant to catch copyright infringers, beware placing too much value on a software roadmap. Any good vendor’s roadmap will change based on their customers’ needs. If you plan an implementation based on a roadmap feature then you are building your enterprise on a foundation that may (or may not) be there when you need it. If the roadmap is a major factor in your decision-making process then you may be making the wrong decision.

  7. Lemmings follow industry trends, too. If the vendor cites “industry trends” as primary architectural guidance then you should probably look for another vendor. While industry trends can certainly inform architectural decisions, those trends should not be the basis for those decisions. Every organization is unique and has unique needs. Do not be led blindly off a cliff. Blockchain, anyone?

  8. Beware the rumor of positive press. Anyone can put together an impressive client list or tell you about their clients’ revolutionary experiences, but it’s all too easy for them to mislead. Reach out to their clients for independent verification, without the vendor on the phone. Be careful of revisionist history and of poor vendor follow-up. Did the whole thing fall apart a year later? The vendor might not even know.

  9. Werewolves never die. As it turns out, there really is no silver bullet. If your vendor has the “perfect solution” for you then you’d better proceed with caution. Ask them what the product’s weaknesses are. What does it do poorly? If they can’t answer that question then walk away. Every product has issues. Your job is to pick the product whose issues pose the fewest problems for your specific organization.

  10. Caveat emptor, or let the buyer beware. Is the price too good to be true? Ask the vendor why. Will there be licensing or support hikes in years 2, 3, or 4? Are there features missing? Perhaps they’re on the verge of a buyout or looking for another round of venture capital and want to pad their numbers. If you’re unsure, consult a firm with a vendor analysis arm, like Gartner, for additional insight.