Or: Everything you wanted to know about customers, but were too busy coding to ask.

In the last issue, Nancy and Barbara gave us a brief overview of some customer relationship issues. This time, they take a closer look at the initial contact phase.

In the last column, we introduced some basic issues that come up when dealing with customers. In this column, we discuss the initial contact, by which we mean the first in-depth meeting with a potential customer. Whether it's by phone or in person, the initial contact forms the basis of the customer's first impression of you. We've found that a business-like approach works best to communicate competency. However, since the rules aren't clear about what “business-like” means, there is no substitute for reconnaissance.

Know your audience. Are you meeting with programmers or accountants? Is the customer in a corporate or campus atmosphere? Are they an international firm (probably more formal than a local firm)? Is the firm technologically savvy? Why care? How the heck do you find out? Luckily, there are resources.

The receptionist can be your most fruitful resource. Also, check the company's website. What it looks like will tell you how they are positioning themselves with technology. If they don't have a website, that tells you something, too. Ask about the roles of the people you will be meeting. Ask how long the meeting will last. If the client is local, find out where the office suites are, because that may tell you how “corporate” they are.

Should you wear a suit or Dockers? For corporate customers, a suit is our first choice. For campus environments, we like business casual. Face it - geeks aren't known for being stylish, but in business meetings, customers are looking for serious business partners, not for geeks. If you're really hopeless, go to a decent department store and ask for help with two outfits: business casual and business.

Goals of initial contact

A contract or job offer is the goal of the initial contact. Here are some useful questions to keep in mind during the initial contact, to help you stay focused.

  • Is the project interesting, does it fit with my business objectives, and am I capable of it?
  • Does the customer know what the project is? Is there a budget?
  • Does the customer pay bills on time?
  • Has the customer contracted for software development services before? Do I know any of the contractors?
  • Who are the players?

The following questions are helpful to keep in mind during the initial contact, but are usually discussed during negotiations.

  • Can the customer and I agree on how I will bill (hourly versus fixed price)?
  • Does the customer understand what my hourly rate is, or does she have a very general idea of what the project may cost? There may be no point in continuing if she wants a complete inventory system for a fraction of what I estimate the cost to be. There are exceptions. It can pay off to be firm and suggest an initial contract for a relatively short duration for a functional specification.
  • Does the customer understand what the deliverables are? For example, do they have expectations about whether or not they get source code, about who owns the copyright to that source code, and whether or not documentation and setup disks to install the system are included?

Presenting the Right Image

Focusing on your goals for the initial contact and knowing as much as you can before the meeting are great steps toward a great first impression. Next, comes selling your services. It helps to work out a personal approach to selling that will keep you focused. We've found that a soft-sell approach works best. For example, being a salesperson means matching up a client's needs with capabilities. How that is done, is a matter of personal style. The important point is to think about what you are selling and how you want to sell it.

Neither of us cares for the pushy or anxious sales approach. However, relevant accomplishments should be discussed positively. As the customer discusses needs, give examples of similar situations you've experienced. It's okay to bring up a problem (if the customer is concerned about an issue), so you can explain how you intend to resolve it.

Note that there is a difference between experience and accomplishments. Failure is experience, too, so saying “I was successful at [something] by doing [this]” has more meaning to a customer than “I have experience in [something].”

What we sell is our competence. We all know that we meet new tasks everyday - it's part of the charm of our profession. However, customers want to hear that we have all the expertise they need, right in our back pockets. If a customer hasn't worked with us before, they may be discouraged to hear that we don't have experience in a particular technology. How do we balance our confidence that we can get the information with the customer's need for assurance?

If we are interested in and generally capable of doing the project, but it involves something we haven't done before, we don't lead the customer to think we're experts. Nor do we go out of our way to emphasize that we don't know what we're doing in that area.

Let's say a potential customer is asking for a major database application that tracks orders and inventory. One of the things it needs to do is interface with Quicken�, and you know nothing about its internal data. You can simply mention to the customer that you are not familiar with the data requirements for Quicken�, so this feature will require you to review some technical documentation. It's fair to mention a similar situation in another project, so the customer knows this isn't unusual. He'll appreciate your honesty and put that much more faith in what you claim to have done. If you appear intelligent and confident, you'll leave the right impression.

As another example, you can use a corporate approach. The corporate individual who meets with a customer rarely has all of the direct experience a project will require. However, he will know who his resources are, their capabilities, and how to put them together to get the job done. It doesn't have to be much different for independent consultants. Professional relationships with other specialists can provide bench-strength, giving you and the customer confidence. Part of your reconnaissance would include identifying specialties, and having a plan for putting together a team. Whichever approach you use for the customer should highlight your strengths and mitigate your weaknesses.

Who Brought You In?

Use the initial contact to determine the players. Who brought you in? Why were you brought in? Sometimes there's a hidden agenda, or you're being brought in as a scapegoat. Is there another bidder? Does he have an existing contract with the customer? If so, you might just be filler, or they might just be using you to check out the feasibility of something the current contractor said. As you gain more experience, you'll be better able to recognize such situations early in the process. Who are the players? Here are some we've commonly found:

The contract administrator: This is the person who signs the contract, although you may never actually meet her. She is usually the one who processes invoices, and could suddenly insert herself into projects with no background. It's rare, and the only good defense is to make sure that all your paperwork is in good order, and that your main contact (and optimally his boss) knows exactly where you are with the project. Try to set up your contract so that you send copies of transmittals to someone in addition to your contact, such as his boss or the contract administrator.

