“Don’t write about that,” I’ve been told by several colleagues, when I’ve mentioned that I was working on a post about how best, as the senior technology executive, to negotiate with vendors.  “You’ll give away all your tricks!” they’ve said.

Well, actually, no.  Here’s the main trick: this particular CIO doesn’t have any “tricks”, if by tricks you mean ways to outfox the opposition, or anything else that is best kept secret.  In fact, I’m not a natural avid negotiator. I’m not one of those people who looks forward to buying a new car because of the thrill of haggling with the salesperson.  But I’ve learned over the years how negotiations can best be structured for the optimal outcome.  Like cryptography, where greater obscurity isn’t equivalent to greater security, successful negotiation isn’t dependent on tricks or subterfuge.

I’m quite content to tell any vendor or salesman how I go about negotiating, because doing so doesn’t provide them any kind of advantage.  If anything, it’s beneficial to me and my company that all parties in the negotiation understand clearly the basic principles and approach that I’m using; it cuts a lot of the normal gamesmanship out of the equation.

What I’m about to tell you about negotiating actually strikes me as incredibly obvious. Yet, time and again, I’ve come into a new CTO/CIO role and been astounded at the poor technology deals that were cut by the previous executive: inadequate terms, failure to protect both parties instead of just the vendor, unnecessary and undesirable contractual lock-in.  What happened in most of these cases, as far as I can usually determine, is that the executive in charge got swept away by emotional attachment to a specific solution, and tipped his or her hand. Game over: at that point they were putty in the vendor’s hands. I’ve even seen cases where contracts have completely put the vendor in the driver’s seat of actual implementation, including spending authority, to an unconscionable degree.

Make no mistake: vendors are typically much more experienced and skilled in negotiations than most of the technology executives they deal with.  Achieving excellence in negotiation should therefore be seen as a critical part of the technology executive’s skill portfolio.  But, like finance skills, it’s a skill more honored in the breach than the observance.  Your ability to negotiate well can not only protect your company’s long-term interests, but can actually recoup far more than the equivalent of your annual salary to the bottom line. It’s not uncommon for technology executives at even relatively small companies to negotiate deals worth hundreds of thousands or even millions of dollars of capital and operating expense.

So let’s cut to the “secret”. It boils down to this simple principle: give yourself choices. Identify two, preferably three, viable, affordable, achieveable ways to solve your problem or need.  Once you’ve successfully established that viable short list, the power is all in your hands.  If you haven’t fully done that, you’re not really ready to negotiate, so you shouldn’t even start. Power in negotiation comes from not being wedded to a particular solution. Another way of expressing this idea is “always be truly ready and willing to walk away.”

Pay attention here: I’m about to say two apparently contradictory things, both of which are true and key:

1. You need to regard all of the choices on your short list as fundamentally on equal footing, each with its own advantages and disadvantages, but on balance having roughly the same merit as a solution.  Don’t ever go in having already decided which one you really want!
2. Yet, you need to remember that all of the choices are also fundamentally different in their details. For example, one might have 30% greater functionality or come from a more established and stable company than the others, but recognize that this advantage probably comes with a cost premium. The market is generally pretty efficient that way.

Your goal in the negotiation process is to see where you can find “wiggle room” on each alternative’s components (price, terms, features) that will ultimately make one of those choices outshine the other, on balance.  In other words, you are looking to unsettle the equilibrium you’ve achieved in #1, so that one choice comes out on top. And here’s another key: let each vendor know, and remind them frequently, that this is what you’re doing. Usually, there’s no need (or benefit) in letting the participating vendors know exactly what your list of alternatives consists of, but it will suffice that they know that you know that you have choices.

Miscellaneous tips and observations:

• Negotiation, in general, is not simply about money, although that’s certainly a key dimension that can make one of your viable alternatives rise above the others.  Any facet of the deal should be open to scrutiny and discussion: cost, terms, rights to upgrade, SLAs, warranty, etc. You don’t always automatically choose the least expensive option, nor do you always choose the most featureful.

• Don’t ever tell vendors (and believe me, they’ll ask again and again) what your budget is for this project. They don’t tell you what deals they’ve cut when they’ve sold their product to other customers, do they?  Again, the fact that you are actively pursuing other alternatives needs to speak the loudest.

• Remember, though, that your goal is not to hammer down the price so far that the vendor won’t make any money on the deal. You can do that, at times, but it ultimately means that you’ll get poorer service and less attention when you need it.

• Where possible, involve your legal counsel in the negotiations; don’t just bring them in at the end. The best negotiations for me, in terms of viable outcome, were where I had a tight bond and common approach with my legal counsel.

