Vendor Management Categories

• Role of the Sales Rep

Leverage your Vendor Sales Cheese to avoid the Architecture Astronauts!

In the previous article [], we explored how this role can benefit the IT engineer by cutting through the bologna that is the normal route to getting technical support from a vendor and putting one in direct contact with a peer senior technical resource that can solve tough problems quickly.  But what about the benefits to an IT manager?

IT Manager Dividends

Scenario 1 – You Don’t Have Bob the Engineer from the Previous Example

Well, let’s start with that same hypothetical problem scenario in the previous post [] with a production problem being reported in the service you and your team are responsible for, in this case the FlimFlam software.  You don’t have a Bob that has introduced himself to the Vendor Sales Cheese and established himself as the guy, that when he reports a problem with FlimFlam, there is indeed a problem with FlimFlam and Bob needs senior tech support ASAP.  It not, the Vendor Sales Cheese is going to spend his or her value time not selling but rather in fire suppression mode.

Once you notice your team is stuck in the troubleshooting process with the FlimFlam software and the trouble ticket that is open with the vendor is going no where, have your Vendor Sales Cheese contact info handy:

Sally the Manager: “Hey, Vendor Sales Cheese, it is Sally at ABC Company.  Well, no, everything isn’t quite fine.  We’ve got a problem.  FlimFlam is causing customer pain and is throwing an error 57 that no one, not even the tech folks behind your support web site are able to figure out.  You know I don’t waste your time with the trivial stuff, thus this isn’t trivial.  I am about to get on a conference call to explain to my peer management that we have our top engineers working on the problem but I don’t have a good answer when they ask what the vendor of FlimFlam is doing to aide us.  Yes, you can help, that is why I called.  Can you get a senior tech person to look at support ticket <blah> and then have that senior tech person call Joe on my team at <blah> to start resolving the issue?  I have your commitment someone is going to call Joe, right?  Good … now I have a much better story to tell everyone on the conference call.  I’ll be in touch.”

Similar to the previous example, you can leverage your relationship with the Vendor Sales Cheese to get priority service.  From a management perspective, you have just increased the technical capacity of your team without incurring any additional cost by leveraging the notion that the Vendor Sales Cheese would rather have a happy customer for which they can manage this problem more proactively since they were engaged early in the problem resolution process.  Any experienced Vendor Sales Cheese that been set on proverbial fire coming into a customer hot zone with threats of having the vendor and all provided products and services throw out because high level management had to get involved with a problem that, to them and rest of the organization, should never have occurred in the first place.  High level management sees the $$$ from their budget going to these monthly maintenance fees to their vendors as insurance that they will never have to directly deal with a problem caused by the vendor.  The Vendor Sales Cheese that can get engaged in a hot problem early, bring the right level of technical support and relationship support at the highest level and make the problem go away quick has actually earned positive face time with higher levels in the customer organization.  Their bet is the higher levels in the customer organization will see the support value in addition to product feature set from the vendor and look for that vendor to provide future solutions.

Thus, if the issue is heating up in your organization and you don’t have a Bob that has dragged the vendor into the troubleshooting mix, get on the phone to the Vendor Sales Cheese and give the Vendor Sales Cheese the opportunity to augment your team’s technical capacity as well as the opportunity to manage the customer relationship early rather then when asbestos underwear will be required later.

IT Manager Dividends

Scenario 2 – You Have Bob the Engineer

In this scenario, Bob on your team has already brought the vendor into the troubleshooting effort.  So, all you have to do is put your feet up on your desk and watch the magic happen as Bob and the senior vendor resource solve the issue before the day is over.  Well, you could, but what if it is 6PM and Bob and the vendor are stuck after hours of troubleshooting?  Once Bob has reached out to the Vendor Sales Cheese, wait a brief amount of time and then make a follow-up call yourself.  Let the Vendor Sales Cheese know that of all the problems you wrestle with every day, this one has your highest priority attention.  This further emphasizes to the Vendor Sales Cheese that this problem could become the problem that has the Vendor Sales Cheese sending $300+ an hour vendor solution architects to your company for free to appease the post resolution craziness that will surely develop if this problem isn’t given top priority and resolved in short order.

Sure, the Vendor Sales Cheese will quickly become high maintenance because they have had to work with customers in postmortems where a bunch of company architecture astronauts are swooping in after the system has been stabilized to philosophize on how a completely different solution that doesn’t even involve the vendor’s technology would be the best approach for senior management to implement to avoid this type of problem in the future.  The experienced Vendor Sales Cheese knows that once they are up against the customer’s architecture astronauts, the customer’s senior management has lost faith the vendor can save them from getting involved in distracting support issues.  Plus, senior management gets to throw out a vendor that failed and proceed to be courted by new vendors salivating at getting the opportunity to make the sale and have the “we replaced vendor X at company Y” story to enhance their sales pitches of the future.

Again, be prepared for the Vendor Sales Cheese to be high maintenance, but take comfort in the constant polling for status can easily be a positive when you need the vendor to jump higher and you already have the Vendor Sales Cheese with full issue context ready to say “how high?”

This concludes the perspectives on the role of the sale representative short of their role in the sales cycle and pricing.  I’ll dive into this aspect in the next article with more MidWestern IT perspectives on the topic of the “Sales Cycle and Pricing” in the spectrum of vendor management.

Related posts:

1. Vendor Management – Part 9 – Role of the Sales Rep – Part 2
2. Vendor Management – Part 8 – Role of the Sales Rep – Part 1
3. Vendor Management – Part 7 – Vendor Service Integration Challenges Continued

Vendor Management Categories

• Role of the Sales Rep

The Vendor Sales Cheese can keep you off the phone and on your keyboard