The contact person: This is usually a conscientious person, already overworked, given the assignment because, well, he never says no. There are two common problems with the contact. Sometimes he doesn't have the authority to make decisions. He often won't have time to get you answers when you need them to keep the project on schedule. In this case, send the customer (your contact) lots and lots and lots of memos saying what you need, when you need it, and what impact it will have if late. Offer meaningful suggestions and offer to help get any information needed. If you're not getting responses, it may help to copy the contact's boss, but you must be careful how you do this. (We'll discuss how the players interact in more detail in a future column.)

It helps to arrange with the customer how you will make requests, so it is as easy as possible for him to answer you. It's our responsibility if the project goes off-track, even if the customer is holding us up. It's our invoices that won't be paid. What happens if the contact is promoted or fired before your project is complete? You simply need to have good communication with his boss to keep your project alive.

The contact's boss: This can be tricky to pull off, but the basic idea is that you don't want her to pull the plug on your project because of budget cuts or because your contact leaves. Help your contact market the project to his boss. In other words, you want your contact's boss excited about the project. You also want your invoice to be at the top of the to-be-paid pile, rather than at the bottom.

The user: This is someone who either directly uses your software or uses the product of your software. If you are lucky, you are working on a project the users have been asking for. If you are not lucky, you are working on software that is being imposed. Some of Nancy's experience has been with customers who began software projects as punishment. Projects that start out with requirements for electric shocks in the chairs if data is left empty, aren't fated for success.

It is possible, though, to turn such projects around, with a little bit of luck. This can take a lot of energy, but so does dealing with hostile users. If you find yourself in such a situation, you should try to get a sense of what the users need. If necessary, talk to your contact about redirecting modest resources, so that the project has better buy-in and will go smoother. For example, in the case of the electric shock customer, a satisfactory compromise that also helped the users was to programming intelligent defaults. Good thing, because by the time the project ended, the user base had changed, and with it, the politics. This brings up the issue of elephants.

The elephant in the living room: Customers' elephants are those looming issues that have little to do with your software project, but have the potential to squash the project like a bug. Is the project being initiated by a new manager brought in from the outside? If so, you may have tension with your contact and resentment with users. Is the project a continuation of something that another contractor abandoned or was fired from? This can be a red flag! Use caution, especially if you must work with the previous programmer's code.

Is the customer looking for a hard price against insubstantial specifications in the first meeting? They may be trying to use your bid as leverage in other negotiations. Is the customer requesting a for-free design plan? Sometimes companies will let bidders do the research into technologies and approaches, and then use that research themselves. Are the users hostile? There are several species of this elephant.

Educating the Customer

Often, a potential customer doesn't have much experience with program development ? or has had bad experiences with it. Whether you're an independent or corporate developer, you can briefly describe your development process in the initial contact. Details for the process should be discussed and agreed upon during negotiations, which we will discuss in our next column. For the first meeting, it's important, we believe, to assure the customer that the process will be orderly.

The specification of firm schedules, billing rates and frequency, customer responsibilities, customer report requirements, and deliverables, is usually done during negotiations. However, discussing these points in general now will demonstrate that you're competent to manage the project. It's also important to leave the customer assured that development is a team effort between programmer and customer. She is the expert in her business, and you are the expert in programming.

For example, someone can't just ask you to write an accounting program and expect you to come back some time later with the finished product working just the way she wants. However, that's often exactly what a customer does ask. If she does, or you hear phrases like: “you're the expert: you tell us what we need” or, “we don't have time to do a design phase,” then talk to her about off-the-shelf software. Since a customer will have often considered and rejected off-the-shelf packages, this tactic can secure her commitment to be involved.

Introduce the customer to the idea that development is an iterative process, and that her involvement in testing will be important. Explain how you'll start with a program that does many of the basics. She'll try it out for a while and suggest changes and improvements. Then you'll fill in more of the details and improvements from the last go 'round, and she'll try it out again. Details about how the customer will test the software should be worked out early in the process. It's important that the customer understand that she must do extensive testing before the program can go into production. There is no way that you as a programmer can try out or understand all the intricate ways that the program will be used.

Let the customer know that you don't expect her to remember to tell you everything she needs up front, although it's important that she remembers to tell you as much as possible. It's normal and expected for her to think of things during all phases of the development cycle. It's also important for her to be aware of how these changes may affect the cost and time for development. Talking about the development process during the initial contact can prepare the ground for agreeing, during negotiations, on how often you expect to deliver test versions.

Eventually, you'll also need to tell the customer how you work and what to expect from you. What kind of deliverables will they receive? Unless you are developing a product and have specific concerns about distributing source code, including source code as a deliverable is a key selling point. It builds trust with the customer because he doesn't feel he will always be forced to deal with you. This can actually help you keep a customer rather than drive him away. Documentation is another important deliverable. It may cut down on support calls, and can certainly help when you get a support call and haven't looked at the app in a year. Both of those items tend to be important concerns for customers. Identifying the customer's expectations during the initial contact will help when you negotiate the contract.

In the next column, we'll discuss the delicate process of arriving at a final contract.

By Barbara Peisch and Nancy Folsom

Nancy and Barbara welcome your comments about this column. Barbara can be reached at articles@peisch.com. Nancy can be reached at articles@pixeldustindustries.com.