In the end, it’s all about getting a viable solution for your need, at a reasonable price and beneficial terms for all. It’s not really about “winning”; it’s about choosing. Give yourself choices, and in the end, you (and your organization) do win.

Lagniappe:

• Ward Keever, “Ten Keys to Successful Negotiations”
• Martin Ewing, “5 Can’t-Miss Vendor Negotiation Tips”
• Michael Krigsman, “Negotiation Tips for CIOs”
• Peter Kretzman, “More tips for dealing with IT vendors“

Here’s one series of questions that’s great to ask a candidate for a senior position in IT, be it in project management, development, operations, or whatever: Tell me about a recent project or initiative for which you were responsible. What was the goal, and how did you ensure that the goal was achieved? What were the roadblocks you encountered along the way, and what did you do to address them? What mistakes did you make? What would you do differently if you were faced with a similar project or initiative again?

For this post, I’ll play candidate and outline the kind of full and detailed response I would be looking for as a hiring manager, based on a project from my own experience. Let’s use a relatively simple one: implementing off-site (Software-as-a-Service, known as SaaS) email, replacing a poorly implemented in-house email system. Today, this would loftily be called “going to the cloud.”  (Yes, I’m aware that cloud computing encompasses far more than SaaS, but that’s not my thrust here).

As the incoming CTO at an Internet social networking company several years ago, I quickly observed that an unacceptable percentage of my IT staff’s time was absorbed in administering, troubleshooting, and user handholding related to the in-house email system, a third-party substitute for Microsoft Exchange.  But far more than the high cost factor was at stake: the flakiness of the company’s email and calendaring system had become both a cultural punchline and, frankly, an easy company-wide excuse (a little like “the dog ate my homework”) for people missing meetings and failing to communicate on key initiatives. Undeniably, meetings were indeed disappearing regularly from people’s calendars, and even simple meeting scheduling required using an unintuitive workaround to guarantee that all recipients would get the meeting notice. So, our goal was two-fold: reduce cost and staff distraction significantly, AND (most importantly) give the company a solid, reliable system for internal and external communication.

The mail server package had been implemented several years before my arrival as CTO, apparently without a careful plan or study, and mostly as a gut reaction by a then-VP of IT who simply loathed Microsoft and wanted a non-Microsoft solution. A significant portion of a DBA’s time, not to mention that of the entire help desk staff, was being expended in support of the system, not to mention the high hardware and software maintenance costs. My staff, and just about all users, detested the system. But oddly, roadblocks were present nonetheless:

• staff resistance on changing out a system they regarded as part of their job;
• CFO reluctance to make changes in general, and especially reluctance to go to an external email provider (concern about loss of control).

One lesson here? Things are never so bad that people drop their innate resistance to change!  But I digress.

We countered these roadblocks via several approaches:

• We surveyed all users in the company for their views of the system and tolerance for change in this area, and fed this feedback into the resulting action plan.
• We constructed a thorough cost analysis of the status quo: how much the current solution was costing the company in both hard and soft costs. I used this analysis to obtain executive buy-in, and to specify in detail what the cost and effort would be to fix it.
• We made sure that both junior and senior staff were involved in the methodical evaluation of alternative approaches, including the alternative of keeping the status quo. This helped achieve staff buy-in.
• We brought our “short list” vendors in for week-long user proof-of-concept trial periods, getting both staff and user feedback, thus defusing a lot of the “loss of control” type of uncertainty regarding the change.
• We negotiated hard with our “short list” vendors to obtain a good deal for the company.
• We worked hand-in-hand with our excellent legal staff to make sure we were well protected in terms of vendor SLAs, security, etc.
• We constructed and followed a careful user communication plan, keeping everyone informed of the rollout schedule via FAQ-style emails.

The rollout of the chosen solution went fairly smoothly.  We failed to identify two key risk areas or areas of concern clearly enough, though:

1. Users were much more concerned about calendar migration (old appointments and their attachments) than we had anticipated, and somehow this didn’t come out in surveys etc. before the implementation; we responded not by migrating the old items (expensive and difficult), but by keeping the old system running for a period of time after system rollout of the new solution, and that seemed to be satisfactory.
2. Users had great difficulty adapting to a 250MB email space limitation, since they had effectively had “no limit” (albeit poor performance and terrible stability) under the old system.  Even though we had discussed that limit in advance, done benchmarking across similar companies about their space limits, and gotten clear user buy-in, it still might have been better to consider a higher limit (and hence more cost) as we sought expenditure approval.