In the previous article [], we explored this role more deeply and how, as an IT manager or IT engineer in a MidWestern company, you need to partner with this role to be successful in delivering you and your team’s services to the company.  We established the notion that as either an IT manager or IT engineer, instead of bolting for the nearest keyboard, there is benefit to spending five minutes introducing yourself to the Vendor Sales Cheese and giving him or her a clear understanding of your role within the company and how you are linked to the product or service the Vendor Sales Cheese is representing.  We left off suggesting that this brief exchange will pay off in tactical dividends.  So, enough with the preview, what are these so called dividends?

IT Engineer Dividends

In short, someone to suck into your troubleshooting effort to get you the technical expertise you need without having to sit on the phone on endless hold finding it yourself.  Someone you can say: “Hey, I did everything I was supposed to do to get help and I am stuck.  Get someone who can speak at my level that knows your product and can help me get this working ASAP.”  Take this typical scenario:

A technical problem makes its way through your business call center through the IT technical support helpdesk to your inbox.  Based on the brief explanation of the problem and the levels of “reboot your PC and try again” and “close your browser, clear your cache and try again” that have been tried with no success, this hypothetical situation suggests you are going to have to roll up your sleeves and figure this out because likely, no one else can in the company.  So, after much wailing and grinding of teeth, you are able to reproduce the problem in a test environment and have ruled out everything except the FlimFlam product.  From everything you can tell, you can now get the problem to occur at will, but all the FlimFlam system does is throw an “Error Code 57: Process died unexpectedly”.  The almighty Google is no help with error code 57.  The vendor’s tech support web site or “knowledge base” (which you have now dismissed as an oxymoron) completely mocks you with no reference whatsoever to error code 57.  So, no instant problem resolution gratification today, you have to log in to the vendor’s support web site with your company’s magic trouble ticket account to open a support issue.  You have been down this road plenty of times before, so you succinctly enter the exact end user steps to reproduce the problem and generate an error code 57.  You cut and paste in a copy of the system log that says “yep, I’m definitely throwing an error code 57 … and unexpectedly as well!”  You provide your platform and vendor product version, revision, and patch level down and dump the configuration out to the final detail.  You get back a trouble ticket number which you write down in the false hope your next email from the vendor’s support site will have the magic cure.

Off to lunch at the default route … err, food court at the mall

When you get back to your desk, you see an email from the vendor’s support site indicating your ticket has been closed.  You log back into the vendor’s site to see the last ticket status entry read:

“Upgrade to the latest version by applying patch 59837”

You switch over to the download tab and punch in “patch 59837”.  You quickly skim the release notes only to find absolutely no reference to error code 57 or anything that even resembles the problem you reported.  You’ve played this game many times before.  But you know, you have to play it or you get stuck at this level in the game, forever unable to advance.  So, you download patch 59837.  You install it in the test environment.  No install errors.  You re-test the system and low and behold, on the first attempt, you generate error code 57 with the same “unexpected-ness”.  So, you go back to the vendor support site.  You re-open your ticket; indicate you did exactly as told with no success.  Again, you’ve been down this road, so you re-state the platform and product versions showing the new patch applied.  You re-attach the log files and a dump of your configuration settings.  You re-attach the steps to create the error.  You raise the ticket to highest priority level you can.  You submit it back to the vendor.

Time goes by.

People in the company, including your boss, start asking: “Hey, when is that problem going to get fixed, people are complaining.” or “customers are getting irritated” or “we are starting to experience high call center call volume related to this problem.” Or whatever constitutes the inter-company fervor building to where you will soon be joining conference calls to explain what is going on and where things are at … rather than being allowed to actually fix the problem.

In anticipation of that first “please join the problem resolution conference line” alter, you re-check your ticket status online and see:

“Ticket Status = Pending”

… and nothing else.

Your world is about to get even more unpleasant as you see you’re frustrated and exhausted boss heading to your cube.

Wouldn’t it be great to have some human at the vendor to reach out to who is motivated to keep your company happily paying the monthly maintenance fees to help cut through the bureaucracy and get your technical peer at the vendor working on a fix for this problem?  Someone who can find that singular vendor engineer, that upon seeing your configuration can immediately go:

“Geez, they are running on OS 34 in 61-bit mode?  They need to add the ‘no cache during day light savings time=yes’ setting to their config file or else they will throw error 57 every time someone presses the ‘Q’ then ‘k’ keys.”

Here is where having the contact info for the Vendor Sales Cheese handy and having had that five minute conversation not too long ago with the Vendor Sales Cheese pays big tactical dividends.

Bob the Engineer: “Hey Vendor Sales Cheese, it is Bob at ABC Company.  Hey, I am getting the run around on support ticket <blah>.  I did everyone as instructed but we are still getting errors from FlimFlam.  A whole bunch of managers are going to get together and start talking about this problem with FlimFlam which means they are probably going to call you at some point if this problem doesn’t get resolved.  What do you need from me to get a senior tech guy to call me ASAP to avoid this pending mess?”  (Note the clever use of language to make your problem the Vendor Sales Cheese’s problem as well.)

The Vendor Sales Cheese doesn’t want to spend time putting out a fire at a customer’s site due to his product or service.  He or she wants to out selling their product or service to a new customer.  Plus, the Vendor Sales Cheese knows you from that fire minute conversation at which they “Check!” linked you to the top tech guy who knows his stuff and only needs help when something is going horribly, horribly wrong at ABC Compnay.  The Vendor Sales Cheese starts lighting fires within his company for get their FlimFlam tech expert on your phone ASAP.

That five minute awkward conversation with the Vendor Sales Cheese pays off big time when that FlimFlam senior tech guy or gal calls you with the magic config file setting that makes the whole problem go away.  And equally important, stops you from having to join the company trouble call and spend countless hours trying to explain to a conference call full of managers.

IT Manager Dividends

Ok, I see the value to the IT engineer, but what about the IT manager?   I’ll dive into this value proposition in the next article with more MidWestern IT perspectives on the topic of the “Role of the Sales Rep” in the spectrum of vendor management.

Related posts:

