Clients

Clients come in all shapes and sizes. Whether you are independent consultants who work with your business customers, other developers, or subcontract on jobs for another developer ‚ s clients, or are corporate developers who work internally on the computing staff and develop solutions for other people in our company, you all have clients. Dealing with clients can often become harder than developing the software you deploy. Learning to work with your clients can often require or qualify you for a certificate in psychology. The fact remains, this human interaction is an important part of the development and deployment facets of the projects you work on.

Dealing with customers

This section discusses some tips that lead to positive and profitable interaction with our clients. Without a good basis of customer interaction, the odds are deployment will never happen or be extremely difficult.

The First Meeting

The first meeting is where you get to make the all important first impression. It is the foundation of everything to come. You only get one chance to make the best impression at the first meeting. No pressure, right?

Try to understand the players at the meeting. This requires asking the main contact who you can expect to meet at the first meeting. Remember the names of the people involved. Will it be the CEO, the Chief Janitor, the Controller, the head of the computer department, or the end users? Knowing who will be in the room helps you prepare for the meeting, helps you determine the agenda, and what you need to prepare for the presentation. Understanding the expectations of the potential client will also help in this regard. Showing up with a demo of your product line when the meeting is with the legal team might not be as useful as showing up with your standard contract, prepared to discuss the sections, and know the areas open for negotiation. On the other hand, stepping through a slide show and demonstration of your vertical market application when the project champion and lead decision makers want to see what you have to offer might be appropriate. For these meetings you might want to bring along the marketing brochure and demo copies that can later be loaded on their computers.

A couple of months ago I showed up at a potential client ready to discuss what our company was all about. We sat down in the conference room of this manufacturing plant. I was referred to this customer by a fellow developer. While I expected to pitch the sales presentation, he showed up with five file folders, each with the specs for the first five projects he wanted me to work on. He was already sold based on the recommendation. I could have been better prepared, but the meeting went well despite the misunderstanding.

Dressing for the occasion is very important. Image and professionalism is everything. Understand your client ‚ s work environment. Are they business casual (Dockers/button shirt), ultra -casual (torn t-shirts and jeans ), or business attire ( suits and ties, skirts and blouses)? Dressing to your client ‚ s dress code removes any possible uncomfortable situations. I will never forget a meeting when my client threatened to cut off my tie. I worked for EDS when there was a strict dress code of suits and ties. My client was a corporate vice-president for the financial subsidiary of General Motors. GM was business casual at the time, and my customer felt it was intimidating we wore ties in their environment. We did get past it when I loosened my tie any time we met, before our organization finally went business casual. The first meeting is the most difficult because you need to ask what the dress code is.

One of the easiest ways to impress the potential client is with competence and composure . You can do this several ways. First of all you can provide your client with company marketing material. This is easy to provide in advance of the initial meeting. Showing your core competency in software development can be handled by listing projects, lines of businesses, customers, and technologies you have used in solutions. Highlight those items closely related to the problem they want solved . For instance, if you know one of their problems is they need to move to a Web-based solution, note the projects and the technologies you have deployed using Web solutions. It also helps if you can show them some white papers, articles, or books you have written on the subject. For some reason it gives you instant credibility. It might help if you can link them to your Web site based resume, Curriculum Vitae, or references. This applies to both corporate developers and independents.

One key to the initial meeting is to find out if there is competition for the project. Knowing this helps you slant the presentation to show how much better you are than the competition. You may often find you compete against the same developers or companies. Knowing your strengths that position you better against your competitors makes the customer ‚ s decision to select you that much easier.

Show your customers the light on specifications/requirements and testing. Let them know your expectations concerning their participation in this process. Follow up with the person that gave you the reference and the people you met with at the sales meeting. It shows you are interested. It shows the customer you care and you are serious in partnering with them in their projects. It also shows you value good and frequent communication, which is one of the facets to leading a successful project. Following up with the reference person is also good, doing so might lead to another reference in the future.

General Concepts

Once you have worked through the first meeting and shown the customer you are the right person/ group for the project, you need to nurture the relationship. We do not always implement each of these ideas for every customer, but it should provide you with a good start on ideas we have in our foundation as we move forward with our customers.

All successful relationships, whether business or personal, should be based on mutual respect and trust. This is a natural. If you don ‚ t respect your client, it ‚ s likely you will not have open communication. We have worked for a lot of people, both bosses and customers. We can say without hesitation that the people we enjoyed working with the most are people we respected and learned we could trust. Those that did not fit this mold were jobs we dreaded doing and found the most troublesome .

Communications Cubed! Communications, communications, communications! Open, honest, and frequent communications eliminates many problems before they happen, and typically resolves much sooner the problems that do occur. This is another natural concept, but for some reason it is one of those problems that always seems to climb back into our projects. The thing we find strange is today we have more ways than ever to communicate with other human beings, yet have trouble communicating. You have phones you clip on your belt and work almost everywhere, postal service mail, overnight delivery mail, e-mail that can travel around the globe in seconds, beepers in a watch you wear on your wrist, walkie-talkies, video conferencing over the Internet, and even the fax machine. With all of these technologies at our disposal, why is it that a high percentage of project-related problems can be attributed to communication issues? It is amazing.

