Defining Customer Requirements
by Paula K. Martin, CEO, Martin Training Associates
and Karen Tate, President, The Griffin Tate Group
One of the most important things you'll do in any project is define the customer requirements. But before you begin, you'll first need to determine what the customer needs and wants. The best way to get this information is directly from the customer.
Set up a customer inquiry meeting and ask the customer to describe the final deliverable he expects to receive from the project. Record exactly what he says. Next, ask him to define the need or problem he is experiencing that the final deliverable will help him resolve. Remember, customers don't need deliverables. What they need is a solution to a problem and the deliverable is the means by which the problem is solved or alleviated. All too often a customer will ask for something that he doesn't truly need - it's his interpretation of how to solve the problem. Unfortunately, it can miss the mark. If you use his solution as the starting point without checking to make sure it will truly help, you'll find yourself meeting every requirement and still having a dissatisfied customer. So, before you head down that road, back up and, make sure you understand the pain your customer is feeling as specifically as possible. Verify that the final deliverable will help him relieve the pain. Then you can safely move on to requirements definition.
Ask the customer to tell you what he wants from the final deliverable. A want is a specific solution or a characteristic of that solution. "What do you want this final deliverable to do? To look like? What features do you want? What performance characteristics are important?" As you elicit these wants or desired characteristics (DCs) of the final deliverable, record them on sticky notes and place them on banner paper so that everyone involved can see them. If you don't understand what the customer is asking for, probe for clarity. Don't argue. Don't tell him that he doesn't really need these things or point out that his requests are abominably unrealistic. Simply listen and record. Continue to probe to until the customer is satisfied that his wants have been recorded.
Next, ask the customer, "If the project was resource constrained, which of these desired characteristics would you be willing to give up?" Mark these as 'nice to haves'. Then ask, "Which of these characteristics must be included if the project is to be worthwhile at all? Which ones are you under no conditions willing to live without?" These are the 'must haves'. Mark the remaining characteristics as 'highly desirable'.
Ask the customer to rate the current product or service and/or your competitors' product/service against each of the desired characteristics. Next, have him rate the level of performance improvement he expects from each of the DCs. Discuss how the performance improvement could be measured. Record the responses.
What's you've now done is capture the customer's expectations, in the customer's language. These expectations may or may not be realistic. You'll address that next. Now it's time to translate the DCs of the customer into features and functions (FFs) of the final deliverable. As much as possible, try to keep these in language the customer can understand. You can have several FFs for one DC. Continue to define FFs until you've covered all the DCs. Next assess the resource requirements for the must have, highly desirable, and nice to have DCs. Segment your risk assessment to rate the risk level for each of these three groups. Present the resource and risk data to the customer. Now it's time to get real. What can he or the organization afford? How long is he willing to wait to get the entire list of DCs? Maybe he'd prefer to get the 'must haves' in the first version and the 'highly desirables' in the next. (Include the sponsor in this meeting if the customer isn't paying for the final deliverable.)
Once the FFs have been agreed to, complete your project plan, translate the FFs into technical specifications, and you're set to go. However, remember that when you report back to the customer, use his language - the language of the DCs. It's what he understands since he participated in defining them and he as a result, he also has ownership of them. Deliver the DCs, and your customer will be satisfied.
©2003 Paula Martin and Karen Tate. All Rights Reserved. Published on ProjectConnections by permission of the authors.
Paula Martin is the CEO of Martin Training Associates, a management training and consulting firm. She's the author of seven books including the Project Management Memory Jogger™ (which she co-authored with Karen Tate). For more information, visit www.martintraining.net. Phone: 866-922-3122.
Karen Tate is President of The Griffin Tate Group, a project management training and consulting firm, and author of three project management books. For more information, visit www.griffintate.com. Phone: 877-984-8150.
©Copyright 2000-2008 Emprend, Inc. All Rights Reserved.
About us Site Map View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy