I originally published this article on the PM Tips website. You can view the original article here.
I think I’ve touched on this before, but it is a topic that deserves more mention. If you follow a traditional project management process, then you expect that the customer comes into an engagement with some requirements in place, correct? And we assume that the customer basically knows what they want. In reality, we need to be very careful what we assume. In fact, it’s better to assume nothing…because at the end of the day if it’s wrong, it will come back to the Project Manager.
Moving Forward
Back to the original process discussion. We have those initial customer requirements in hand. We take those requirements – we assume they are correct – and we meet with the customer to build on them. We come out of what I like to call the Exploration phase with detailed requirements nailed down – or so we think. At the completion of the Exploration phase we have a Business Requirements Document (BRD) signed, sealed and delivered to the customer and another milestone checked off.
We then move on to Design and Development, all the while designing and writing code to match the requirements – and modifying as the requirements change and they ALWAYS change. We Test, we Train, we Deploy.….we smile about a job well done and we turn the system on and hand it to the end user and they’re happy, right? Well…not always. How is that possible? We built to the requirements, we worked with the customer project team every step of the way. We delivered what they documented they wanted.
What vs. Why
Here’s the problem. We did a lot of asking the customer ‘what’ they wanted, but we may have never asked the customer ‘why’ they wanted it. Remember, we’re the experts, we’re the consultants, we’re the professionals who have designed and developed and implemented this software solution in some form or another over and over again. We’ve seen it implemented in many industries across the country. The customer, on the other hand, only knows their business…their own business process. When it’s said that way it’s easy to understand how they could have blinders on, isn’t it? Likewise, it’s easy to understand, from our own business and project experiences how you can go down a path for a while and if you go down it long enough you think that is the only way you can or should go. Again, you have blinders on.
We’re the pros – it’s our responsibility to take the blinders off the customer. We need to ask the tough questions.That starts by taking the time up front to understand the customer’s business, their business processes that they’ve mapped out and to understand how those mapped out business processes and the few high-level requirements that they entered the engagement with match up with the solution we can offer them.
A deep analysis with the customer on the ‘why’ instead of the ‘what’ can have a negative result that we have to be prepared for. It can lead to the customer skipping the engagement altogether if they realize this isn’t the right solution for them. If that happens, it happens. But it’s more likely that the analysis can be geared to an even better – and possibly more profitable for us – solution for the customer that provides them with even greater satisfaction and usability at the end of the engagement.
Summary
Don’t assume your customer knows exactly what they want. They rarely know exactly what they want and sometimes they’ll even tell you “here are my processes – tell me what I need.” I’ve had that happen many times – it’s a great way to start an engagement, a nice way to increase revenue, and immediate opportunity to gain customer faith, confidence and satisfaction. It just requires and understanding that the initial project plan likely needs to be extended and the budget for the project may need to grow to accommodate the additional consulting and analysis required.
But even if they don’t ask that of you, you still need to be prepared – always – to ask ‘why.’ If they know why, then that’s half the battle. But likely your questions will intrigue them and you’ll gain some new perspectives, better project information and start the engagement off on the right foot by heading down the path that best serves the customer in the long run.
I think I’ve touched on this before, but it is a topic that deserves more mention. If you follow a traditional project management process, then you expect that the customer comes into an engagement with some requirements in place, correct? And we assume that the customer basically knows what they want. In reality, we need to be very careful what we assume. In fact, it’s better to assume nothing…because at the end of the day if it’s wrong, it will come back to the Project Manager.
Moving Forward
Back to the original process discussion. We have those initial customer requirements in hand. We take those requirements – we assume they are correct – and we meet with the customer to build on them. We come out of what I like to call the Exploration phase with detailed requirements nailed down – or so we think. At the completion of the Exploration phase we have a Business Requirements Document (BRD) signed, sealed and delivered to the customer and another milestone checked off.
We then move on to Design and Development, all the while designing and writing code to match the requirements – and modifying as the requirements change and they ALWAYS change. We Test, we Train, we Deploy.….we smile about a job well done and we turn the system on and hand it to the end user and they’re happy, right? Well…not always. How is that possible? We built to the requirements, we worked with the customer project team every step of the way. We delivered what they documented they wanted.
What vs. Why
Here’s the problem. We did a lot of asking the customer ‘what’ they wanted, but we may have never asked the customer ‘why’ they wanted it. Remember, we’re the experts, we’re the consultants, we’re the professionals who have designed and developed and implemented this software solution in some form or another over and over again. We’ve seen it implemented in many industries across the country. The customer, on the other hand, only knows their business…their own business process. When it’s said that way it’s easy to understand how they could have blinders on, isn’t it? Likewise, it’s easy to understand, from our own business and project experiences how you can go down a path for a while and if you go down it long enough you think that is the only way you can or should go. Again, you have blinders on.
We’re the pros – it’s our responsibility to take the blinders off the customer. We need to ask the tough questions.That starts by taking the time up front to understand the customer’s business, their business processes that they’ve mapped out and to understand how those mapped out business processes and the few high-level requirements that they entered the engagement with match up with the solution we can offer them.
A deep analysis with the customer on the ‘why’ instead of the ‘what’ can have a negative result that we have to be prepared for. It can lead to the customer skipping the engagement altogether if they realize this isn’t the right solution for them. If that happens, it happens. But it’s more likely that the analysis can be geared to an even better – and possibly more profitable for us – solution for the customer that provides them with even greater satisfaction and usability at the end of the engagement.
Summary
Don’t assume your customer knows exactly what they want. They rarely know exactly what they want and sometimes they’ll even tell you “here are my processes – tell me what I need.” I’ve had that happen many times – it’s a great way to start an engagement, a nice way to increase revenue, and immediate opportunity to gain customer faith, confidence and satisfaction. It just requires and understanding that the initial project plan likely needs to be extended and the budget for the project may need to grow to accommodate the additional consulting and analysis required.
But even if they don’t ask that of you, you still need to be prepared – always – to ask ‘why.’ If they know why, then that’s half the battle. But likely your questions will intrigue them and you’ll gain some new perspectives, better project information and start the engagement off on the right foot by heading down the path that best serves the customer in the long run.
RSS Feed
