In the prevailing wisdom of the consulting industry, on-site consultants represent the single most powerful sales tool a company possesses. The on-site consultant has a proven track record with the client. He also develops intense relationships with his client counterparts. Being on site constantly, he can ferret out sensitive information, upcoming projects, and political insight that give a company the edge over the competition. Misusing this knowledge, though, can lead to serious client problems. I learned this lesson the hard way on my first large on-site implementation.

I went onto my first long-term on-site assignment after a few years of contract work. The client wanted a fairly simple Linux sendmail backbone, long before Linux became the darling of the IT world. Before I left, my manager reminded me that I was “the company’s best salesman.”

I spent six weeks at the client’s site: tuning servers, sending mail, and generally doing what consultants do. Over the course of six weeks, the client and I ate far too many bad lunches and spent late nights in the server room together. We talked constantly, at first about work but later about personal matters as well. As we talked, we gradually branched out into the complex realm of future projects. Eventually, my client revealed that he wanted to undertake an ambitious database consolidation project. I knew from previous internal conversations that my company wanted to break into that space. After we finally broke for the night, I tossed an e-mail to my company’s client rep about the potential project.

Over the next week, the rep asked me for a number of details regarding the client’s network and database architecture. I didn’t think anything of it. In my opinion at the time, I thought he should know as much about his client as possible.

On Monday afternoon, my client asked me to come into his office. I went, expecting that we would need to talk about the work ahead of us. Instead, he showed me a detailed and highly flawed proposal that had just arrived on his boss’ desk. It discussed a database reengineering project. His boss’ comment was, “Do we need this?” My client’s first comment to me was, “I never want to see anything like this again.”

After he yelled at me a bit, he said that he had not even discussed the possibility of such a project with his boss. The idea was something he wanted to consider for a long time before bringing it up. Since we had forced his hand, he now had a great deal of work to do in addition to learning the particularities of his new messaging backbone.

Two weeks later, the client cancelled the continuing operations portion of the contract, citing the stellar work I did in creating an easily maintainable system. We never received any work from that client again.

Beyond the obvious
Obviously, my company mishandled the situation. Our litany of mistakes reads like something out of a “never do this” sales manual. Although I believe to this day that our intentions were reasonable, the lack of communication with our primary client contact cannot be excused.

At the core of the systemic failure, though, lurks a very simple mistake on my part. I failed to differentiate between information shared with me in a personal context and professional information.

It’s not always easy, especially for inexperienced technical consultants, to recognize the difference. The more social we are, the less simple it becomes to sort out what is personal information and what we can share with our organizations. Treating it all as personal saves a lot of trouble with the clients but also cuts us off from valuable opportunities. Similarly, passing on information before it is time can generate serious interpersonal and even intercompany issues.

Establishing and maintaining information boundaries
When deciding whether to share information gained during on-site discussions, consider the following:

  • In what context was the information presented? Did it come out during a formal meeting? During a pizza and beer lunch offsite? At a baseball game? The more informal the setting, the more personal the information is likely to be.
  • How highly placed in the organization is the individual? The more experienced the individual, the more likely it is that he understands and can deal with the game of business. Inexperienced or young clients don’t always differentiate between personal and professional conversations. Experienced clients typically know that you have to report back to the home office at some point, so they are careful about what they say.
  • Does your client have the authority to authorize the project? In the above example, my client hadn’t even spoken to his boss (the decision maker) about the project. He was dreaming out loud about something he knew he wanted to do someday. In general, if your client doesn’t have the authority to make the decision, you shouldn’t pass the comment on.

Finally, if you have any doubt at all about whether to share information with your company, ask your client directly. Although it goes against every consulting myth, we don’t need to hoodwink most clients. If you ask a direct question, you’ll usually get a direct answer. More important, you establish your sensitivity to their position. By asking outright, you give the client control over your actions, increasing their belief that they can trust you.

Fast forward
Many years later, one of my clients and I took a break after a data-center rollout that lasted for more than three days. After eating out of vending machines while checking systems, we wanted a decent meal.

We went to a local steak house, had a few beers, and waxed poetic about our lives. As the conversation turned, she told me that she wanted to replace four other data centers around the country. Although I was exhausted, my sales antenna stood up to full alert. She just casually mentioned a job that would be worth a few million dollars to the company that landed it.

I hastily went though my list of rules. We were definitely in a private setting but business was the topic of conversation. She was the chief architect of the organization, so she did not have decision-making authority. She also possessed sufficient experience to know that a project that large would definitely be of interest to my company. It looked like a toss-up. Rather than stall, I asked her if she wanted me to have a salesperson contact her.

She said no. I immediately turned the discussion to other things. But later, after I helped her write the RFP, we landed the contract and finished up the remaining data centers.

In the first case, I allowed my confusion about personal and professional information to start a disastrous chain of events. In the second, I kept my head and applied basic principles to reinforce my client’s trust and win the deal.