1. Vendor Management – Part 8 – Role of the Sales Rep – Part 1
2. Vendor Management – Part 7 – Vendor Service Integration Challenges Continued
3. Vendor Management – Part 6 – Vendor Service Integration Challenges

Vendor Management Categories

• Role of the Sales Rep

You want to get to know the shinny suit

In the previous article, I concluded thoughts on vendor service integration challenges.  I made a cavalier reference to the “Vendor Sales Cheese” role.  This article will explore this role more deeply and how, as an IT manager in a MidWestern company, you need to partner with this role to be successful in delivering you and your team’s services to the company.

I don’t think there are more diametrically opposed roles in business than the IT engineer and the IT vendor sales representative.  One of the best descriptions of the complex persona that is the IT engineer is The Nerd Handbook.    IT engineers look at the world as an ever unfolding flow chart of logical constructs built on top of more logical constructs.  They are constantly learning and building.  They prioritize human interactions based on a peer level of technical appreciation and comprehension.  If someone isn’t at their level of knowledge on the subject at hand, the value of the exchange diminishes rapidly in their mind.  On the other hand, the Vendor Sales Representative or as I’ve affectionately relabeled as “Vendor Sales Cheese”, as viewed through the IT engineer lens, couldn’t be worth even a nod in the conversation spectrum.  If you align yourself more with the IT engineering mindset, I bet you are getting ready to HTTP 302 yourself off this article and on to something more technical.  I beg you to continue reading in the hopes I can influence you to consider a logical argument for the value of the Vendor Sales Cheese in your technical and/or management function.

So, as a typical IT engineer or engineering manager, your initial interactions with the Vendor Sales Cheese have you thinking: “This person is way too positive and friendly.  That sure is a slick and way too shinny suit.  I need to get outta this conversation and back to my keyboard ASAP.”  Yes, the Vendor Sales Cheese meets new people every fifteen minutes of every day.  Those people could be the tier one HelpDesk technician or the president of the company.  Hence, they error on the side of potentially meeting the president and bust out the shinny suit.  In meeting people, they need to quickly determine your role in the customer vendor relationship ASAP since there is going to be someone new to meet in another fifteen minutes.  Thoughts going through the Vendor Sales Cheese’s mind:

• How do you align in the organization against the product or service the Vendor Sales Cheese represents?
• Are you an end user that is going to be a source of complaints?
• Are you a decision influencer that won’t make the final purchase decision but could influence the decision maker and possibly tank the deal?
• Or are you’re the golden role, the decision maker that is the person between the Vendor Sales Cheese and closing the deal to get the big compensation bonus?

The Vendor Sales Cheese is trying to determine this as quickly as possible in the limited interaction time they are given.

Sure, you can return to the safety of your keyboard and the logical and controlled in order to avoid the seemingly unpleasant and awkward conversation.  But is another five minutes of conversation really going to kill you?  My recommendation is make this five minutes tactically productive by immediately describing your role within the organization and how it aligns with the product or service the Vendor Sales Cheese represents:

IT Engineer: “Hi, I’m Bob and I am the lead engineer in ABC Company that has the job of taking your FlimFlam software product and cramming it into our enterprise IT environment.  I can’t sign a PO and can’t buy anything.  But, when there is a tough problem with the FlimFlam software here, I get the call.  I’ve been working with it for X years.  So when I need tech support, I don’t need the 1-800 number level 1 tech.  I need access to the guy who, like me, knows how FlimFlam works inside and out.  How do I get that tech access so I don’t waste your company’s time?”  (Note the clever use of language to suck the “vsc” into the need to solve a problem for his company and help a customer at the same time.  How can the “vsc” resist this?)

IT Manager: “Hi, I’m Sally and I am the manager over the team that integrates your FlimFlam software with the rest of the technology here at ABC Company.  Let me start with the fact that I am not the guy that signs the PO, but I have the Director’s ear does.  We’ve had great success with FlimFlam but we know there is plenty of competition in this product space.  My biggest challenge with your company is X.  What is the best way to improve the X situation?”  (Again, sucking the “vsc” in by creating a scenario he/she can’t possibly walk away from since they are ever so relationship positive focused)

For the IT engineer, you have given the Vendor Sales Cheese exactly what they need to know:

• Bob = tech guy at ABC Company that can sing the praises of FlimFlam or make a lot of noise when we drop the ball failing to supporting his priority support needs.  Check.

For the IT manager, the Vendor Sales Cheese knows:

• Sally = manager at ABC Company that shouldn’t get the loge tickets to Sunday’s game at the stadium, but he needs some above average attention because she could tank the current/next deal by pitching to the VP/Director/Other that another company with a competing product could be integrated quicker/faster/cheaper is giving her more respect and support.  Check.

Ok, you are scratching your head … “ok, I see how the stage has been set for some tactical value from this Vendor Sales Cheese exchange, but what does this really do for me?  Doesn’t this just lead to more annoying conversation?”  I’ll dive into this value proposition in the next article with more MidWestern IT perspectives on the topic of the “Role of the Sales Rep” in the spectrum of vendor management.

Related posts:

1. Vendor Management – Part 7 – Vendor Service Integration Challenges Continued
2. Vendor Management – Part 6 – Vendor Service Integration Challenges
3. Vendor Management – Part 5 – More on Who Owns the Relationship

Integration going South? Time to call the Vendor Sales Cheese!

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

1. Vendor Service Integration Challenges

In the previous article, I suggested some approaches to consider as the project is underway to integrate the vendor’s service with you and your team’s technology service.  This article will explore considerations once you are in the throws of integration.

So, you have your prototyping working to reduce the unknowns associated with how to get the two disparate technologies functionally working together.  You also have your “spaghetti infrastructure” in place to reduce the risk of negative impacts to your service’s ability to continue to perform for existing needs as well as supporting the new vendor integration.  Finally, you have your “vendor simulator” setup to conduct various permutations of performance testing scenarios between you and your team’s service and the vendor’s service.  So what else do you need?

