Your Customer Has Rights…. And Responsabilities

Let’s talk about what the customer has a right to expect from us. The customer can expect that analysts will speak the customer’s language and that we will learn about their business. This means we don’t throw a bunch of technical and design requirements at them and ask if this is what they want. Developers will explain their solution and will treat the customer with respect. Developers will NOT tell the customer how they should be using the system. And developers will not become defensive if the customer doesn’t think the proposed solution will meet their needs. The customer can expect that they will be provided opportunities to adjust the requirements as needed, within the defined process. They can expect that we will provide them with good faith estimates for the work. And, above all, they can expect a system that meets their functional and quality needs.

We are often focused on the customer rights, and so is the customer. But sometimes we forget to discuss with them their responsibilities. Often we assume they understand our process and know what their responsibilities are. As a result we don’t bother to tell them what we expect from them. Sometimes we skirt around the issue because we don’t want to “upset” them by telling that we have expectations about what we will receive from them. Sometimes we just don’t even think about it. So what are the customer responsibilities? Well, let’s be clear about what we expect from them.

If we are going to learn about their business they have to teach us. We expect customers to be precise when providing information and to make timely decisions when necessary. We expect customers to prioritize requirements and not just assume all requirements are a “high priority”. We expect customers to review documents that we give them and provide us with real feedback regarding the accuracy of our problem statement (user requirements). We expect customers to communicate changes as soon as possible and not wait until the last minute to provide them to us. Lastly, we expect customers to respect our requirements process. If we expect them to respect our process then we need to make sure we all know what that process is, including the change request process. If we cannot explain our requirements process, then how do we expect customers to understand out process? Being able to help customers understand the process is a critical piece of getting customers on board with our processes.

By communicating this information during the project kick-off meeting we are ensuring that we all understand our responsibilities to each other. It’s not just a one way street. Customers who tell us once what they want and then never communicate again will be the ones who say “I told you what I want, why didn’t you build it?” Analysts who document the requirements and never discuss them with the customer are the ones who say “We built what you told us, you didn’t know what you wanted.” Let’s remember there are responsibilities on both sides. And let’s make sure this is made clear to everyone on the project team. Think about your customers. Do they understand and respect your requirements process?

BY: Marcia Stinson