One of the first things we do is find the keeper of the money. We recommend you introduce yourself to the accounting department/person as well as the person who authorizes your payment (which in many cases is your main contact). Whether this is an internal transfer of funding between departments, or an actual check paid to an invoice, you want to make sure the individual who will pay your bill knows who you are. It is better to get this done up front than the first time an invoice payment is late. Another key is to find out what the payment cycles are. We have run into a number of organizations over the years that have mysterious accounting practices where the accounting software only prints checks on a specific day of the month. We know this is just creative accounting practices for companies to hold on to their money longer, so we find this out up front in order to time our invoices for optimal payment processing.

The stakeholders/ champions /project leaders are important. They are the people who really want to see the project be a huge success. Often they are using this project as a booster for their career aspirations and/or have a large financial bonus riding on the completion. They are the go-to people when things need to happen to move the project forward or get over hurdles along the way. Make sure you have a solid and positive working relationship with these individuals.

It never hurts to understand the organization chart. Knowing the boss of the stakeholder, the boss of the accounting person who pays your invoice, the head of the IT department, and how the end users fit into the picture might be helpful as you interact with different people. Knowing the right people when you start collecting requirements and writing the specifications leads to smother deployments.

There are some basic fundamentals like following the Golden Rule (do unto others as you would want done unto you) that work in the business world as well. Make sure to follow your client ‚ s wishes and always assume their goals should be your goals. If you do not help them achieve their goals you will be shown the door very quickly. The key here is to learn what the goals are and plot a plan to achieve them.

Understanding the politics of the office also makes your life a lot easier. Politics are almost a sure thing in larger organizations, and there are better than even odds you will find it in organizations of all types. Knowing the ins and outs of the office politics allows you to not trip over your own feet when dealing with the individuals. One example we can relay in this regard is the perception of playing favorites. We frequently find when we are in the requirements phase that some individuals perceive someone else ‚ s feature is being given more attention than their own feature. As developers we know all features are important and there are priorities, and we typically focus on one at a time, hopefully in the order of priority. Some users might get an attitude that a developer is playing favorites with others in the office, which can lead to problems. The worst case is the person who waits for the developers to finally get to their feature is not cooperative when the time comes to gather their requirements.

Lastly, we often need to educate the customer on the processes of custom software development. Many of our new clients have never been through a custom software development process. They need to understand you are not stopping by the local software store, purchasing the package off the shelf, and installing it the day after the specifications are approved. They need to understand the concepts of specifications, development, testing, installation, and technical support. They need to learn that each step takes time and you need to set the expectations of what is to follow. Doing so is all part of the Communications Cubed mindset.

Working with subject matter experts

You know developers often collect requirements from the domain ‚ s subject matter experts (SME). An SME possesses unique experience and expert knowledge in technical, functional, and/or process areas in their industry or company. They apply best industry practices and standards, current technology, and creative solutions to challenging problems they face. The subject matter experts are the super users that understand the requirements, the business processes, and the day-to-day operations. They can tell you the exact steps and formulas to calculate the shipping charges, the way interest is calculated on a car loan, the steps to check a person into a hospital, the information that needs collecting when a person is evaluated, when thank you letters are sent to clients for their recent purchase, when a reservation is logged, and what credit cards are accepted.

These individuals should dictate the base requirements for the application. We have worked with all kinds of subject matter experts in our careers. They could be the vice- president in charge of operations, the accounting manager or comptroller, the department head, the employee that worked for the company the longest and experienced several positions , and sometimes even the CEO (usually in very small companies). We found over time that software developers who work in one industry for a long time often become the subject matter expert.

We generally find spending time with the subject matter experts allows the requirements phase to be shortened . Naturally there are many factors leading to a successful deployment, but one of the strongest factors in determining a successful deployment is how well the application models the business issues. Subject matter experts hopefully will be key players in getting the proper requirements. Once the requirements are written down, make sure the SMEs review the documentation and certify it correct. Skipping a review at this stage will negatively impact deployment.

One rule we have in working with users when collecting requirements is we do not let requirements collection meetings last more than 4 hours (including breaks). It is our experience that you start to see a negative return on the time spent after the first four hours.

It is also important to establish roles and responsibilities for the subject matter experts. We like to inform them that they will be needed during the development cycle to answer questions from the project leader, provide additional details not collected in the initial requirements collection, be available to review ongoing development, and provide customer acceptance testing when the application or a component is ready. The key to working with subject matter experts is communication. We find open and regular communication with all parties in the project leads to better solutions.

Talking to the real or end users