In parallel to all of the above rather technical risk mitigation techniques, you need an additional management tool to address adverse scenarios that will inevitably pop up randomly throughout the integration project.  The tool I am referring to is a thorough understanding of the vendor’s organizational chart.  Specifically, you are looking to identify the following roles within the vendor’s organization:

• Relationship Manager assigned to your company

This is the individual whose job it is to ensure that your company is happy at all times with the service the vendor is providing to your company.  This is an individual who you can leverage any time you believe additional support from the vendor would allow for accomplishing things more efficiently and effectively.  If things are trending poorly and you have exhausted the contacts and procedures to get support from the vendor, don’t hesitate to contact this individual.  They should react immediately to your needs, especially if you can summarize your thorough attempt to use the normal channels and your coming up proverbially empty.  On word of caution, make sure you exhaust the established parameters for vendor resource and assistance engagement.  If you call on this person at every bump in the road, you may get high touch service immediately, but you will quickly be labeled as a “hyper escalator” and your high priority requests will be interpreted as low priority.  This is indeed a balance, for if you don’t leverage this individual and things come to a head down the road, the vendor has an easy out for providing poor service:

Vendor Sales Cheese <role defined later in this article>: “I understand you are frustrated.  You do know you can contact Bob for all your customer service needs.  He is your Relationship Manager dedicated to you and from what I understand; no one reached out to Bob.  If you do contact Bob, he will make sure you are getting the needed service and support from our organization …”

Regardless of your level of credible frustration, you didn’t take advantage of the escalatory options at your disposal from the vendor:

• Senior Technical Person

This is the role you need to find quickly.  The vendor will most likely try to shield this person.  Why shield?  Well, if every customer knew how to get a hold of Senior Technical Person, they would for their every need because they get the real, direct and reliable technical answer quickly.  But like every technical organization, these roles are few and far between and worth protecting so only the most critical problems get into their hands.  This being said, you need to quickly identify this person and establish a back channel communications mechanism between your senior tech person and the vendor senior tech person.  Similar to the Relationship Manager role, this is a “don’t use unless you absolutely have too” communications route.  Make sure you coach your senior tech resource to play along with only contacting their peer at the vendor when the regular channels breakdown.  On the flip side, the vendor senior technical resource will appreciate being able to speak with a technical peer within the customer’s organization.  Just like your senior tech resource, the vendor’s equivalent will be frustrated with the problems that are beneath them to solve crossing their desk.  They will find it refreshing to speak with someone who shares their priority attributed to technical excellence and will provide top notch support when engaged as such.  This back channel communication mechanism can be exceedingly valuable when milestone dates are looming and confounding technical problems block forward progress.

• Vendor Project Manager

Assuming the integration effort is of a scale that involves more than a few humans completing a few tasks to integrate technologies, there will most likely be a project manager within your organization (see other series of articles on interacting within your project management framework for IT Engineers and IT Managers ).  On the vendor side, they will most likely have a Vendor Project Manager role. This role keeps the vendor resource moving forward within the vendor’s organization in parallel with your organization’s project manager.  Don’t be quick to conclude that your company’s project manager will work effectively with their peer within the vendor’s organization.  It is best to assume your project manager will fail to grasp the nuances of the technical tasks and dependencies and thus fail to get critical information passed back and forth between the two organizations successfully.  I am not suggesting you need to absorb the project management function within yourself or your team, rather, develop a communication approach that takes this miscommunication potential into account.  For example, consider adding the Vendor Project Manager as a carbon copy to all emails that make even the slightest reference to questions, answers, tasks or dependencies that involve the vendor.  For example, pass on mentioning that Bob on your team needs to take the internal account access form to the access granters for Bob to get access to that new server he doesn’t have access to yet.  This doesn’t involve the vendor in the slightest.  But, if the vendor is expecting a copy of the contents of a configuration file on that new server, then by all means add the Vendor Project Manager to the cc line of the email to your company’s project manager.  Why this seemingly superfluous communication of ancillary internal access granting minutia?  The perception becomes more clear that the vendor is waiting on the configuration file snapshot, which your team needs to provide, yet clearly can’t until access is granted to Bob.  Without this documented clarity, the Vendor Project Manager can send a heated email to your project manager claiming your company is holding up the project due to not providing the configuration file.  Your project manager, under duress, may be quick to claim you and your team are the hold up within your company.  Without this example email, you have to get on the defensive, especially to the classic “surprised and confused” response from the under duress project manager:

Company Project Manager: “What?  You needed server access in order to send over the configuration file that has been holding everyone up?  I’m surprised that you needed this access and I’m confused that you didn’t tell me about needing it.  For had I known you needed this access, I would have worked to get you that access ASAP.  Since I didn’t know about it, I couldn’t have known that this was a barrier to progress …”

The email including letting the Vendor Project Manager know all of the dependencies in order to provide the deliverable makes it obvious the communication breakdown is outside you and your team so you survive unscathed and don’t have to invest energy in forming a tactical defense or erect proverbial blame shields.

• Vendor Sales Cheese

Similar to the Relationship Manager role, you need to identify the Vendor Sales Cheese or salesperson that stands to loose big in the compensation category if the customer gets frustrated and doesn’t close the deal for him or her to score their bonus.  Depending on the vendor, the Vendor Sales Cheese or the Relationship Manager maybe the same person.  But in the event they are different people, make sure you have a clear understanding of their roles and follow the below sequence for every vendor request, only proceeding to the next step if the prior step failed to generate expected results:

1. Normal communication route (support ticket, email to vendor support mailbox, etc.) keeping the Vendor Project Manager copied on communications
2. Vendor Project Manager directly
3. Vendor Relationship Manager
4. Vendor Sales Cheese

