The customer’s perspective
You know the story – a customer comes to you with a project and they have it all mapped out. They know what they want. They know how they want it. They know the technology they want to utilize for the solution. They may even know how much it’s going to cost and how long it’s going to take.
The project manager’s perspective
Now let’s look at your situation. You’re a busy project manager and your plate is full. You’re juggling six projects already with six different project teams and six different customers. That means you’re already babysitting a lot of people and making a lot of things happen. This new project comes to you with everything planned out in advance by the customer. Talk about easy street. And after all, it is the customer’s money that’s being spent so they must know what they want. Who are you to tell them what they should be spending their money on? And if it all goes up in flames, it’s their fault anyway because this is what they asked for.
STOP! It’s sounds wonderful, but do not go down that road. It’s incredibly tempting to take the easy road and just do what the customer wants. At the end of the day, it’s their request you’re implementing so if things go south, you can blame it all on them. WRONG! When the dust clears at the end of the project and your customer is left with a bunch of frustrated end users because you rolled out a solution that they asked for, but not one they needed, then it will be your head on the chopping block. Remember, it’s always the project manager who has the target on their head. Don’t kid yourself that an unhappy customer will accept the blame. No, it’s your job to look at their issues and ask the right questions to find out what they really need. It’s not your job to just placate the customer.
Here are four steps that the project manager can go through to basically morph the project from the customer’s wish list into a real solution. There are variations to this and what works best may depend on the customer and what your organization’s processes mandate, but to some extent this is basically what needs to happen. It may be easy, but sometimes it isn’t because the customer may have to hear some tough news – like their ‘real’ solution is going to cost five times what they were originally expecting.
Hear the customer out
Obviously, the first thing your project team must do is ride it out with the customer. Sit down and go through the package you’ve been given. Accept their requirements, their wide-eyed ideas of how things are and how things should be, and generally be all ears. Ask questions, but don’t be combative. Don’t deflate the customer’s enthusiasm at this point because they may really know what they need. At this point it’s your job to review the requirements they’ve documented for you and try to get some more detail attached to them. You really don’t know their business yet.
Interview the real users
As the project manager, it’s critical that you’ve built the proper amount of planning time into the schedule. Even if it seems like it’s all planned out and the customer has everything under control, you have to assume that’s not the case. So, now it’s on to the next phase of the planning process. Ask you customer to gather subject matter experts (SMEs) and end users (they may be one in the same) 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 they need to really do their job well. Once you’ve done that, then you can bring out what you’ve documented so far. Show them the requirements, the potential solution, and get an understanding of the ‘gaps’ that still remain between what the customer thinks they need and what their end users really need.
Revamp the quote
Assuming you found more than just a little ‘gap’, you must now go back and rework the project schedule, the estimate, the timeframe, the resource plan …. basically everything. Make it as strong a case as possible because if you’ve found a significant gap, it’s going to take solid numbers and documentation to back it up if you’re going to convince the customer that they were way off in their original perception of the problem and the solution.
Break the news
Now it’s time to regroup with your project sponsor or customer project team. It’s time to present your latest findings to them and go through what you believe to be the ‘real world’ vision of the project schedule and cost. Remember, you can’t toss everything out from your original work. There’s that outside possibility that the customer won’t signoff on your version of the ‘real’ task at hand and will instead require you to move forward with their plans.
If that is the case, then you have a tough decision to make … or your company leadership has a tough decision to make. Do you go down the customer’s path with them knowing you may be delivering the wrong solution and laugh all the way to the bank? Or do you end the project right there knowing you’ll never make them happy? My preference is somewhere in between because I believe that in most cases, with the proper presentation you can sway the customer over to the right solution. But this is not always going to be the case and there are times when you have to cut your loses and say goodbye. Ending the relationship at that impasse rather than risking permanent damage to your reputation is usually the best path to take.
Summary
It’s not always easy to take the steps necessary for the PM and team to get from the initial project request, through to the real problem, define the requirements and provide a satisfying solution to the customer. You want to trust that the customer understands the issues and can figure out what is best for them, but that is not necessarily the case – that’s why they brought in the experts in the first place. You just have to make them realize that sometimes. Just remember that there's almost always more to the underlying issue that necessitated the project than what originally meets the eye. And if all you do is provide a solution to what they originally request without going deeper, you can easily end up with a dissatisfied customer and frustrated end users at the end of the project.
Never forget that when the project gets to the 11th hour and the SMEs or end users are testing it out and are telling their superiors that this solution doesn't do the trick, the customer will come back to the PM looking for blood. It doesn't matter how much they said they knew what they wanted ... the bottom line is the PM didn't deliver and that is what the customer will take away with them.
You know the story – a customer comes to you with a project and they have it all mapped out. They know what they want. They know how they want it. They know the technology they want to utilize for the solution. They may even know how much it’s going to cost and how long it’s going to take.
The project manager’s perspective
Now let’s look at your situation. You’re a busy project manager and your plate is full. You’re juggling six projects already with six different project teams and six different customers. That means you’re already babysitting a lot of people and making a lot of things happen. This new project comes to you with everything planned out in advance by the customer. Talk about easy street. And after all, it is the customer’s money that’s being spent so they must know what they want. Who are you to tell them what they should be spending their money on? And if it all goes up in flames, it’s their fault anyway because this is what they asked for.
STOP! It’s sounds wonderful, but do not go down that road. It’s incredibly tempting to take the easy road and just do what the customer wants. At the end of the day, it’s their request you’re implementing so if things go south, you can blame it all on them. WRONG! When the dust clears at the end of the project and your customer is left with a bunch of frustrated end users because you rolled out a solution that they asked for, but not one they needed, then it will be your head on the chopping block. Remember, it’s always the project manager who has the target on their head. Don’t kid yourself that an unhappy customer will accept the blame. No, it’s your job to look at their issues and ask the right questions to find out what they really need. It’s not your job to just placate the customer.
Here are four steps that the project manager can go through to basically morph the project from the customer’s wish list into a real solution. There are variations to this and what works best may depend on the customer and what your organization’s processes mandate, but to some extent this is basically what needs to happen. It may be easy, but sometimes it isn’t because the customer may have to hear some tough news – like their ‘real’ solution is going to cost five times what they were originally expecting.
Hear the customer out
Obviously, the first thing your project team must do is ride it out with the customer. Sit down and go through the package you’ve been given. Accept their requirements, their wide-eyed ideas of how things are and how things should be, and generally be all ears. Ask questions, but don’t be combative. Don’t deflate the customer’s enthusiasm at this point because they may really know what they need. At this point it’s your job to review the requirements they’ve documented for you and try to get some more detail attached to them. You really don’t know their business yet.
Interview the real users
As the project manager, it’s critical that you’ve built the proper amount of planning time into the schedule. Even if it seems like it’s all planned out and the customer has everything under control, you have to assume that’s not the case. So, now it’s on to the next phase of the planning process. Ask you customer to gather subject matter experts (SMEs) and end users (they may be one in the same) 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 they need to really do their job well. Once you’ve done that, then you can bring out what you’ve documented so far. Show them the requirements, the potential solution, and get an understanding of the ‘gaps’ that still remain between what the customer thinks they need and what their end users really need.
Revamp the quote
Assuming you found more than just a little ‘gap’, you must now go back and rework the project schedule, the estimate, the timeframe, the resource plan …. basically everything. Make it as strong a case as possible because if you’ve found a significant gap, it’s going to take solid numbers and documentation to back it up if you’re going to convince the customer that they were way off in their original perception of the problem and the solution.
Break the news
Now it’s time to regroup with your project sponsor or customer project team. It’s time to present your latest findings to them and go through what you believe to be the ‘real world’ vision of the project schedule and cost. Remember, you can’t toss everything out from your original work. There’s that outside possibility that the customer won’t signoff on your version of the ‘real’ task at hand and will instead require you to move forward with their plans.
If that is the case, then you have a tough decision to make … or your company leadership has a tough decision to make. Do you go down the customer’s path with them knowing you may be delivering the wrong solution and laugh all the way to the bank? Or do you end the project right there knowing you’ll never make them happy? My preference is somewhere in between because I believe that in most cases, with the proper presentation you can sway the customer over to the right solution. But this is not always going to be the case and there are times when you have to cut your loses and say goodbye. Ending the relationship at that impasse rather than risking permanent damage to your reputation is usually the best path to take.
Summary
It’s not always easy to take the steps necessary for the PM and team to get from the initial project request, through to the real problem, define the requirements and provide a satisfying solution to the customer. You want to trust that the customer understands the issues and can figure out what is best for them, but that is not necessarily the case – that’s why they brought in the experts in the first place. You just have to make them realize that sometimes. Just remember that there's almost always more to the underlying issue that necessitated the project than what originally meets the eye. And if all you do is provide a solution to what they originally request without going deeper, you can easily end up with a dissatisfied customer and frustrated end users at the end of the project.
Never forget that when the project gets to the 11th hour and the SMEs or end users are testing it out and are telling their superiors that this solution doesn't do the trick, the customer will come back to the PM looking for blood. It doesn't matter how much they said they knew what they wanted ... the bottom line is the PM didn't deliver and that is what the customer will take away with them.
RSS Feed