Now, just three years or so later, I’d do several things differently:

1. obviously, anticipate and avoid the mistakes itemized above;
2. consider using Google’s business email offering (we ruled it out since it was brand-new as of the time of the implementation, but it offers a much greater storage limit than any other provider I’m aware of); and finally,
3. implement sooner rather than later. Why sooner? The implementation and system was such a success that despite the bumps and concerns I just named, there was no more constant hallway conversation about the email system. It had ceased to become a concern, and also ceased to become an excuse.

And bottom line for the company, besides those productivity benefits? The total cost of running our (now very stable) mail system had dropped to the equivalent of just one FTE, about a third of what it had been.  Happier staff, happier users, and much lower costs: all projects should be so fortunate.

Lagniappe:

• Maria Spínola, “An Essential Guide to Possibilities and Risks of Cloud Computing“
• Michael Coté, “Don’t confuse SaaS with Cloud Computing“

As I’ve written before (“Offshore development: target the destination, even if you never go there“), the reality of the CTO/CIO’s life is to be constantly challenged to produce more. Most technology executives, given that challenge, focus on squeezing out greater efficiency from existing processes, which is of course a necessary and constant push. What many don’t do is recognize the importance of crisp, formal handoffs of software from stage to stage, and how those can greatly enhance productivity.

Software engineering lessons over the past decades have taught us that software architectural techniques such as encapsulation, data hiding, and well-defined module interfaces are essential practices as systems scale ever larger. Equally, the human side of software delivery needs those sorts of crisp interfaces and neutral handoffs: loose coupling, in other words.  Loose coupling entails “minimal assumptions between the sending and receiving parties.”  And an increased focus on internal efficiencies (plus deadlines and pressure) can sometimes lead a shop away from that, and into tightly coupled handoffs, because those seem faster and easier.  You don’t have the time to do it right, so you end up using a lot of time doing it over.  My argument is that (just as it is with object-oriented architectures) it’s worth slightly less efficiency-in-the-small, if certain sacrifices in the hand-off arena can help you attain efficiency-in-the-large.

As I wrote in my previous post, referring to the constant business-driven pressure to “put eight pounds of manure into a five pound bag” when it comes to delivering technology projects,

The main insight here is that finding a viable way to outsource some projects is your ticket to expanding the bag.  I’m not even talking about offshoring here, simply about being able to take a chunk of your project load and hand it to an outside entity to get done.  If everything could be done that way, then you’d be constrained in your project load only by available money.  Sadly, in many shops, almost nothing can be done that way, due to too much interdependency of systems, too much background lore required, and no processes in place to allow for external entities delivering changes into current production environments.  My position here is that it’s a key part of your job to change that situation: to work actively on decoupling the interdependencies so that you at least have the option to leverage outside help more effectively.

Let me focus in this post on the important role that outside help can and should play in your development portfolio.  Specifically, I recommend that you find several (I suggest three to five) vendors who can take on well-defined development projects and deliver them relatively independently of your current core development staff.  Pay no attention to the natural sales technique that each vendor will use (e.g., “we want to be your sole provider”), because that’s principally in their interest, not yours.  Each vendor will have different skill sets, different availability, even slightly different approaches.  Not to mention pricing: when a provider knows that they won’t win every job, by definition, that keeps everyone on their toes in terms of both maximizing quality and minimizing the cost of delivery.

Here are a few key aspects to strive for when embarking on this sort of selective outsourcing:

• Make sure the vendor can and will work within the software delivery approaches that you’ve carefully established. You’ll find that a lot of independent vendors actually aren’t accustomed to the idea of formal handoffs and loose coupling.  Educate them, and move forward with the ones who get it.
• Work closely with your company’s legal department to understand clearly what data you can hand off to external entities, and what protection mechanisms need to be in place.
• Design (or redesign) all of your development processes so that it will be relatively painless to keep your vendors working with current builds, data, and necessary interfaces into your key systems.  Otherwise, you’ll face a nightmare of integration testing once they deliver.
• Don’t tolerate lack of collaboration (i.e., with other vendors, or with your internal staff, which happens more than you probably suspect) or information hiding. Everyone needs to be part of the team, with all behavior above-board.
• Make sure everyone (the vendors and your in-house staff) understands that delivery is defined as full delivery, not just “working code.”  That includes acceptance testing (user and operations both), knowledge transfer, agreed-upon documentation, test scripts, everything.
• Do recognize that functions “down the road” (QA, operations) will be impacted (resource and schedule-wise) almost as much by an outsourced project as by an in-sourced one. Nothing comes for free, and this is often forgotten.
• Make sure that your internal team understands the strategy here. You don’t want to have jealousies or insecurities pop up, simply because not all projects are being done internally.