Lastly, knowing who within your company owns the relationship with this vendor, as described in previous articles,  is also important so when you get a sense the communications are getting more heated as you are moving from the normal communication route, past the Vendor Project Manager over to the Vendor Relationship Manager and Vendor Sales Cheese, you can bring the vendor relationship owner into the mix when their vendor is at risk of causing the integration to go off track or miss a major project milestone.  If the integration project is trending in this direction, you will want to have all of the communications documented and reflecting a logical progression through the escalation path confirming to all that you and your team took every opportunity to engage the correct resources to not be the cause of the pending failure.

Knowing the contact information for all the vendor players identified in the roles above will allow you and your team to effectively manage the communications and escalatory options between your company and the vendor’s organization.  Relying on others puts you and your team at risk for being perceived as the service provider that is holding up the integration project and diverts focus from getting the technical integration completed.  The next article will dive deeper into more MidWestern IT perspectives on the topic of the “Role of the Sales Rep” in the spectrum of vendor management.

Related posts:

1. Vendor Management – Part 6 – Vendor Service Integration Challenges
2. Vendor Management – Part 5 – More on Who Owns the Relationship
3. Vendor Management – Part 4 – More on Who Owns the Relationship

Vendor Management Categories

• Vendor Service Integration Challenges

In the previous article, I described aspects the vendor due diligence process and mitigating technology integration risks with a vendor after a contract is signed with the vendor and  you and your team didn’t get full participation in the vendor selection process.   In this article, I suggest some approaches to consider as the project is underway to integrate the vendor’s service with you and your team’s technology service.

In the previous article, I started to hint at ways to accommodate the usually, less than optimal way one becomes part of a vendor integration effort with my “spaghetti infrastructure” example.  In short, “spaghetti infrastructure” refers to looking to add sub par infrastructure extensions in order to accommodate the variable production volume/usage patterns of this new vendor integrated service to your existing technology platform or service for which you and your team are responsible.  I also mentioned the concept of using a technology prototype to reduce the risk of the technical variables related to integrating two separately owned and designed technology frameworks.  Below is an additional vendor integration challenge and a way to attack this challenge head on:

• Need to confirm the integrated solution will perform to production expectations

“Spaghetti infrastructure” and prototypes are tools to reduce the unknowns associated with integrating you and your team’s technology service with a vendor’s technology service.  But how does one address the question: “Will this integrated solution perform to the level needed to meet production usage SLAs and response times?”  Consider the development of a “vendor simulator”.

What is a “vendor simulator” do you say?  A “vendor simulator” represents all of the integration touch points between you and your team’s technology service and the vendor’s.  Expecting the vendor to have a dedicated test environment that you can use at a moments notice that is pre-populated with synthetic transactions that reflect the sample data you have within you and your team’s test environment including predictive data that runs the gamut of possible query responses is rather unrealistic.  Thus, if you invest some time and energy in building an application or service that can mimic the inputs and corresponding outputs of the vendor’s service, then you have a tool to test your service prior to engaging the vendor’s testing resources.  Below is a simple, high level graphical example of simplistic company/vendor integration architecture:

Note: The above architecture is exceedingly simple.  In real world architectures, there could be many components and technologies between you and your team’s service and the vendor’s technology.

With the above simplistic architecture in mind, below is an example use case scenario to setup for our “vendor simulator”:

Use Case Example #1

1. Create request transaction to pass to the vendor that includes:
   1. Authentication/Authorization information to establish security context between you and your team’s service and the vendor’s service
   2. A “customer identifier” that exists within the vendor’s service
   3. A “Get the last ten transactions” request
2. Request, via the vendor gateway, the above transaction be processed by the vendor
3. Receive a synchronous response from the vendor, for the provided customer identifier, for the ten strings of text that represent this customer’s most recent ten transactions recorded in the vendor’s service
4. Close the connection with the vendor’s service

The above use case could represent a potential real world scenario of a company web site that allows their customers to view all transactions conducted against all services the company offers the customer.  In this case, a particular company product has been “outsourced” to a vendor, but the company desires to have the company web site show the outsourced product transactions within the list of all transactions the customer has performed using all their company enrolled products.

If there were only 1,000 customers involved, the production volumes would be easy to incorporate within a systems design.  But what if there were 100,000?  Or 1,000,000?  Or even 10,000,000?  In the later cases, the production volumes are indeed significant and require a properly designed, optimized and tuned solution.  So where should the “vendor simulator” architecturally exist?  See the below graphic:

Ideally, your “vendor simulator” should exist within your technology framework as close to the end point where your network “links” or “touches” the vendor’s network.  Sure, someone might suggest the “vendor simulator” should hang off the edge firewall in the graphic, but the latency that firewall would add to the simulated request round trips is negligible in the grand scheme of our simulation need.

Great, we have found the ideal location to insert our “vendor simulator”, now what should the “vendor simulator” actually do?

Using our Example Use Case #1 above, the “vendor simulator” would be built to do the following:

1. Accept the first transaction that includes authentication and authorization data and the customer identifier and the request for the 10 transactions
   1. Note: if you would find value from implementing some validation scheme the vendor has indicated they would perform on transactions, feel free to replicate that validation here.  You might find in implementing their validation, your construction of the message payload is faulty and thus you can correct before interacting with the vendor
2. Allow for a random yet within a minimum/maximum range delay latency for the processing of the request within the vendor’s technology and the communications between your company and the vendor
3. Provide 10 artificial transactions to return to you and your team’s service that consist of test data that represents a generous sampling of the plausible data the vendor’s service would return.
4. Close out the request

Note on step 2:  The goal of this step is to provide an ability to simulate the latency or slowness of the network to and from your company and the vendor as well as the time it takes the vendor to receive, validate, process, format and compile the results and return them to your company.  By making those latency elements configurable, specifically identifying a minimum and maximum range and then randomly picking within the ranges per test transaction, the “vendor simulator” can get close to reflecting real world production interactions.

With the “vendor simulator” configured as above, you can run any number of system tests that include interacting with the vendor yet there is no need to engage the vendor for each and every test.

