Author: Brad Egeland
A customer's initial perceived needs for a project often don't mesh with reality. Part of our job is to look at customers' issues and ask the right questions to find out what they really need.
How to get the actual project requirements
If a customer brings you a project that he or she has mapped out, the customer has likely already thought about implementation, technology, and possibly even how much the project will cost and how long it will take to complete. As much as you might want to jump in there and morph the customer's project wish list into the actual requirements, you need to be thoughtful about how you proceed.
Here are four steps that you can take to shape the customer's initial requirements into a real solution. You may need to modify the steps based on your customer and what your organization's processes mandate.
1: Hear the customer out
At this stage, you probably don't really know the customer's business yet, so your project team should be all ears. You need to listen to the customer's requirements and his or her wide-eyed ideas of how things are and how things should be. You should also ask questions, but don't be combative or deflate the customer's enthusiasm. It's your job to review the requirements the customer has documented for you and try to get more detail.
2: Meet with SMEs and end users
You should ask the customer to gather subject matter experts (SME) and end users so that you can interview them. After all, you need all sides of the story, right?
Before you show these individuals what you and your customer have compiled so far, find out where things stand from their perspective. Discuss the goals of the project and see if they line up with what the end users really need to do their job well. Then you can bring out what you've documented so far and show them the requirements and the potential solution and get an understanding of the gaps that still remain between what the customer thinks is needed and what the end users really need.
3: Revamp the requirements
Assuming you found more than just a small gap in the initial requirements, you must rework the project schedule, the estimate, the timeframe, and the resource plan. In order to convince the customer that he or she was way off in the original perception of the problem and the solution, you need to make as strong a case as possible (it should include solid numbers and documentation).
4: Break the news
It's time to regroup with your project sponsor or customer project team and present your findings and what you believe to be the real-world vision of the project's schedule and cost. This may be a tough sell, especially if you found a significant gap and the solution will cost five times what the customer was originally expecting.
What to do if the customer sticks to the original specs
In most instances, you can sway the customer to see the right solution for the project, but there is the possibility that the customer won't sign off on your version of the real task at hand and will require you to move forward with the original plans. If the client sticks to their guns and insists on following the initial project wish list, then you have a tough decision to make. Do you go down the customer's path, knowing you may be delivering the wrong solution? Or do you end the project right there because you know you'll never make the customer happy?
I believe that, in most circumstances, ending the relationship at that impasse rather than risking permanent damage to your reputation is usually the best path to take. Also, I think most project managers want to feel good about their work; if you implement a solution that you don't believe in, you're going to have a bad taste in your mouth at the end of that project.
Your reputation is on the line
Regardless of how tempting it might be to take the easy road and just do what the customer wants (especially if you're already juggling six projects), you should never trust a customer's initial requirements. There's almost always more to the problem, and therefore the solution, than originally meets the eye. If you provide a solution purely based on their original request without going deeper, you will likely have a dissatisfied customer and frustrated end users by the end of the project. You might think that if the project goes up in flames, it's the custome's fault because it was his or her wish list, but you'll be the one who is blamed.

Brad Egeland is an IT/Project Management consultant and author with over 24 years of software development and management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT.
Sent by Maxis from my BlackBerry® smartphone
0 comments:
Post a Comment