Midwest IT Survival

Are you meshing with the vendor relationship owner?

Whether you are working in a complete custom software development shop with little vendor interaction or a technology integration shop with vendor solutions integrated with other vendor solutions on top of yet other vendor solutions, you will have to manage vendor relationships to some degree as an IT manager in a MidWestern company.  This series looks at the complex arena of IT vendor management and offers some tips to make the arduous process a bit less arduous and possibly discover some additional benefits along the way.

Vendor Management Categories

• Who Owns the Relationship

When looking into the broad topic of vendor management, one could easily be hit with confusion as to where to start the investigation.  For lack of a better place, I picked “Who Owns the Relationship” as a starting point.  Ultimately, someone or some group within the organization is the interface between the service the vendor provides and the benefit the business receives from that service.  Someone or some group within the organization knows who to contact within the vendor’s organization for answers to all facets of questions pertaining to the service the vendor provides, including:

• Service level agreements for deliverables
• Over all service cost structure
• Service benefits to the organization
• Out of scope elements
• Who to contact to reach subject matter experts within the vendor’s resource pool

The service could be as simple as a software widget that converts data from one format to another with the widget being used to complete that data conversion within a larger software application.   Or, the service could be as complex as a complete business process outsourcing arrangement where a major portion of a core business function is effectively provided beginning to end by a vendor loosely at the direction or more specifically, within the operating parameters established by the business.

As an IT Manager in a MidWestern company, knowing who owns the vendor relationship by service is absolutely critical to functioning successfully in your role and to avoid career challenging missteps such as:

You <out loud in an IT all hands meeting as you wait for the meeting to start>: “Who ever makes this FlimFlam software application must be the worst vendor on the planet!  The documentation is completely wrong.  It crashes every five minutes with completely useless error messaging and no logs!  Why can’t we just scrap it and run the market leading software by …”

Peer <in the meeting as well>: “Um, the FlimFlam software was developed by the CIO’s brother-in-law who also happens to be a member of our company’s board of directors.”

You: “Ummmmm, errrrrr …”

This is somewhat an extreme example, but the point I am trying to convey is vendors are sometimes selected not because they are best of breed or because every technical person within a 200 miles radius of your desk would all agree on vendor X for a particular solution, but rather, due to disconnected value propositions.  Propositions such as due to a personal relationship or due in part to a larger arrangement that accepts a lower quality of service solution for an associated arrangement that provides higher overall value to the organization.

Extending the above example evern further: given a software application that you have been tasked to get functioning but is not performing as advertised, how does knowing the vendor relationship owner assist in your need for success?  The vendor probably knows at some level they aren’t quite providing the best solution to the business need.  Yet, they have a similar stake in maintaining credibility in providing this software service given their company owner is directly involved in this customer relationship.  The last thing employees of the software company want to be dealing with is their owner coming back to them with:

Software Company Owner: “Hey, I’m hearing our product isn’t working for ABC Company.  You know I am directly involved in ABC Company and don’t want to hear our product isn’t working for them.  What are we doing to fix this situation so I only hear good things about our products from ABC Company?”

So, how can you leverage this example’s relationship ownership knowledge to your advantage?  Consider approaching the CIO or appropriate members of the organizational chain that can interface with the CIO to present the challenge this way:

“We are having some trouble getting the FlimFlam software up and running.  It is probably something we didn’t quiet understand from the limited interaction and documentation provided to us from the FlimFlam company.  I understand you may have some knowledge on how to put us in contact with the right people at the company to help us get past our current challenges.  Can you help us get that contact established?”

Since, in this example, the CIO is connected to someone high up in the management/ownership of the vendor, slamming the vendor is also a slam against the CIO for choosing and thus  endorsing this vendor.  Flipping this around, the CIO has chosen and is thus endorsing this vendor; hence, the CIO wants the vendor to succeed so he or she is viewed positively for bringing in this vendor to the organization.  Thus, presenting the problem of bad software instead as a need to gain access to strong vendor resources to partner with your team to get things installed correctly shows your respect for the vendor relationship and the credibility of the CIO yet still affords you the ability to complete your task.  Or stated yet another way, given this query, how can the CIO not pick up the phone, call someone important at the vendor and push them to get their top people engaged in order to preserve his credibility?  The CIO involvement can go between two hypothetical extremes in this example:

Extreme = Ultra Positive

Top engineering resources at the vendor are engaged.  They are informed of the stakes and provide high touch service to you and your team.  Maybe they have a good product but the documentation is weak and they can fill in the gaps.  Maybe they, in working with your team, discover a gap in their product and with you and your team’s help; they are able to provide technical fixes that work specifically in your technical framework while strengthening their product for other customers.  CIO appears to be the hero.  He or she was able to bring the right people together to make this happen.  CIO views you as a strong management team partner as you enabled him to reinforce his leadership perception with little risk and little effort on his part.

Extreme = Somewhat Negative

The vendor doesn’t have top engineering resources or the product is indeed a wrong fit or the vendor fails to manage the relationship on their side of the vendor management equation.  Whatever the failure, you have kept up your side of vendor management arrangement.  If you continue to keep good notes and use email to document major communication exchanges, you will have evidence to show you really tried to partner with the vendor but things fell down on the vendor’s side.  Be prepared for unpredictable external events to trickle down to you and require you to quickly assemble your “here is what we did and said when” list to provide your perspective that even after the high level vendor resource request, the vendor is not coming to the table with solutions.  Again, bashing the vendor or using this forum as an opportunity to vent your frustrations will trend towards career limiting rather than career bolstering.

Continuing this MidWestern IT perspective on the topic of “Who Owns the Relationship?” in the next article.

Related posts:

1. Vendor Management – Part 1 – The Intro