In addition, you can change one variable at a time within the “vendor simulator” to determine how you and your team’s service will perform and/or react to the change in behavior of the “vendor simulator”.  Try having the “vendor simulator” perform close to wire speed.  You will be able to see you your system responds to transactions being requested and completed extremely quickly.  Next, try having the “vendor simulator” perform extremely slowly by greatly extending the minimum simulator response times.  Does your system start backing up transactions as the “vendor simulator” fails to process their requests promptly?  Additionally, create a huge time delta between the minimum and maximum “vendor simulator” response times.  This simulates the vendor having some systems issues where they can process transactions, but their processing is erratic as if they are not having a systems outage, rather, capacity issues that cause requests to be processed with great variety in the response times.  Can you service, under load, successfully “smooth” the variability created by the vendor or does your system begin to back up transactions, then flush them out periodically in parallel to the “vendor simulator”?

All of the above testing data will allow you to tweak and tune you and your team’s service’s operating parameters to achieve the most efficient systems configuration to handle the widest variety of vendor performance scenarios without having to have the vendor initially involved.

Next steps?

When you are confident your system is optimally tuned to handle the chaotic responses from your “vendor simulator”, proceed to engage your vendor in formal integration testing and you will have the ability to relate the combined company and vendor testing results with your “vendor simulator” experience.  Based on the results, you should be able to see problems the vendor is experiencing based on the simulated problems your “vendor simulator” generated for you and your team’s service.  See a performance pattern you didn’t see before?  Go back to the “vendor simulator” and try additional configurations that achieve the performance pattern you experienced with the vendor and proceed to tune and tweak you and your team’s service to handle this scenario in a more efficient manner.

Whew, now you are in production and things seem to be working a-ok, throw the “vendor simulator” away, right?

Absolutely not!  Now you have the great opportunity to observe the production usage patterns and configure the “vendor simulator” to replicate those patterns in your test environment.  Once you have replicated the production patterns in test, you can now perform system maintenance or upgrades and leverage the “vendor simulator” again to predict how your system changes will impact the production vendor integration with a higher degree of confidence.

One caution, the “vendor simulator” isn’t a replacement for testing with your vendor partner.  Rather, it is an efficiency tool that can help rule out problems prior to spending the time and energy (and money depending on your vendor contract arrangement for testing) spinning up all the resources within your company and the vendor’s company to conduct full systems integration testing.

Although a pre-signed contract and delayed vendor integration project involvement can create some challenges, consider some of these sub optimal but success trending options.  You may want to create “vendor simulator” regardless of you ability, up front, to build into the project schedule, a comfortable testing exercise.  The next article will dive into more MidWestern IT perspectives on the topic of “Vendor Service Integration Challenges” in addition to this article.

Related posts:

1. Vendor Management – Part 5 – More on Who Owns the Relationship
2. Vendor Management – Part 4 – More on Who Owns the Relationship
3. Vendor Management – Part 3 – More on Who Owns the Relationship

"Spaghetti Infrastructure" can save the day!

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

In the previous article, I described aspects the vendor due diligence process and mitigating technology integration risks with a vendor prior to signing a contract with the vendor. In this article, I suggest some approaches to consider when the partnership between the business and IT is weak and a contract for services has been signed with the vendor without full IT due diligence participation prior.

Has the Contract been Signed? Yes!

Let us be honest, in a perfect world, all critical stakeholders would be engaged at the onset of the vendor selection process. A disciplined procurement process would unfold measuring and weighting all the pros and cons of each solution. Internally transparent decision matrices would ultimately reflect a cross-functional consensus based vendor selection decision. MidWest IT is definitely not a perfect world. Many factors, most not based on logic or metrics, rather emotion, drive the vendor selection process.

If the contract has already been signed, the rules of engagement are becoming established and the boundaries by which you get to interact with the vendor are becoming even more defined. Unfortunately, defined in the sense that integration expectations have already been set, but the specific details are unknown. If the contract has been signed and work has been underway for some time but you have been recently engaged, you are not going to be very popular when you pop up with:

You: “Oh, we have to integrate our technology with Vendor X to provide that? We are going to have to buy all new servers and upgrade that old version of the FlimFlam platform to 9.0! and … and …”

Budgets have been set, integration costs have been projected and expected revenues already sold to the organization. Although not popular, you have to be somewhat transparent in how the vendor integration will put stress on you and your team’s technical services and how to mitigate that stress. Yes, in my experience in shared IT services, this is a rather frequent occurrence. An effort is underway without involving all the stakeholders at the onset. As you are identified as a stakeholder down stream in the project process, you didn’t get to participate early when including your service impacts into the mix would have resulted in a more rational inclusion of your service extension needs within the effort’s requirements framework. Not to fear, there are some options to allow you to mitigate the risks to you and your team’s service.

Keys to improved success in this hypothetical example would be to smooth the impact in proportion to the usage ramp up. Is the ramp up slow enough to allow use of your service in its current configuration but plan for the next budget cycle to incorporate the purchase of additional capacity to support this service growth? The spreading of the impact to your service over budget cycles allows the initial implementation to continue as planned and essentially pushes the “problem” of the need for additional capacity to a corporate exercise that expects to digest investments in capacity to support continued growth.

Another example of improving the chances of a successful outcome without appearing to need significant unplanned investment on meeting the need is to look to leverage the ever declining cost of infrastructure. Especially with today’s service oriented architecture flexibility, is it possible to add additional infrastructure capacity on the cheap? Is there virtual capacity that you can take advantage of now and then plan to fold your virtual architecture extension back into your overall architecture direction? Are there older, decommissioned servers that, not the latest and greatest, could absorb the initial vendor integration work and usage projections and again, allow for folding back into your overall architectural direction in the future?

