Search
Blog
« Estimating testing using spreadsheets | Main | Some questions to think about as you plan your workshop… »
Thursday
Nov152007

I think I'm ready to close the dialog...

In my current role, I deal a lot with vendors who provide testing resources and services. Let me start by saying I think most vendors (at least the ones I interact with), provide a good product. I am generally happy with both of the large vendors I work with, and with several of the smaller vendors. For some background, most of my requests are for products and services around automation and performance testing.

However, given my role I get to participate in a number of meetings where vendors try to sell me on completely outsourcing a function (like performance testing) or on bringing in consultants to help me "develop the right implementation model and frameworks" (like with automation). I've pulled together some observations around how these discussions normally go, and I have some feedback for vendors who hold these conversations with people in my role.

The magical letters ROI don't instantly sell me your product
I'm a fan of understanding return on investment for automation and performance. I think I understand how to do that for my current context, and for a couple of past contexts I've worked in. My current boss, whom I respect more then anyone I've worked for in the past, holds me accountable for understanding our return on investment for automation and performance. I try to have regular discussions around return on investment with the application teams we support.

Having said that, every time I hear "let's take a look at the ROI," or "it will increase your ROI," or "all we need to do is use the ROI calculator" some little part of me shrivels up and dies. It drives me insane. I refuse to believe that for products as complex and involved as automation and performance testing services (where you need to understand infrastructure, application architecture, business and use cases, deployment models, culture, risk tolerance, and the other aspects of the design, development, and testing taking place for a project) that you can so easily capture the ROI. If it were that easy you wouldn't be talking to me about it.

In all of the conversations I've had, the term ROI comes up frequently. I can't bring myself to challenge it, because I don’t want that to become the focus of the conversations (not really productive – regardless of how happy it would make me). What I'm looking to you for is for solutions to problems, not for you to help me sell my role or organization upwards to my management. I don't need your help to build the business case for the role I've been given. If I do, I hope my manager either fires me or gets me the training I need to be effective in my role.

"Additional value add" doesn't actually tell me anything about the value you add
A close second to ROI in terms of frequency of use is the term "additional value add." I don't even know what that means. Well, I know what it means from a marketing perspective – much like the term "best practice." I get it. I'm not completely dense. But I don't know what it means to me in the context it's used in the discussions.

How do they even know what would be valuable to me? In one conversation I listened to a vendor for 20 minutes discuss an approach to automation that I told them I didn't think added much value. Then they proceeded to discuss that approach and the "value added" solutions they had created to allow that work to be done faster and cheaper. If I don't think it's valuable, doing it faster and cheaper still doesn't add value. There might be a divide by zero error in there somewhere.

It's a superfluous phrase (or non-value add – if you will). I'm tempted to ask, "What services or products do you provide that don't add value? I just want to know so I can be sure I'm not paying for any of those." I hope all your services add value. If they don't, don't offer them. When you use terms like "additional value add," in my mind you become the used car salesman of your industry.

Opening a "dialog" doesn't solve my problems
On a final note, the last thing I want to do is "open a dialog" about my problems. If I put a specific problem in front of you, I'm interested in specific solutions. Put the person in front of me who can help me understand what we need to do, and what you can do to help. If you're not that person, I'll find another vendor who is. I don't have time to dialog, I have problems.

For the most part, I'm generally skeptic that you know more about my problems then I do; so you have little credibility to begin with. Telling me you want to drag out high-level conversations rather then talk to me about specific problems is not going to get you more of my time. The best vendors I've seen ask, "What is your biggest problem that we are best positioned to help you solve?" Then they either deliver a solution or help you deliver a solution. If the delivery was successful, they then ask, "How can we best help you solve other problems?" That's when the dialog begins. They now have credibility and are worth me giving them my valuable time.

Deliver something before you talk to me about what you can deliver. Delivery is hard to do. If I see you do it once, I'm more inclined to think you can do it again. Once I think you can deliver, I'll talk with you as much as you want me to.

Reader Comments (1)

Hi Mike,

This is good post ... I have been on the other side (trying to sell IT solutions for testing) for last few years.

You mentioned about "Best practices" (or it's perils) - some customers do give weightage to these and are willing to talk only if we show some "best practices" that we provided to other clients in the same space. Then it becomes a "context" free situation.

They ask "Tell me your best practices, tools, ROI models etc" mainly as we begin "dialog".

Unlike in your case, it typically an IT servies provider gets an entry or opportunity to discuss only when they display their "General" skills.

IT services industry in general, has been tuned to or used to give solutions without knowing exact customer problem in the form of best practices. It had worked for them, seems to work and hence they approach it from that angle.

Coming to Automation specifically - Majority of IT thinks that automation means cut down in test costs. Achieving ever decreasing Testing costs is typically is top agenda on every CIO's list.

If the industry approaches automation as sole means of cutting down testing costs, IT services vendors obviously would need to project their automation capabilities to address that need ...

I am yet to hear a client who would like to initiate automation for other purposes like enhanced test coverage, extend manual testing capabilities etc other than "tool to cut testing costs"

Shrini

November 17, 2007 | Unregistered CommenterShrini

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
All HTML will be escaped. Textile formatting is allowed.