Most of all, the key lesson I’ve learned from working with outside vendors has to be the notion of putting multiple arrows into the quiver: in other words, actively seeking out and using more than one vendor for the portfolio of outsourced projects. Not only does that make sense from a negotiation and pricing point of view, it pushes and tests everyone to make the hand-offs as well-defined (i.e., not individual-specific) as possible. And that benefits everyone.

As I wrote last time, a large part of my reason for opposing offshoring is because I’ve rarely, if ever, worked in a company where I felt the necessary prerequisites were in place to be able to even consider offshoring as a viable option. Let’s go into that in more detail now.

I’ve observed before that managing the incoming flow of projects is often reminiscent of trying to stuff eight pounds of manure into a five-pound bag. In other words, you have more to do than you could ever get done. You will constantly be challenged, and should be challenging yourself, to find ways out of that dilemma: either, how can you become a better stuffer, so to speak, or, how can you expand the size of the bag itself. I assume that you’re doing everything you can to maximize the effective allocation of your resources so that you are more efficiently stuffing the bag. So, what about increasing the size of the bag? Well, additional internal headcount is usually hard to come by, and it also takes a fair amount of management overhead to scale a department prudently. The push is usually for short-term delivery of a project; increasing your own headcount can work in the long run, but almost never in the short term (read Fred Brooks’ classic The Mythical Man-Month).

But there’s another way. The main insight here is that your ticket to expanding the bag consists of finding a viable way to outsource some projects. I’m not even talking about offshoring here, simply about being able to take a chunk of your project load and hand it to an outside entity to get done. If everything could truly be done that way, then you’d be constrained in your project load only by available money. Sadly, in many shops, almost nothing can be done that way, due to too much interdependency of systems, too much background lore required, and no processes in place to allow for external entities delivering changes into current production environments. My position here is that it’s a key part of your job to change that situation: to work actively on decoupling the interdependencies so that you at least have the option to leverage outside help more effectively.

It’s hard to speak specifically to how to decouple the system interdependencies (every shop will be different in this), so I’ll focus here on something else that will essentially push you down that road. And that’s the notion of establishing crisp handoffs between phases.

Whether you outsource a project to a boutique consulting firm down the street, or to a larger entity on the other side of the globe, you’ll need to have certain practices and processes in place in advance, to have a prayer of succeeding. What happens in most shops, as they grow from early stage startups into even mid-level mature companies, is just the opposite: either extremely casual handoffs into production, or essentially no handoff at all. It all seems to work pretty well (usually), people tend to feel; why change it?

To get what I’m talking about, imagine a world where a vendor has magically produced exactly the code/functionality you need to satisfy some long-sought business need, something you haven’t been able to find the resources and cycles to work on internally. Do you just let them install it into your production environment? Of course not. You’d probably set up some meaningful criteria and deliverables they’d need to meet first, in order to mitigate the numerous and considerable risks and to boost your confidence that everything will go as planned. Those hurdles, handed over and accepted in a formal meeting, are what is known as “entry criteria,” an often-new concept to a lot of shops. They might include things like the items on the following non-comprehensive list:

• Installation instructions and scripts
• Operations guide, including troubleshooting steps
• Documented test results
• A list of known outstanding issues/bugs
• Verification tests to be run post-installation
• Full rollback steps
• Oh, yes: the code/binaries to install

I’ve seen a lot of internal development teams provide little more than just the last item, and, what’s worse, those shops typically have the developers install it.

If you focus your development team on what should be a best practice anyway for internal projects (thinking about future operability; documented installation steps; packaging of deliverables; verification testing, etc.), and expect your operations folks to insist on formal handoffs, you’re paving the way for future handoffs to come, potentially, from points outside your department. You’ve then federated and expanded your development factory, while keeping control over what matters: maintaining a robust production environment. You’ve set standards and expectations in place that you can communicate to outside vendors. Voilà: you’ve expanded the bag (well, at least theoretically).

So here’s my point: creating crisp handoffs, per the skeleton outline above, is something you absolutely must do if you ever hope to outsource. But, you’ll find that you’ll reap significant internal benefits from doing it anyway. Plan to do what’s necessary to lay the groundwork for outsourcing, even if you never actually go down that path.

I wrote last time about how there are twin truths to the buy vs. build dilemma: outsourcing can be a superb way to leverage external expertise and keep your own team focused on core functions; yet, outsourcing is not an easy or friction-free choice, and it’s easy to simply substitute one set of problems with another.

