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.
About the author
Brad Egeland is an IT, project management, and business strategy consultant and author with more than twenty-five years of software development, management, and project management experience leading business and IT initiatives in nearly every industry imaginable. He works with organizations of all sizes from startups to Fortune 500 leaders and has overseen the creation and execution of multiple PMOs. Brad is married, a father of nine, and lives in Las Vegas, NV. He can be reached at brad@bradegeland.com or you can visit his website at www.bradegeland.com.