Yes, the cost of “spaghetti infrastructure” needs to be weighed against the benefits of architecturally separating the design, development, testing and performance tuning from your existing service. Plus, experience suggests that during the integration and testing phase before deployment, one gets a projection of the production usage pattern but rarely is that projection spot on. More than likely, there are big swings in production usage from those estimated from the integration project. Anywhere from way fewer users performing transactions to a huge spike in volume based on pent up user demand. Your “spaghetti infrastructure” investment can pay off with real production workload pattern data allowing you to strategize on a more strategic and holistic architecture that can support the current workload and this new workload. Don’t be too quick to dismiss this option as a step back on your architectural roadmap. Rather, consider the ability to gather production data as a way to strengthen your architectural roadmap.

Although a pre-signed contract and delayed vendor integration project involvement can create some challenges, consider some of these sub optimal but success trending options. The next article will dive into the MidWestern IT perspective on the topic of “Vendor Service Integration Challenges” touched on at the end of this article.

Related posts:

1. Vendor Management – Part 4 – More on Who Owns the Relationship
2. Vendor Management – Part 3 – More on Who Owns the Relationship
3. Vendor Management – Part 2 – Who Owns the Relationship

What to do before the contract is signed

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

In the previous article, I described aspects of the differences when there is a strong compared to a weak partnership between the business and IT. In this article, I suggest some approaches to consider when the partnership is weak and how to get injected into the vendor due diligence process in order to improve the chances the company will pick the better vendor when it comes to technical service integration.

Whether it is due to an inability for the business to successfully navigate IT, lack of experience that suggests IT needs to be involved right from the beginning of the due diligence process or a slick vendor sales pitch that conveys a “no brainer” technical integration path, often times IT isn’t engaged early enough in the selection process. Below are some key questions that, once answered, will help suggest an aggressive engagement process with the business to aide in integrating the vendor’s technology with you and your team’s service.

Has the Contract been Signed? Not Yet!

If the contract hasn’t been signed, find every opportunity to get yourself injected in the vendor procurement process. What is your goal after injection? Cook the business case so the work gets done in house. No, rather, gather as much data regarding projections for business service attributes such as:

• Volume of discrete business transactions
  Expected integrated systems usage patterns
  Technology touch points between the vendor and the company
  Sales projections to determine licensing and capacity needs

Once gathered, even if not complete to the level of detail desired, conduct an assessment of the impact of this additional service integrating with your existing technology platform. If you identify a material impact such as:

• Volume to drive need for additional capacity
• Customer sales predictions exceed current year over year licensing
• Vendor platform/integration interface requires an upgrade/investment in extending your service to interface with the vendor’s platform/integration interface
• New integration pattern not proven in production
• Experimental technology such as an unapproved industry standard clear deviation from an industry best proactive

Document it and associated risk mitigation steps and get into the vendor selection or procurements process. Wait a minute, this is sounding like a “CYA” exercise? In the extreme interpretation, maybe, but I argue this is plain good management sense. As an IT manager faced with putting your career and reputation at risk for confirming you and your team can support integrating with a vendor for potentially a 3 to 5 year service agreement, if not longer, based on the limited, mostly verbal, interactions with the leading vendor candidate. Also, note the combination of both noting the concerns and documenting steps to reduce or eliminate those concerns.

An example comes to mind as to what I am suggesting. Consider a hypothetical example:

Consider a business service that involves a vendor hosting a web site that allows the business customers to sign up online and view a summary of transactions (purchases, shipments, financial money flows, widgets coming off an assembly line, etc.):

• The vendor has an integration pattern of receiving transaction batch data at night, processing and posting for users to view the next day
• The business wants this service, but with a more real-time data flow. As the company completes a transaction, it wants to push the transaction attribute data to the vendor and have them post it as soon as they get it.
• Your IT service within the business has the ability to aggregate business transaction data as it occurs and creates batch files nightly to be posted to other systems.
• Both your service and then vendor’s service have the capability to interact more real time with minor service extensions, but you both lack the real world, production experience to confidently mutual subscribe to an integration pattern that has proven to work in the past

Option A – Charge Off and Build

Mutually agree to support the business need for real time transaction postings. Support an implementation date that includes some integration testing prior to production go-live.

Risk? Business starts the marketing engine to deliver a new product or solution to customers by the go live date. You and the vendor as well start doing the real hands on solution development and you realize the go-live date is unrealistic. Unrealistic due to a better understanding of how both systems need to change, support the new real time feature set and not impact existing system usage patterns. Next step? Figure out how to tell the business they need to allot more time for systems integration, delay the marketing engine, and pray your new data estimates are going to stick.

Option B – Charge Off to a Milestone

Mutually agree to build an integration prototype or proof of concept that achieves specific technical milestones that allow both IT and the vendor to more confidently predict the final go live implementation date. Reach a contract level understanding that these specific milestones will be achieved and the costs associated with achieving them.

Risk? Risk is significantly reduced as the time invested in the proof of concept technology spills directly into final solution development with the majority of the unknowns converted to knowns. The business doesn’t know exactly the go live date initially, but they know they will get a date in short order that they can more aggressively plan for with higher confidence it won’t slip.

Both the vendor and the business may need some heavy convincing this is a more risk adverse approach that nets all parties a higher degree of confidence in dates and investments. What are other serendipitous outcomes might be experienced? I would bet even if the proof of concept is exceedingly technical in nature, the business might find some of their assumptions on how the final business solution is implemented will be invalidated as they see the results of the proof of concept work.

Continuing this MidWestern IT perspective on the topic of “Who Owns the Relationship?” in the next article; what to do if the contract has been signed?

Related posts:

1. Vendor Management – Part 3 – More on Who Owns the Relationship
2. Vendor Management – Part 2 – Who Owns the Relationship
3. Vendor Management – Part 1 – The Intro

Does IT have a strong or weak partnership with the Business?

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

