Everything you wanted to know about customers but were too busy coding to ask.
Our last column covered negotiating a contract.
Assuming you got the contract, it's now time for the analysis phase, part of which is requirements gathering.
Like an architect who produces blueprints for a building, you will be producing a functional specification or model for the new system. Your customer will be expecting to pay for this, since it will have been covered during negotiations, as discussed in our last column. In this first column on analysis and requirements gathering, we discuss the various personalities you may meet and some ways we've found to deal with them.
Where do you start?
In the analysis phase, you will form the basis of your relationship with the customer. How you interact at this point will create an impression that will last the length of your relationship, and a good relationship with your customer will help make the project successful.
This brings us to a point about style. There are at least two distinct styles in approaching this phase. One is the programmer who comes in with the idea that the software is important. Another is the programmer who believes that the customer's business is most important. Our bias is with the latter style. Not only is it our nature, but the first has never worked well, in our observation. It's been stated many times in various ways, but it bears repeating: while you listen to the customer, resist the urge to respond immediately. Customers will tell you what you need to know, using their own words. If they try to use our terminology, they will be throwing around terms like “client-server,” or “web-enabled” without the slightest idea what the terms mean. Instead, get your customer to talk about what he does and with whom he works, using everyday language as much as possible. After he's done, paraphrase what he told you to confirm that you understand.
Customers are like everybody else in that they love to talk about what they do. Even when your customer has told you that he has no time for a formal analysis and design phase, if you just let him talk about work, you'll get the time you need. For example, if one of your tasks is rewriting a sales summary module, at your next meeting or follow-up call you can ask about the quarterly sales meeting with the new district manager. Find out how he used the existing tools to prepare his report.
Be prepared to be flexible. We usually get a variety of projects which require a variety of skills. We not only have to be good at understanding programming and computers, but also good listeners. We have to know enough about the customer's business to understand what we're building. If you get to the point that your customer would offer you a job in his area of expertise (not software development), that's a good indication that you're listening well.
Personalities at the top
The person who negotiated the contract with you will most likely introduce your primary contact for the project. In some situations, the contact and contract person may the same. The new system has been discussed previously during the initial contact and negotiations, but now your primary contact will need to give you more details. The earlier you can recognize the personality of the primary contact, the better your chances of gaining the needed cooperation by adjusting your style. Your primary contact might be one of the following:
The Corporate Oracle: He's been with the company four days longer than dirt is old and he knows every job in the company, as well as the stakeholders. He's a great contact...if he's not completely cynical. Perhaps he's seen too many consultants start out in a blaze of promise and end with a whimper of contract disputes. He can tell you what's been tried, how it worked or didn't, and why. He can tell you what products will actually be used versus what people say they will used. He will also be able to guide you around corporate sensitivities and budget quick-sand pits. Oracles are hard to impress, except with performance. Stay focused on the goals of the project and use The Oracle as an oracle.
The Corporate Martyr/Superman: She can't say no to any project and therefore can't do any of her tasks thoroughly, although she'll be most effective on the very latest project. She's helpful, enthusiastic, and genuinely cares about the success of the project. The problem will be competing with her other projects, and if she gets another one, she will be forever in meetings about it. Also, she might want to retrofit your project with bits and pieces of the new project. However, the martyr/superman usually has a lot of corporate knowledge, knows who to talk to, and rarely has an ulterior motive, since she doesn't have time. Keep your contacts with her specific, by having short lists of relevant questions with reasonable alternatives from which she can choose. If you find another contact who might make a good second in command, suggest that your primary contact delegate some of her work.
The New Kid on the Block: He doesn't know the corporate culture very well and may be prone to offending important stakeholders with brashness. He sometimes is more focused on making his new position look and feel like the previous one, so he may push for unnecessary retooling that obscures the project's real needs. He may not have the stature in the company to track down hard-to-find documents, get commitments for participation from senior staff, and so on. On the other hand, the New Kid is enthusiastic and usually free of intra-company political entanglements. Be sure to back up his opinion on the project with input from stakeholders.
The Hermit: She's probably got as much corporate knowledge as the Oracle, but nobody is really sure, because she doesn't want anyone to know what she does or how she does it. She will resist letting you have her database (it's probably in Excel or a Word table), even though it duplicates other corporate databases. The Hermit is often a stakeholder, but sometimes is given a project to manage if the project is somewhat mysterious. The reasoning seems to be that if a project is hard to understand, it should be given to the person in the organization who is hard to understand. For this personality, it's critical that you observe and analyze the users. Try to show the Hermit that the company works similarly to how she works, and how valuable her expertise will be.
Is she a stakeholder?
Each of these personalities can be a stakeholder, in addition to being your primary contact. Stakeholders are the people who have a reason to care about the system:
Direct users, such as data entry clerks, analysts, or machine operators.
Indirect users, such as managers who receive reports, or other systems for which your system will provide input or output.
Bystanders, who are stakeholders with a political or similar interest in the system. For example, the director of the organization may hope for an elevated position within the corporation if the project is successful. Or, the contractor whose system you are replacing may have a stake in the outcome.
The primary contact should introduce you to the stakeholders and arrange for you to meet with them. But, if allowed, be sure to interview and observe the direct and indirect users, to see how they work and to understand the company's workflow. Listening to the stakeholders alone is not sufficient, because there is a difference between what people tell you they need, what they really need, and what they want. Sometimes, the description of their needs is inaccurate, such as when they try to use words they think we'll understand instead of their natural language. Sometimes, people give implementation details instead of really describing the need.
For example, Nancy had a client who half-jokingly suggested that she wire the users' chairs so she could send a shock if data were left blank. The need wasn't for a cattle-prod. The need was for certain important information to be filled in correctly. Sometimes users will adamantly identify a want as a need. Knowing the difference can save you from spending valuable time coding for a particular person's idiosyncrasies that are out-of-synch with the rest of the users. Also, as you budget time on the project, address needed requirements before wanted requirements. It will help keep everyone focused on the right goals.
In rare (and joyful) cases, your primary contact will already have all the information that observation would have given you. If so, that will be apparent during negotiations. However, even then you will want to get a feel for the working environment, to better understand what your contact is telling you.
Stakeholder personalities
There are many types of stakeholder personalities you're likely to meet during analysis. Here are some of the most common and how to deal with them.
**The Advocate: ** This is someone who actually wants the new system, sees its potential, likes the process of designing a new one, and will offer his knowledge and time to make the project successful.
**The Know-it-all: ** This person needs to impress you with her knowledge, and wants to make sure you know that she has all the answers. Listen to her and ask questions when appropriate, but make sure to confirm any information you get from her with someone else. Don't let her dominate group meetings. Usually your primary contact is well aware of this person's foibles and will support you. Be politely firm
when cutting off a conversation that's straying from the main topic, and offer to continue the the discussion after the meeting.
**The Uncooperative Type: ** This is a person who says he's too busy to deal with you, or pretends to cooperate while giving useless or resentful answers. Tell him that this is his chance to influence how the new system will work, and to make sure it has the features he wants. Explain in a tactful way that if you're bothering him, you can just find someone else who has more time to tell you what the system needs are. If the uncooperative person is your primary contact, you may have to be more creative. With any luck, you will have someone else to work with who is more cooperative. Explain how your primary contact has too much going on to deal with your requests, so you'd like some additional help.
**The Staller: ** This person is quite happy to help you, and will look at your requests when he gets some time. It should be any day now. He may have the best of intentions and may just be overworked, or he may not really be all that interested. In either case, the result is the same. If you can't get answers within a reasonable amount of time, set a deadline. Let him know that you understand he may be too busy, and that if he can't get back to you within that time, that you'll ask your primary contact for another way to get the information. Make sure to document your request, so that if this issue comes back up, you can show that you tried to get what you needed, but had a time schedule to keep.
**The Mole: ** This is the person who wants your project to fail. She might be an in-house developer who had hoped to create the system you've been hired for, the developer of the system you are replacing, or someone with a relationship to one of your competitors. You can't ignore her, and you can't take what she tells you about the system as genuine. Sometimes, the Mole will appear to be positive and helpful, but will also write critical memos, complain to indirectly related managers, or sabotage testing.
The Hermit: The Hermit as a primary contact was discussed above. As a stakeholder, he might be the owner of important data or someone responsible for a critical task. He can be a bottleneck, stalling on your requests for information. In rare cases, he can become an advocate, but more often you will need to work around him. Don't, however, ignore him. He usually has a good reputation in the company and is the sole source of information that is perceived to be critical (although it often varies from the other public corporate information). As such, he will need to be involved and given a chance to appear to be cooperative.
**The Quiet One: ** She sits in the back of the meeting and just listens, occasionally making apt suggestions, but offering them only once. The Know-it-all often inhibits her in meetings, so one-on-one interactions with this person are most productive.
Conflicting Information
You've talked to the primary contact and all of the stakeholders. In some areas, they all agree. In others, you get a different story from each of them. How can you determine what the system should do when it seems no one can agree? After you and your primary contact agree on what the issues are, and agree on a few reasonable options for resolving conflicts, get the stakeholders together for a meeting. Work as a team with the primary contact, presenting your findings to date, starting with the features that everyone agrees on. Then, present areas where you've been given conflicting information. Be careful not to single out anyone at this point. Just present the conflict in a factual, non-judgmental, non-accusing way. It could be that each person gave you accurate information as they view it, and you've uncovered a potential problem. Having all parties present at this meeting is vital, because each side can present the facts as they see them and probably discover new viewpoints.
Your toughest job during this meeting is to avoid confrontation. If you don't resolve all of the conflicts, at least your customer will now be aware of them. Steer discussion toward a clear decision on every issue. The decision might be a solution or a plan to discover a solution by a specific date. If no consensus is possible, the stakeholders must understand what decision is finally made and under whose authority it was made, so document any controversial decisions.
In the face of institutional conflicts, your contact must understand exactly what information you need, when you need it, and the impact on the system. Your first act after the meeting should be to transcribe your notes and document the issues for your primary contact. You can help your primary contact with these decisions by considering the likelihood of any particular decision being right or wrong, and the costs associated with each decision.
As an example, say your customer deals in catalog orders. The old system accepts a catalog number, then displays the item description, price and availability. Customer service says that too often, the sales associate doesn't check the description shown and orders the wrong item. One solution is a dialog pop-up that shows the description and forces the sales associate to confirm it. But, the Order Supervisor doesn't want this extra step for each item because it will slow down the order process and annoy the customers.
Let's weigh the options in this situation. Before making a decision, we need to know how often the wrong item is ordered. Therefore, we need customer service to provide information about how many incorrect vs. correct items were ordered over the last three months. Perhaps it turns out that 10% of items shipped are incorrect. That is a fairly high percentage, and is probably causing some bad public relations. The cost of adding the extra dialog is low. The chance of it causing customer annoyance is low, based on data from other companies already working this way. The chance of resolving the incorrect shipment problems is high. Finally, the cost of removing the additional dialog, should you decide this wasn't the correct decision, is low. It seems that adding the dialog is the correct thing to do, but make sure you let your customer make that decision!
Resist all temptations to advise on institutional decisions. Although casually talking about experiences with other companies can be helpful, it's really none of your business how your customer solves the internal conflicts, as long as their decision allows you to fulfill your commitment.
If you approach each customer the same, you may find part way through a process that communication has ground to a halt. “But,” you'll say, “I'm using the same technique that worked for my last client!” If you find yourself in this position, check your contact's personality again. Maybe you've been relating to an Oracle as if she were a New Kid.
Next: Analysis, Part 2
Now that we've introduced some common personalities, it's time to get down to requirements gathering and producing a specification. In our next column, we'll introduce concepts and tools for doing just that.
Nancy Folsom and Barbara Peisch
