Question Your Project Customer

When leading technical projects, project managers and their teams know the task ahead can be a daunting one. So, when the customer comes with a desired solution all mapped out and detailed requirements in hand, the first thing you want to do is move forward. Your planning work, requirements gathering, and selection of a technical solution is all done for you. After all, it’s the customer’s money, so why argue, right? Wrong. No matter what the customer says he wants and how he wants it done, at the end of the day, if it doesn’t solve the customer’s true need, it will be your fault.

The Customer’s Perception
One of the first things the project manager and team must learn is to never take the customer's needs at face value. The project customer has hired you and your team as the experts to implement his solution. He may come in with a plan of his own: knowing what the problem is, wanting to use the latest and greatest technology, and thinking he has the requirements all mapped out for your team. The problem is that the customer may only be looking at a symptom of the true problem. How do you deal with that? How do you even identify if that is the case? In order to identify, verify, and move forward, there are three things you must do: ask the tough questions, map out detailed requirements, and document the right solution.

1. Ask the Tough Questions
The first thing you absolutely must do is ask your customer some tough questions. The customer came to you with what he thought was the real problem, so you risk offending him by questioning the project sponsor’s judgment. But, as uncomfortable as it is, it has to be done if you want to be certain that you and your team solve the real problem. Ask questions like:

• What efforts have you undertaken to determine the real need or problem?
• Have you surveyed your end-users to verify this need?
• Have you mapped out your business processes to confirm this is a real project issue and not just a policy or procedure issue?
• Does your senior management buy into this need? Do you have their backing and agreement?

Meet with the project sponsor, all customer stakeholders, any available subject matter experts (SMEs), and end-users. Ask them for their perception of the problem or need. Chances are, not all responses will match your project champion’s perception on the customer’s side. And if the answers are all related but don’t match, then you know that some of the respondents are actually looking at symptoms of the real problem. Now, it’s your job to ask more questions and to figure out what that real need truly is. Then—and only then—can you go back to the drawing board and map out the requirements for the real solution.

2. Map Out Detailed Requirements
In the best-case scenario on every project your customer comes with detailed requirements all mapped out for you and your project team. But even if they do, as we’ve discussed, you still have work to do. You can never take those requirements at face value because they may be pointing to the wrong final solution. Likewise, you can never assume that they are complete enough or detailed enough to derive a final solution from. No matter how detailed the customer’s requirements are and no matter how confident the customer may be that he has correctly identified exactly what the project entails, always build requirements planning into the project schedule and plan to drill down deeper into the requirements. Or, in the worst-case scenario, start completely over from scratch.

So, let’s assume you’ve asked the tough questions and you’ve identified the real need or confirmed your project sponsor’s perception. What next? The key is to drill down to detailed requirements that you can use to build a solution instead of just running with your customer’s requirements.

Schedule a series of requirements meetings to review your customer’s documented requirements and to verify that these are as detailed as possible. If they’re not—and 99 percent of the time this will be the case—then you must hold the customer’s hand through this process. If you try to build a solution from the wrong requirements or from requirements that are not detailed and complete, then you’ll find yourself deploying a final solution that doesn’t solve the customer’s need. At that point, the fingers will be pointing at you. Take time up front to plan and document the requirements and make them as complete as possible.

3. Document the right solution
Once you’ve verified or rewritten your customer’s detailed requirements, you can then document the right solution and the right technology selection for the implementation based on those now very complete and detailed requirements. Revisit and revise the statement of work as necessary, and build a functional design document for your customer and for your project team to lay the groundwork for the design and development phases of the project.

Good requirements are everything, and too many times the customer is coming to the table with a symptom, not the real problem. If the project manager and team don't dive into the real requirements, the solution they build will not meet end-user needs and will ultimately be deemed a failure, even if what they built was what the sponsor requested. Seek out SMEs and meet the end-user needs. The only way to ensure that you do that is to plan, plan, plan with the customer and ask the right questions up front. Assume there’s more than meets the eye, and that will help keep you out of trouble—at least most of the time.