Note that I’m not specifically addressing offshoring here; rather, my comments pertain to any time you engage an external entity (across the big pond or across town) to perform a development or operations task instead of using your own people. I’ll have more to say about the specific subject of offshoring soon.

As Scott McNealy basically challenged Bill Howard at Sun, why not outsource (i.e., buy) everything and build nothing yourself? If that’s now the implicit going-in position regarding IT systems and services for many of today’s executives, then here are a few important (and often overlooked) things to consider, pitfalls of the “buy” side of the equation:

• Figure out your desired core competencies, as a company and as an IT organization. Focus on outsourcing/buying the fringe, not the chewy chocolate center of your total areas of responsibility. For example, at a recent job where the principal operational responsibility was running the company’s social networking web site, I made the decision to outsource internal e-mail, rather than host our own Exchange server, etc.

• Another way to put it: avoid building “plumbing”, even though it’s (maybe) considered fun or cool by your development team. If you’re a retailer, for example, you don’t want or need to be building generic middleware software components that are readily available elsewhere. I once saw a big consulting firm, left to their own devices, sink literally millions of client dollars into constructing and tweaking an elaborate bug tracking spreadsheet (yes, spreadsheet), rather than put a part of that effort into identifying and buying an adequate off-the-shelf solution. A classic example of yak shaving, that… not to mention client bilking.

• Don’t let anyone assume (and frankly, your senior execs are classic candidates for making this assumption) that outsourcing a given area will mean no resource commitment or involvement on your side. Outsourcing is meant to be a case of leveraging, and it can never mean throwing up your hands and absolving the company of any responsibility or involvement.

• Make sure you (or someone else at the company) can be a tough and active negotiator, both on price and on terms and conditions. Mistakes made on either one can affect the bottom line for years.

• In the case of one-off projects (as opposed to outsourcing ongoing services), watch out for inadvertently creating a total, ongoing, interminable dependency on the entity to which you’ve outsourced. Keep some employee skin (i.e., familiarity) in the game.

• It’s really rare for a system or service to be truly stand-alone, in any company. Assume that at least 30% of the total schedule will require intense participation from your internal resources, carefully defining integration points, clarifying requirements, and ensuring knowledge transfer.

• Try not to outsource all the most enticing projects, for the sake of your internal team’s interest, pride, and eventual continuity. In fact, be sure to make it clear to your team, when you do outsource something, why you picked that specific area or project.

• Think about the state of your operational acceptance process. If you haven’t had a robust process for migrating new applications or builds into production, that process needs to be crystallized before outsourcing anything is remotely viable. You do not want to get into the situation of having the outsourced entity have to ship an engineer to your doorstep to install its product into your production environment. If you can’t succinctly state the specific hand-off requirements to your vendor up front, then trouble is down the road.

• On outsourced development projects, unless it truly is a stand-alone project (a rarity), think about your integration test environments and process. Where will the acceptance gates be? You’re not really contemplating just taking their word that everything works and won’t impact your other applications, are you?

It should be clear from the above that outsourcing entails a ton of work on your end, work which can come close to balancing out the actual work you’re supposedly outsourcing. But here’s the most important point: you should be doing that preparation work anyway, even for internal projects. You should have acceptance gates, clear hand-offs, careful integration testing, etc. If you organize and plan for that, you have the ability to scale your team up internally as well as externally. You can then do a kind of “internal outsourcing” on a project-by-project basis, since hand-offs are crisp and safety nets are in place. That approach ultimately becomes the only possible meaningful answer to the recurring dilemma I’ve written about before: how do you stuff 8 pounds of manure into a five-pound bag.

Bottom line: if you’re robust enough already in your organization about these “best practice” kinds of hand-offs, you’re quite ready to shade the “buy vs. build” equation a bit more towards the “buy” side. If you’re not, you should be devoting night and day to getting there, for internal quality and scalability reasons alone.

I’m going to unabashedly steal someone else’s anecdote for this post. I’ll justify doing so on the grounds that the anecdote has stuck with me since I heard it; I’ll talk about why, and why I tend to repeat it to my staff at opportune moments. Starting with this post, I plan to follow on with additional posts discussing more nuances of this very critical topic of buy vs. build.

About 5 or more years ago, I went to a CIO forum hosted at Sun Microsystems by their then-CIO, Bill Howard, who has since retired. At the time, Howard ran IT for Sun, with a staff that probably numbered in the thousands. His anecdote was about how he was frequently nagged by Sun chairman Scott McNealy about the size of his IT staff. Scott, according to Bill, was of the decided opinion that Bill could accomplish all he needed simply by having himself and an assistant, and outsourcing all the rest to external parties.

