Customer relationships are an often-overlooked part of what we, as programmers, do.
But customers are essential; after all, they're the ones we are creating systems for. We've heard from many programmers that customers are obstructive, stubborn, and computer-illiterate. Have you experienced similar frustrations? Why do projects often seem like battles, rather than cooperative efforts to solve specific problems?
As you might expect from the title, this column is not about programming. Nor is it about customers of broad market products. One exception to this is when a specific person or company has contracted with you to develop such a product, which they will market and support. In this case, the customer relationship is the same as customers of specific software projects. The goal of this column is to present some strategies to improve our customers' satisfaction.
What Do We Mean by Customer?
Who are we talking about when we say customer? For independent developers, this is clear. A customer is someone who hires you for a project. But if you are a corporate developer (any employee-developer qualifies as a “corporate developer” for the purposes of this column), you have customers, too. Indeed, we've found treating the boss and coworkers as customers improved our effectiveness. The situation for independent developers who are brought in to work with a team in a corporate environment is much the same for corporate developers. Sometimes we'll use client to refer to primary point-of-contract (pun intended).
There may be many customers when dealing with a client's company. If you are a corporate developer, there is your immediate supervisor and possibly her boss or other management. If you are independent, there is your main contact?the client. Then there are end users and the people they work for. Keep in mind that even though you may not have an opportunity to communicate with all the customers in this case, it's still important to keep them happy. Sometimes that's not easy.
General Rules for Customer Satisfaction
Customer satisfaction comprises many elements, only a few of which are related to the software you are developing. Here are some general rules we have found to help achieve and maintain customer satisfaction.
Rule 1 - Keep your ego out of programming
This rule is arguably the most important technique for assuring customer satisfaction. If your ego is too involved in your project, then the tendency is to get defensive when customers ask for changes or report bugs. Remember, change and enhancement requests are a good thing, not personal assaults. In addition, we've found that when we have our ego involved in our decisions and code, we are less likely to see a solution that might suit the problem better than ours does.
Rule 2 - Don't care more about your project than your customer does
A corporate old-timer once told Nancy, “Don't care more about your project than your client does.” It was a hard concept to understand for a long time, but it is a reminder that there are often many unseen influences on your project. Understanding this can help to keep the same perspective on the project that the client has, which means you will have a better chance of understanding how the project fits into the customer's larger business.
Rule 3 - Don't care more about your project than you do about your customer
This is twist on Rule 2. It may seem obvious, but we have found it easy to forget that it is the customer's goals that should be your focus. The project is secondary, and is only one of several solutions?even if it is the best, in your opinion.
Rule 4 - Treat the customer and all users with respect
You are dealing with intelligent human beings. You may think that some of them aren't so intelligent, but remember, if they were the wizards, you wouldn't have a project. They are not experts in your area, but they are experts in theirs.
Never do anything that makes a customer feel stupid or intimidated. And never, never, never make your customer look bad in front of others. If he deserves to look bad, he will do it all on his own.
If your user calls when she has problems, you're lucky! Some won't. They'll reboot their computer or come up with elaborate workarounds. Then they'll malign your system to their supervisors. Dealing respectfully with each customer can be proactive damage control.
Rule 5 - Keep your eye on the ball. What problem is being solved?
Rule 5 is related to Rule 3. Focus your communication on how the work you are doing fits in with the customer's business needs. Nothing can blow a budget or timeline faster than getting sidetracked. It may be nice or clever if some great feature is part of the system. However, if it's not in the specifications, don't do it unless you get written approval first. When getting approval, make sure you explain to the customer why you feel this change or feature is necessary, and how it affects the budget and timeline. It's often possible to hold off on a feature until a later version, or you might better see how to bundle in a feature with another one already planned with minimal impact on the project.
Rule 6 - Keep the customer informed
The only surprise customers like are projects delivered under budget and early. If you realize something can't be done as specified or within the budget or timeline, inform the customer as soon as possible. Explain why you came to that conclusion, and provide a few alternatives. Don't wait until you send an invoice that is over budget, or turn in a timesheet for way too much time.
We'll go into more detail on these rules in future columns, and we'll show examples of how you can use them in the various phases of system development.
Initial Contact
Often a potential customer doesn't have much experience with program development. If you're an independent developer, you need to make clear your expectations of how things work. That includes the various phases of development and what goes on in each of those phases, as well as deliverables, your billing rate and frequency, and any responsibilities or roles the customer will need to fulfill, like testing and signing off various phases of development.
If you're in a job interview for a position as a corporate developer, it's more likely you'll need to find out what the potential customer (employer) expects of you, but you do need to make sure you voice any expectations that you have. Customer expectations for corporate developers will include things like following corporate policies. You'll need to find out what those policies are.
Analysis Phase
As much as is allowed, you should interview and observe the people who will actually be using the system. Watch how they work so you can understand the company's workflow.
At this point, you should start to get a sense of what roles various people are playing. We'll give some strategies for how to handle some of the various personalities you're likely to run into in one of our future columns.
Program Development
During program development, you're working on your own more than interfacing with the customer.
But it's important that he always stays in the forefront of your mind. In this phase more than any other, it's vital that you think from the perspective of a user as much as possible. We'll also discuss delivering interim versions during the programming phase, and the pros and cons of doing so.
Testing
The number one mistake that a lot of developers make is they assume they are the only one who needs to test their code. Sure, you need to test your code to make sure it runs the way you expect, but the users must be the ones to perform the final test on the system. This is one of the hardest phases (next to design) to get cooperation. We'll discuss some strategies to keep customers on your side.
Maintenance
This is the phase that many developers dislike the most. It's also one of the most important phases for maintaining a good customer relationship. If you drop the ball when it comes to maintenance, not only will you not get any further work from this customer, but also you won't get any referral. If you're an employee, you risk a bad review and no pay raise, or even losing your job. We'll be covering ways to keep your customer happy for the long haul in upcoming issues of Code Magazine.
How To Move On
In our next column, we will go into more detail on how to make the initial contact, including how to make a good impression, how to evaluate the problem to be solved, and some client education.
Barbara Peisch and Nancy Folsom