In the previous article, I used an example of a company CIO bringing in a software vendor with the CIO’s brother as a majority owner of the software company and how to navigate the need for technical assistance from the vendor to get their product installed successfully by your team.  The notion of needing to investigate and understand the non-technical dynamics of who owns the vendor relationship is critical to avoid a potentially career limiting exchange involving vendor bashing or venting frustrations too openly.

Continuing in the theme of understanding who owns the vendor relationship, especially when you or your immediate management don’t, what other dynamics come into play?  Another challenging dynamic is when the business owns the relationship yet IT needs significant interaction with the vendor to establish the vendor’s service for the business.  Starting from the beginning during the vendor selection process, depending on the business plus IT partnership, the vendor selected will have a significant impact on how smoothly the service will be implemented.

Strong Partnership between IT and Business

If the intra-department partnership is strong and thus IT has an equal seat at the vendor selection table, then there is a greater potential for the vendor selected will include critical due diligence around the vendor’s IT strength and competency.  To determine the vendor’s capability to smoothly integrate the service, IT needs an efficient yet thorough due diligence process to quickly understand if the vendor successfully integrated their service with another customer recently that matches key attributes of your technology framework.  The vendor that can site examples without prompting of integration challenges and how they over came those challenges that closely match your anticipated challenges given your technology frameworks is in a stronger position.  A vendor that can’t cite examples with confidence and clarity will most likely be learning “on the job” with your company.  Note, not all “learning on the job” situations are negative.  In a future article I’ll describe a “strategic customer” relationship that turns learning on the job into a significant win for both company and vendor.

Weak Partnership between IT and Business

If the intra-department partnership is weak, the business will most likely engage vendors and make a product or service selection based more strongly on their goals and objectives and not consider the IT integration costs heavily in the due diligence process.  The business could be conducting the due diligence process and not have a way to engage IT partners easily due to how IT is structured within the organization.  Or, the business could be specifically down playing the role IT needs to play in the service integration effort due to lack of service implementation experience and just how important IT’s role is in that success.  Additionally, the business may be lulled into a sense of artificial comfort by the vendor’s slick sales pitches that create the impression the IT side of things is a “no brainer” and they’ve done this integration in the recent past with countless customers with nothing but success.

Sounds like the strong partnership between the business and IT fosters more open communication in an effort to more equally way the IT costs in with the business integration costs.  How can one leverage techniques to generate conversation when the partnership isn’t strong?  Continuing this MidWestern IT [] perspective on the topic of “Who Owns the Relationship?” in the next article.

Related posts:

1. Vendor Management – Part 2 – Who Owns the Relationship
2. Vendor Management – Part 1 – The Intro

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

Is build versus buy like pushing your team off a cliff?

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.

As I reflect on the topic of vendor management, I tried to break down vendor management into subcategories.  For each subcategory below, I plan to dedicate an article or two to drill down into the nuances I’ve come across, what techniques worked for me and what didn’t turn out so well:

Vendor Management Categories

• Who Owns the Relationship
• Vendor Service Integration Challenges
• Role of the Sales Rep.
• Sales Cycle and Pricing
• How to Leverage Tech Support
• Product Versioning and the Upgrade Cycle
• Cost of Swapping versus Maintaining
• Product Selection/Feature Evaluation
• Being a Strategic Customer

Why spend so much time covering this topic?  Don’t MidWestern companies pay decent money to vendors for technology they can install, get the features they need cheaper and more robustly than building themselves and pay a monthly/yearly fee for this great benefit without further worry?  Well, technically, on paper, yes, but in my experience, it has never worked out so simply.

As a typical IT manager in a MidWestern company that primarily leverages IT for operational efficiency gains rather than direct core technical product offerings (see this article for more on this IT conceptual nuance), there are plenty of business cases that tip the build versus buy decision towards the buy.  If the business case says buy, then buy means vendor.  And believe me, the minute you start asking the “hey, does someone make a technology product that does X” question, there will be thirty if not forty different vendors all clamoring to sell you on their product that does X and for the cheapest price you can find anywhere.  Now nailing down that price is quite a challenge, but more on that aspect in a future article.

A point of clarification when I say “vendor” and “buy” what I am referring to is more directly the aspect of purchasing a software or infrastructure technology that you and your team have some hand in installing, configuring and/or supporting it’s operations going forward.  An example would be database products from companies such as IBM, Oracle or Microsoft.  You are clearly looking to leverage the expertise these companies have invested in their product over the years rather than build your own database solution from scratch.  An example of what would not fit in this category would be a vendor/product relationship where a majority if not all of the IT services are outsourced to the vendor.  “Software as a Service” models would fit in this “outsourced to the vendor” category or effectively any web site that the company leverages a vendor to provide the complete business service with little to no integration or direct support from in-house IT.

Cloud computing [definition: Wikipedia] is a recently maturing technology offering that is blurring the lines a bit between, say, buying “software” and install it on your “box”.  The “software” may be a portion of the overall software application that supports the business need that happens to be hosted by a third party both in terms of the platform as well as the business logic/rules that are being executed as part of the overall business solution.  The “box” may be from a logical interaction perspective the same as a server powered, networked and operating within your company’s data center but in reality, a virtual server powered in the vendor’s datacenter and connected to your company’s network via the Internet or similar arrangement.  Cloud computing is rapidly gaining attention as a viable and cost effective solution to “outsourcing” more IT functionality to a vendor while continuing to maintain control over core business differentiated IT services and pushing off control of commodity/non-core business services to third parties.  The concept involves moving more non-core business services “to the cloud” allowing cloud vendors to focus on up time, reliability, disaster recovery, capacity and performance at a price point lower than in-house since it is spread across all the customers of the cloud.  The basic concepts of vendor management still apply to cloud environments.  I encourage readers considering cloud computing to continue to evaluate the growing experiences of peers as cloud computing grows and matures from its current state.

So, let’s dive into the realm of vendor management from a MidWestern IT perspective starting with the topic of “Who Owns the Relationship?” in the next article.

No related posts.