As I recall, Bill told this story with some mixed feelings. Some of it seemed to express a wry feeling of “this is the kind of thing I have to deal with from my management”; on the other hand, he went on to say that he actually thought that in a certain sense, Scott had a valid point. Bill also went on to note that despite Scott’s jibes, Bill still had thousands of people in his IT organization.

A joke often reveals a lot about the world view of the jokester. I don’t know, of course, but it may be that Scott McNealy operated in a world where, for all practical purposes, he focused on his own role and that of his assistant, and considered everything else as effectively “outsourced”, even to his senior lieutenants. It can get dangerously easy, as a senior executive, to reach that level of detachment. It’s something I advise against.

But that’s a different topic altogether. In any case, my main takeaway points from the anecdote itself reflect exactly those two twin, contradictory poles, representing simultaneous truths. The anecdote has stuck in my mind, and gotten repeated to my staffs, all these years precisely because both aspects of it are true:

• Upper management can (sadly) often underestimate and/or undervalue the amount of work and complexity entailed in both “keeping the lights on” and delivering new features and functions to the business
• IT systems and services are now actually quite often not much more than commodity items, which can achieve scales of economy and efficiency through appropriate outsourcing to firms that are expert in each particular area.

So yes, one can (and frequently does) farm out chunks of the existing IT work and rely on an external party to provide the associated service: systems development, systems operation (financial systems, e-mail, colocation facilities), tech support, help desk, even project management. For example, building a custom operations center for a web site today, when quality colocation facilities are readily available, is fairly foolhardy and almost always unnecessary.

But think about it. It’s also the case that managing a passel of external vendors is not a walk in the park. Strong horses need strong riders. And, in what shouldn’t be a surprise, companies that are created to exploit economies of scale will often push to achieve, well, economies of scale: this means that existing customers can often be neglected unless those customers manage the relationship closely and actively. All of that active management takes staff, and time, and knowledge. Equally, there are core competencies, integration requirements, and business-specific needs (less than people think, more more than management would typically like) that can effectively rule out the use of off-the-shelf, commodity approaches.

It’s all in the balance, of course. I’ll talk further in subsequent posts about possible approaches toward striking a balance.

Lagniappe:

• Notable quotes from Scott McNealy, one of the more flamboyant figures in technology circles
• Bill Howard’s retrospective view upon departing from Sun Microsystems

Build-vs-buy background articles:

• “Build vs. Buy In the 21st Century“, Joshua Greenbaum, Intelligent Enterprise magazine
• “Survival Guide“, Bob Lewis
• “Buy Versus Build: Why Companies Should Never Build Software“
• “Consider these points when making the build vs. buy decision“, Jerry Loza, Tech Republic
• “The Death of Packaged Apps?“, Eric Keller, Sandhill.com

Just a quick one, this time, in what may become an ongoing motif of describing some of the pet peeves I’ve developed in this role.

For years now, I’ve been unable to answer my desk phone. Or rather, I’ve been unwilling to answer it, at least for calls that I can tell are coming from sources external to my own company.

Nineteen times out of twenty, any external call is almost certainly a cold call from a software or hardware or services vendor. It’s as bad as dinner hour used to be at home, before the advent of the National Do Not Call list. Sometimes I even detect the telltale blank pause that occurs while the automated outbound dialer, robotically jumping for joy at having landed a live one, is routing the call to a real person. The caller is often obviously reading from a script, rapidly.

They want to impart things along the following lines:

• Can they take me to lunch, or coffee, and discuss my upcoming initiatives;
• Am I aware that they can save me many thousands of dollars, if not hundreds of thousands, with their product/service;
• They have a uniquely topnotch, crackerjack, CMM level 5 offshoring team, in Bangalore/Vietnam/Russia/Argentina/China/Dominican Republic etc., that can provide high quality development or tech support or QA at a mere fraction of my current cost;
• They provide flexible staffing and have the best technical folks in town overflowing their rolodex;
• They’ve recently talked to Executive X at my company, who kindly directed them my way, maybe even gave them my number. (Thank you very much, executive X!)

Once I’ve taken the bait (i.e., once I’ve actually answered the phone, against my normal habit), it’s at best time-consuming and at worst extremely awkward to gracefully end the call in any manner that constitutes the normal politeness I try hard to muster in the workplace. Some people simply refuse to hear no, even when repeated, even when firm. It’s almost as bad as trying to cancel AOL service. Getting even one or two of these calls, at least when it’s the persistent ones, is almost guaranteed to ruin my day.

