Application Negotiation - a field guide to interacting with the client

You love programming and writing code. I get it, but at some time or other you're going to actually talk to a client. In the end this will likely have more impact on the success or failure of your project than the technical aspects of writing code. I've lumped these soft skills into the term "application negotiation". So as the project leader what's this all about? (btw, if you're the only technical person on the project, then you're the project leader.) Well, it's not about the details of how you manage the to-do list. It is about communication and leadership.

Early Agreements
You probably fall into one of two situations: you're employed by a company full-time to do programming work or lead a programming team, or you're selling your services to a company from outside that company. Either way you need to pay some attention to the agreements that you make when you first start talking about a new project.

The client chose you for a reason. Find out why. If you work for a company, the reasons have more to do with why they want the project than why they chose you personally. They probably didn't have a lot of choice about using you for the project. Do your best to find out the pressures that are on them. I found that all too often, they've come to you with only one of many possible solutions to their situation. Try to get them to define the project in terms of the root problem you're trying to solve.

If you've been hired from outside the company, learn why they chose you. This will give you some insight into their expectations about the project. Try not to be lulled into a straight time and materials viewpoint. You'll do better in the long run if you can build a relationship of trust. Very few projects are so cut and dry that you can just do what was asked of you and walk away.

It's in your best interest to focus on the long term. You have your reputation to protect. Taking any old project may help provide some immediate cash flow, but it's the long term relationships that add stability to your efforts. Beware the client that is only interested in you writing the code that you're told to write. In the end they probably won't like what they get and they'll blame it on you.

The client will undoubtedly have expectations for the project, but you have expectations too. Make sure to set some agreements before you start working, and I do mean working, not programming. Define how you will work together. Do your best to gain direct access to the people who will use the final product. Set regular times when you will meet to review the project. Give them a vision of what it will be like to work together. Actually talk through how you will get work done.

Project Research
Learn your client's world. Write your project documentation in their terms using their jargon, not yours. Have the client verbally explain the environment where the work products of this project will be used. Their business environment is likely very different than your programming environment. If you can become the person that is comfortable working in both worlds, then you will become very successful.

Spend the time talking through who will use the product and how it will be used. Do your best to pull in all affected parties, even if that means you do the "leg work" to interview people separately. Use this early time to help people visualize the solution they are asking for. Dig deep to find consequences to their actions. One of the areas that comes up most often is in setting requirements for data collection. Many times the sponsor of the project wants to make most data input fields required, but you should talk it through and make sure that the user will always have the answer to every required field.

The client doesn't care about your technical prowess. Don't use it as a smoke screen. I've seen many eager young programmers suggesting technical solutions in terms so technical it was impossible for the client to understand them. In the end the client doesn't usually care how you're going to solve the problem. If they talk like they want to know how you're going to accomplish the project, keep your answers simple. Let the client probe you for more information if they want it. After many years of programming and leading projects large and small, I still struggle with this one.

I've found that some of the best approaches to problem solving in this environment comes from some math teachers. Here's some links to articles I've found useful:

• Understanding the problem from mathforum.org
• Measuring what counts: memorization vs. understanding from edutopia.org
• Understanding a Conflict by Grete Refsum

Managing Expectations
Let nothing go unsaid that needs to be said. If you have doubts, you need to express them. However, don't dwell on what won't work. Spend most of your time exploring ideas that you can implement. If your project meeting is turning into a gripe session, turn the tide by exploring possible solutions. If they refuse to acknowledge that anything will help, try focusing on the requirements. Defining and redefining requirements can help them to focus on what they want, not on what they think is impossible.

Reiterate your understanding of the expectations at the end of every interaction with the client. Verbal repetition helps you solidify your understanding of the problem and gives the client a chance to clarify. Always make an appointment for your next interaction, and don't tie it to project milestones. If you make your next appointment tied to the accomplishment of a task and that task gets delayed, it only frustrates the client.

Learn your client's tolerance for project updates. "I'm working on it" is never an appropriate measure of progress or project status. When the client asks for project projections, avoid projecting beyond their tolerance for updates. When I was at my last job, their tolerance was about three weeks. I needed to try to keep any work items broken down into things that could be accomplished in three weeks or less. If you reach the end of your client's tolerance for updates, and your answer is the dreaded "I'm working on it", then the client will start to set their own timeline for progress based on how long they think it should take to get the task done. Then they'll hold you to it.

Dealing with Shifting Project Definitions
People change their minds. Get over it. Learn to effectively lead people through their decisions. They won't always know the consequences of their choices. It's up to you to lay it out for them. After that, all you can do is give them what they want.

Admit your mistakes early. You're only wasting time by delaying the inevitable.

Get help. When you're unclear of your direction, bounce your ideas off a trusted colleague. Facebook, Twitter, and USENET groups can be valuable resources.

Dealing with People
Stay in control of your emotions even when the client is all over the map with theirs. You don't have to take their stress. Here's a link to a good article on understanding people's emotions as a way of providing good customer service.

Learn to deal with angry clients. When they start to vent. Let them. The client has the right to feel the way they feel, so don't tell them their feelings aren't valid. After you have listened, repeat their main points back to them. This let's them know that they've been heard. Here's two links on dealing with angry clients:

• Diffusing Anger from BusinessKnowHow.com
• Handling Angry Customers from Gaebler.com
• Boys and Their Toys by Bill Adler, Jr.

How to Improve Your Skills

• Look for courses in facilitative leadership.
• Practice public speaking.
• Read. There is an almost unlimited library of advice on this topic on the web.