One thing we often overlooked during the software development cycle is including the real users, the people who work on the front lines and will use the software on a daily basis. It is our experience more often than not that these people are not the same people as the subject matter experts, but they can be.

These are the clerks, the data entry person, the sales person making an order, the assembly person on the shop floor updating inventory, the security guard checking a visitor in at the front desk, the bill collector placing a call to an overdue customer, the fireman entering in the latest pump test, the administrative assistant updating the dentist ‚ s schedule, the policeman filing a complaint report, or the statistician updating the basketball player ‚ s shots from last night ‚ s game.

We find in spending time with these people is where you collect the nitty-gritty details about the business processes. It is where you find out your user interface is a hindrance, not smooth flowing , and unproductive. The real users tell you how it can be better, how you can make their pain go away. Where the subject matter experts might be very good at big picture and visionary decisions, the real users provide more detailed processes and point out shortcomings in productivity.

The real users are especially helpful when you are updating existing software or rewriting an application. They already know how well they like certain heads-down , data-entry features. They also know where the holes are and what they do not like about the existing package. Getting a handle on what they like and dislike about the current environment is critical to your success. One particular application for which we were writing a specification was for a sales force at a service company. They took calls from a large customer base for repeat business. They basically completed the order in less than a minute, and then scheduled the work. If we wrote the order form and it took more time, then we failed to deliver on the full requirements. The subject matter experts on the other hand might have detailed all the items that needed to be collected from the customer and provided us the algorithm to calculate how the service was scheduled.

It is also important to establish roles and responsibilities for the end users. We like to inform them that they will be needed during the development cycle to answer questions from the project leader, provide additional details not collected in the initial requirements collection, be available to review ongoing development, and provide customer acceptance testing when the application or a component is ready. In practice, we found we communicate less with the end users than the subject matter experts if they are not one and the same.

Handling those ‚“special case ‚½ customers

It is likely you have run into the ‚“special case ‚½ customer. These are the ones that can be classified as high maintenance and require special attention, or more likely additional attention. We find this type of customer usually causes us grief and we spend an enormous amount of non-billable time pacifying their needs, complaints, and special wishes. You have to determine what your threshold for pain is when dealing with each individual case. Sometimes you work around them when the client is worth the extra effort necessary. Sometimes you are better off telling the client they need to change who you work with or find another developer to handle their computing needs.

Someone we will refer to as ‚“Jennifer ‚½ is my favorite special case customer. She was with this company for nearly 30 years and each day you hoped to be invited to her retirement celebration . On a good day you could expect her boss, who was the Information Technology (IT) manager for a large manufacturing company, to call the president of our organization to voice her issues. Imagine a very well paid IT manager dealing with mundane issues and the president of our company taking time out to assure him our staff was indeed working hard to finish up the latest feature on their current project, all because Jennifer got fired up that a developer broke a field validation or had a couple of labels misaligned by a pixel or two. She regularly took a little problem and made sure everyone in our customer ‚ s IT department knew about the problem and how stupid the developers on our staff were. On a bad day she would call a developer for technical support, ask an incomplete question, and scream at you because you had to ask a question for clarification of the issue. More than one of us on the staff was called incompetent during a phone call or even during a face-to-face meeting. As much as you wanted to politely tell this person to get a life, you knew anytime you upset her you were risking an account that was paying more than a million dollars a year for development and support and your job was dependent on her satisfaction.

‚“Kelly ‚½ is an administrative assistant at a small organization (three people total). One of the services we provide to this organization is to update virus software, run checks for spyware, defrag hard drives , diagnose broadband performance problems, and update software. This general maintenance is scheduled and performed regularly. Kelly knows we are coming at a specific time and knows we will need control of her PC for a short period during our visit. Most of the time we either interrupt a game of Solitaire, or a Web browsing session on material not related to the organization, and she is physically upset when we interrupt her. During our maintenance session she will talk on the phone with someone about things of a personal nature, not professional. She will ask us if she can get back to her important tasks several times during a short stay.

We are sure we could swap stories for hours on this topic. There are customers that never call or complain, yet when you review the error log there are dozens of issues that are simple bug fixes, but customers think they caused them. There are customers that only call and complain when something is wrong with the invoice (typically that the invoice is too large despite the fact you billed a bunch of no-charge time you knew they would never appreciate). There are customers you have to show for the millionth time how to run the invoice cycle despite the fact it is well documented in the help file you assembled for a tenth of your normal rate. You all have them and you all need to deal with them. As the saying goes, if they do not kill us, our character will be stronger.

As far as deployment issues with these customers are concerned , we found that addressing their hot spots is very important. Know their strengths and weaknesses and use this knowledge to smooth out the deployment process. In the case of Jennifer who always made a big deal about pixel alignment of labels, we decided to take extra care when building user interfaces and made sure the quality assurance team cracked on developers when a problem was found in this respect. By reducing problems they find, you can take the ‚“special customers ‚½ off their game, and this is the best way to remove them as speed bumps in the deployment process.