I’ve taken to the following strategies:

• No more external calls. Ever. If I want someone to be able to reach me, I give them my cell phone number. Not only do I have more accurate and customizable caller ID capabilities on my cell phone, it’s more likely to reach me when I’m roaming the halls.
• I put a firm outgoing voice mail greeting on my line, in which I explain that due to the volume of calls I get, I greatly prefer receiving e-mail, especially from possible vendors. I also ask that they not leave a voice mail at all, but instead provide me with material via e-mail. And I give out my e-mail address in that greeting.
• Then, I try (not always succeeding 100%, admittedly) to answer each and every one of the resulting e-mails that I do get from people who have called first, even when I’m expressing a complete lack of interest in pursuing their offering. It especially amuses me, though, when people leave a lengthy voice mail message, despite my request, ostensibly to tell me that an e-mail is on the way from them.

All humor aside, I do understand that sales is hard, and making meaningful contact with potential new business must be one of the trickiest things in the profession. But for the sake of my own productivity, I do have to function defensively, and preserve my time and efficiency against these repeated and often insistent encroachments.

I’ve been in this mode, exercising these strategies out of sheer necessity, for well over a dozen years now, at several companies. I can’t imagine that my situation here is really any different from any other IT executive. Which makes me wonder sometimes: just why do we still have desk phones at all?

Now that I’ve covered the more humorous (and hopefully the less typical) side of dealing with vendors, I’d like to present some “lessons learned” for developing and maintaining positive relationships with hardware, software, and service providers. After all, we all need to use vendors’ products and services, and I’ve learned in my own experience that there’s a great deal that the technology executive can do to make a vendor relationship a positive experience for all concerned.

Here are some general tips, tips for during the sales cycle, and then tips for after the sale is over. Topic of a whole separate post in the future will be negotiations; this post will focus on relationship building and value determination.

General:

• Mutual respect. These vendors, if you’ve called them in to present to you at all, obviously have something that could help you accomplish your three key goals: maintain revenue, increase revenue, or cut costs. A major thrust of your discussions should be to ferret out those aspects of their offering, while determining if the benefits will outweigh the associated costs.
• Either way, the salespeople and technical representatives you are meeting with are earning their living this way and generally tend (in my experience) to believe strongly in their product. Treat them accordingly. Remember their names, look them in the eye, thank them for coming.
• Equally, gauge (and do so quickly) that rare case where they appear to be regarding you just as a quick sale. You need to work with vendors who are truly interested in understanding your business problems and issues and seeing how their offering can help.

During the sales process:

• It’s all about negotiation when it comes to price, and very little is ever set in stone at the outset. However, as you negotiate (and frankly, it took me a while to absorb this basic fact as deeply as I needed to), remember the basic truth that the vendor needs to make a profit too. There’s no point in repeatedly hammering the vendor down on price so that your company becomes little more than a difficult or unprofitable customer for them. That backfires.
• Try to level the playing field so that you’re evaluating 2-3 fairly similar offerings from different providers, any one of which could do the job. Doing so keeps everyone, including you and your staff, on their toes and watchful of both cost and value, and it lets you gauge what you really want (features and functions) from the purchase.
• Get your legal and financial people involved as early as they will accept (and usually that’s pretty early). Nothing is more frustrating to an in-house legal counsel, for example, than to be brought in and told, “everything’s all done, and we really need to get this signed this week.” That approach is bad enough in terms of your negotiating power, and it’s even worse for protecting your company.
• The vendors will want to know what your budget is. Sometimes you’ll have a really firm idea of what that is. Don’t tell them. Sometimes you won’t have a firm idea, because it depends on the value that you’re seeing and the trade-offs you can make in other areas. Don’t tell them. Within an appropriate and reasonable range of product type (e.g., all Volkswagens, as opposed to a mix of Volkswagens and Bentleys), you want to focus on functionality, robustness, and overall value, long before you start discussing particulars of price.
• The vendors will want to know who their competition is. They go crazy when they don’t know whom they’re up against, and they will tend to ask repeatedly in various ways. Don’t tell them, though. Again, it’s mainly about them understanding your business and needs, and about you understanding their offering. Everything else is largely a part of the price negotiation.

After the sale is complete:

