How to interview a customer to take requirements?

Question

I currently work as a PeopleSoft technical consultant, a title that, in practice, means that I'm a PeopleCode programmer. Documents with specifications somehow arrive to my desk and I just implement what the papers say.

However, I'm going to be assigned to a project in which I'm going to be a functional consultant as well, that means that I have to ask the customer what their business processes are and how PeopleSoft should support and enhance these processes. After that, I have to write the specifications themselves, so that technical consultants (myself included) can implement them.

I have no problems with business process modeling nor writing specifications, however, I have never been good at interviewing people nor at dealing with people in first place, so I would like to ask you all whether you have some tips that I could take into consideration before the interview ends in a disaster.

Answer 1

Usually a customer cannot formulate precisely what his business processes are. He won't even be able to think in these terms. You have to pose leading questions for him to "get" the direction and describe the problem to you, one issue after the other.

It is recommended that you ask him for permission to use a tape recorder or just write down what he says on a piece of paper.

What you get from the first interview will provide you with an overview of his needs. You take it home, reflect on it, then try to formulate it with your own words. You sketch something as a wireframe representation of the future system. Then you arrange the next meeting to discuss your vision of the situation. You will be talking, he will be correcting you.

You need to do a few iterations until you both agree that you understand each other.

At some stage of the game you need to talk to real users of your future system. Ask for permission to talk to his employees. Join them in their everyday activities, observe what they do, how they do it, what would they need of the software to help them. Interview them as well. Again, ask for permission to use a camera or a voice recorder. Back in your office you will watch and listen to these recordings with your colleagues and you will be transforming them into business processes.

Answer 2

• Learn the words your clients use, and find out exactly what they mean.

• Always - always - ask for the constraints and exceptions to any business rules the customers tell you about.

• Avoid using technical terms your clients might not understand. You might impress them, but it won't help you at all getting their requirements right.

Answer 3

Even though you won't be using an agile methodology you may want to read up on user stories, and see if you can get the user to just describe as a story what they want the feature to do. Then, you look at the story and see what features are present, and just write those out separately and ask for a story on each of those.

For example, if they want to be able to type in something and get a table of results that they can sort.

Then, what is valid data for what they want to be able to type in.

Should they be able to sort on only one column or sort on columnA and then on columnC, so it actually sorts on two columns.

As you go through this, you can help them understand what they envision and you can have a better idea, and you save the story, so that later, if they complain, you point to the story and explain that you implemented what was agreed on as the goal.

The problem you may have is that this is not going to be how they are used to giving requirements, so there may be some resistance because it is new.

Answer 4

Identify with management each individual role; that is, if five people all do the same thing, that's one.

Schedule a meeting with one person from each role. Get them a cup of coffee. Ask them to walk you through a typical day, and let them know that your team is going to base the first version of a new system off of what you learn.

Screenshot most of what they do if it's computerized, and email it to yourself. Photocopy what they do if it's on paper. Keep the documents in chronological order.

Build a prototype from what you've learned. Go back to the users, and double check that it fits the need.

Finish the prototype, and now that you have users involved, they'll actively ask for new features, which keeps your consultancy employed.

Answer 5

The only thing I would ask the customer for is a rough outline of what their processes are. Listening is optional. Then, and this is the important part, ask where they keep the documentation for their processes, and if they follow that documentation.

Your possible outcomes, ordered from best to worst:

1. Yes all our documentation is [here] and we follow it to the letter.
2. Yes all our documentation is [here] but we haven't updated that in ages.
3. Yes all our documentation is...wait, where is it? That's gonna take a while to find.
4. We don't have any documentation but I can tell you what we do.

Answer 6

This will only answer a small part of your question, but it has helped me immensely.

Do not be afraid to ask stupid questions

So often, when gathering requirements the client will gloss over details as if any fool would understand that part of their business. It is precisely those moments when you need to stop the conversation and say, you really want to understand all of the business process and to please explain that to you as if you know nothing.

I've seen, and been a part of, many interviews where the tangential (or so you thought) questions weren't asked (For many reasons, but in part to avoid looking clueless) only to later find out that it is vital and having to go back 2 weeks later to ask the dump question that you should have asked in the first place.

Make sure you don't leave an interview until you understand the process as well and from the same perspective as the client. If you feel like you have weak areas of understanding, I can almost guarantee you that those areas will come back to bite you.

Plus, its the guy/gal that asks the dumb questions that soon becomes the subject matter expert.

Answer 7

I've been on both side of this table. The usual problem is that the client doesn't speak "programming" and the programmer doesn't speak "subject area". So you end up with assumptions all over the place. The only really good assumption is that neither of you understand the other guy. So:

• be humble. Just because you can code doesn't mean you're smarter than your client -when a client tells you something, paraphrase it back to him in your own words. This lets him know you understood, or lets him correct your misapprehension.
• when you tell a client something, ask him to explain his understanding of what you told him. If he doesn't get it, explain it another way. He's not dumb, he's just speaking a different language.
• make the client understand that details are very important, and exceptions to rules are even more important than details. Clients often think "always" means "usually".
• provide specification drafts to your client and review them with him. This is often where the "gotchas" rear their ugly heads.
• make sure that you get to do all of the above with each user type. They will all have different expectations of the system you're building.