Midwest IT Survival

"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.

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?

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.

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.