• Have a long memory. Good vendors are golden. Less good ones seldom change their basic approach. There are several vendors (a very small set, to be sure) that I will never work with again under almost any circumstances. Don’t let your natural trust and hope go too far towards giving business relationships a second chance if you’ve been seriously disappointed the first time around.
• Don’t fall out of touch with your new vendor, any more than you want them to do that to you. Maintain regular contact. Make sure that you or a suitable delegate is in charge of the ongoing relationship–this means achieving an ongoing understanding what products they have in the pipeline and how it affects what you’ve purchased from them already.
• Don’t get complacent, any more than allow them to become complacent. Each of your vendors should earn your business each time. Yes, it’s easier to just call up Joe for the next piece of equipment or software module, but within logistical boundaries, look to explore if there are viable alternatives. You owe that to your business and to your bottom line.

Lagniappe:

Enough serious posts for the moment: it’s time for a little bit of humor, hopefully with a moral or two in tow.

About 15 years ago, when I was still a director and not a C-level executive, I worked a great deal with vendors providing services, project management, software development, and so on. In particular, my company chose to enter an extended and extremely expensive relationship with a well-known large consulting firm, which was given near-total management control over resource allocation (meaning their own resources) and an apparently unlimited budget. For the next three or four years, I worked closely with them, Biedermann among The Firebugs, working to maintain a semblance of integrity and direction for the project and for my company’s financials.

In the course of all that, I heard certain earnest promises repeatedly, and came to regard such statements as canaries in the coal mine when dealing (especially in the early sales cycle) with new vendors. At the time, finding some strength in humor, I dashed off the following list, which I’m repeating here with some commentary. If you hear any of these statements from a vendor (not to mention several such utterances strung together in an elevator pitch), my strong advice is FAV: Find Another Vendor.

In true David Letterman style, here’s the Top 10 List of Vendor Statements, with annotations.

10. We want to partner with you.
What do they mean by this? To me, a partnership would mean some kind of true sharing of effort, cost, and risk. Instead, the real meaning behind this statement is usually that they’d like to be your principal (or sole) provider in this area. This kind of “we bill and you pay” partnership is anything but. Probe them for what this “partnership” will entail, and work to make it even-handed.

9. Your company is one of our most important clients.
And talk is cheap. How does the vendor demonstrate your importance to them? There are only a couple of ways: preferential service and/or cheaper rates. Ask for something solid along these lines.

8. We’re barely making any money here.
As defined by what? The big consulting firm that told me this most often (this would be the same firm that was billing my company in excess of $3-$4 million dollars per month, with about 100 of its consultants engaged on site at rates exceeding $175/hour) defined “making money” as when they exceeded an already high (and arbitrary) markup percentage on their people.

7. We give you only our best people.
That’s possible, I suppose. But are they saying this to everyone? This claim reminds me of Garrison Keillor’s welcome to Lake Wobegon, “where all the women are strong, all the men are good-looking, and all the children are above average.”

6. If you don’t like one of our people, we’ll roll that person off the project right away.
Here I’m burdened with history: when push came to shove on this one, it simply didn’t happen, repeatedly. There was always going to be too much impact to the project, or sudden claims of a mere “personality conflict”, etc., and the company’s executive sponsor of the project didn’t jump in to ensure that the vendor acted. In other words, without a near court case about the matter, the vendor’s claim was empty. As an executive, make sure that you back your people up in these circumstances and insist on the removal of the consultant at issue.

5. We’re barely making any money here.
See #8. When these cries get louder as you push back on their fees, well, as the Bard says, the lady doth protest too much, methinks.

4. We’re in this for the long term, not just a quick gain.
See #10. This statement would imply a level of true vendor-side investment in the overall effort, investment that is rarely forthcoming. Ask for specifics that will demonstrate their commitment.

3. One of our key goals is to help you build your organization.
That implies that they don’t want to do the opposite: build in a profound dependency on them. Unfortunately, actual behavior (particularly on the part of big consulting firms and even some vendor professional services organizations) can often be the opposite. Not always, but often: after all, it’s human (management) behavior to attempt to lock in revenue for as long a time period as possible. Hence, any time you use external resources, you need to push hard to avoid long-term dependency, even when that’s painful in the short term.

2. We don’t want our people to work overtime. Really.
Think about it from the vendor management’s point of view: their employee costs tend to consist of fixed salaries, not people paid by the hour or even compensated for overtime. The full rate from any extra hours that their consultants bill to the client thus flows almost directly to the vendor’s profit line. Sure, from a people impact point of view, they have to be careful, otherwise their people will quit on them. But eagerness to get this kind of “pure gravy” revenue often trumps any people concerns.

1. We’re barely making any money here.
It starts to sound a bit desperate, doesn’t it?