Quardev recently posted an article I wrote on building trust as a consultant. The main points include:
I really enjoyed writing this short article and wanted to thank Jon Bach for asking. He’s someone I’ve grown to trust over the last few years and I’ve learned a lot from him.
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.
It’s been a while since Windows has blue-screened on me. Probably a couple of years actually. The other day I got a blue screen for the first time on my Vaio. When the restart was complete, I was greeted with this priceless gem…
I love that Windows protects me from Microsoft processes…
Someone recently emailed me and asked me about starting their own peer workshop. I have a small amount of experience in the topic. I’ve run a number of IWSTs (a small local workshop) and two WOCs (a longer three-day workshop). I’ve attended many other peer workshops, including WHET, WOPR, WOCT, STMR, STiFS, and AWTA. They are all in some way or another in the LAWST-style.
Here are bits of my reply:
Facilitation
Depending on your personality type, you might be able to facilitate. I don’t know what personality types make good facilitators, I just know not everyone is a good facilitator. If you ever need a facilitator, and your workshop is LAWST-style, there is a good chance AST will provide one for you.
I recommend two books:
- Facilitator’s Guide to Participatory Decision-Making
- How to Run Seminars and Workshops
To get AST sponsorship, follow the LAWST-style and submit an email to the AST VP of Conferences (conference@associationforsoftwaretesting.org). It’s that easy.
Money
Plan on a three-day workshop costing you around $1,500 out of pocket all said and done. You can do it a bit cheaper or a bit more expensive - depending on the market and your connections in that market.
Content
Be clear on your expectations on what you want the outcomes to be. That will help guide your invitations and content selections. Scott Barber has noticed some interesting dynamics on this topic. I hope he posts them as a comment to this post.
Be very clear about what it takes to attend. If it’s invitation only - make it invitation only. Be painfully clear about what that means. Does that mean I can just email you to get an invitation? Say that. This is the largest barrier to entry for people attending. If they feel it’s ‘closed’, they won’t try to come. If they feel it’s only for the ‘elite’, they won’t try to come.
Marketing
Get a website. Right away. Unless you want a small community, you need a public face. WOPR has a great marketing group (Ross, Roland, and Scott) and they do an /excellent/ job at getting new blood into the workshops.
Send the call for participation well in advance. Send it more then once.
Keep a relatively constant stream of communication to your attendees. Send emails 60 day, 30 days, 15 days, and 7 days before the event. Start a YahooGroup following the workshop for veterans.
Struggles
Get ready for rejection. It’s the hardest part. People commit and then they back out at the last minute. I find that the hardest part.
Be ready for people not to publish anything following the workshop. It takes someone special to actually follow up on workshop promises. This is the second hardest part. (I still have outstanding promises to AWTA from January. I have good intentions. It’s hard…)
If you have other tips (many readers of my blog have attended or run their own peer conferences) please feel free to post them.
As a contributing author of more then 30 articles to developerWorks over the last few years, I’m super happy to see that at the 17th Annual Jolt Product Excellence Awards IBM developerWorks received The Jolt Hall of Fame award.
I find the developerWorks editors and technical staff to be both easy and fun to work with. I know what kind of work goes into getting the content out there, and they have a lot of content. And I’m not just an author, I’m also a user.
More information: http://www-03.ibm.com/developerworks/blogs/page/moc?entry=dw_wins_jolt_hall_of