Should Technology Drive the Solution?
Posted by Brad Egeland
“Oh…pick me, pick me Mr. Kawtter!” (as Horshack would say to Kotter for those of you old enough to remember – see image to the left) I know this one. But wait, new technology is so cool…and so much fun. And often the customer comes to you with the solution in mind that includes this technology. And sometimes he even has the money to back it up. Resist! Resist at all costs!
The answer is a resounding NO. Technology should not drive the solution. Never ever ever. It may be the solution, but there’s work to be done first to get there. Follow the process, push back on the persistent customer who knows exactly what he wants and how he wants it done. Take a deep breath and tell the customer simply …. no.
Why? You would think that a customer who has money, has a need, and knows the solution is an easy customer. All we have to do is do as he says, cash the check, and move on to the next project – everybody’s happy, right? Not always … and not likely.
The problem with this scenario is that the customer often doesn’t really know what they want. What they know is that they have a need. The customer needs help cultivating the information from that need into a solution that will fit or solve that need. That’s where you – and your team – come in. Being a ‘yes’ man for the customer won’t do them any favors and will more often than not leaving them with a final solution that doesn’t meet their needs. If the customer’s end users are frustrated, the customer will be frustrated. And customer frustration = customer dissatisfaction.
In order to best ensure that you’re going to be providing the customer with the actual solution that their need requires, you’ll need to follow a process similar to the following:
Have the customer map out business processes
Mapping out their own business processes is something that is very helpful for the customer to do, but they’ll often overlook this activity unless you specifically require it. It’s really a good idea to require that they go through this activity before you ever even sit down with them. If the customer goes to their end users and subject matter experts (SMEs) and gets business processes mapped out with them, then there’s a real good chance that they’ll have the best possible view of their real need going into requirements definition on their own or with you.
Review or create high-level requirements with the customer
Ideally, the customer would do this on their own, but what’s ideal and what the customer actually does aren’t the same thing. So, assuming that you and your team have to at least ‘help’ the customer map out their high level requirements, at least you’ll have their business processes in place from the previous step to really help you understand what their need is.
Create detailed requirements with the customer
Next, drill down with the customer further into the requirements. It’s best at this time to also categorize and prioritize requirements. You can do on it white boards, on paper, in Visio or Excel, or you can utilize a mind-mapping tool like Seavus’ Dropmind. The key is to capture more requirements detail at this point.
It’s inevitable that there will be three general categories of requirements: must-haves (the #1s), should-haves (the #2s), and nice-to-haves (the #3s). Prioritizing now will help you later if and when scope or schedule changes affect the project and you have to get functionality up and running by a specific date leaving the rest for a later phase of the implementation. Then, you’ll be able to focus on first getting all the #1 requirements met, if necessary, and push 2’s and 3’s to a later phase rather than watch the entire project crash or go over budget and time.
Propose a solution
Unless it’s already obvious, now is the more likely time to actually propose the technology for the solution. Up to this point we’ve been examining the current processes and need and detailing the requirements. Now, based on all of that information we can propose or confirm the right solution to meet those needs. Now is when the real work of utilizing the proposed solution to meet the requirements of the project can start to happen.
Summary
The customer often thinks they know what they want. However, don’t be tricked into going down that path with them. Remember, you have the team of experts that they came to for the solution. You’re the leader – lead them down the path to the right solution. Don’t let the customer dictate the solution to you and your team.
Related posts:
Amir Toister says:
Sometimes, you have a solution to a something that the customer doesn’t even realise that he needs it. There it the Request (what the customer has asked for), the Need (what is needed for a succesful operation) and the most interesting part – the gray area between the two: what the customer thinks he has asked for and what the customer thinks he needs. If you deliver what he’s asked for without answering his real need you get an unsatisfied customer. I totally agree with your analysis.
My boss wouldn’t accept this argumentation claiming that we were paid to deliver the request and don’t have the time and budget for the additional analysis. I told him that it won’t work. When he saw that I was right, he fired me.
Steven Hanks says:
Brad,
I totally agree with you. Customers often just don’t know what they want. Customers are (in most cases) far less experienced in the field that you propose a solution. To sales representatives; If the customer already knew exactly what he wants, he would already have a solution for it. Therefore it’s imperative to conduct a thorough Requirements Research before proposing a solution. On our website I have written a post about it which you can find below:
http://www.iwmsnews.com/2008/10/requirements-research/
Yours Sincerely,
Steven Hanks
IWMSNews.com
Brian Mossing says:
Brad, great overview and, as usual, well written and easy to understand.
I find in the mega-corp in which I work, the process you outline is that much more important but also that much less likely to be done. The general perception (I think) is, “How can one employee [the PM] of Mega-corp, who doesnt’ even work in my area, tell me [the customer] what the solution to my problem should be.” (But bring in an outside consultant and their word is gold.) There’s also the continual time pressure to get projects done, budget pressures to help Mega-corp financial performance, etc.
On the other hand, I suspect at Tiny-corp, that one customer might have a proportionately larger share of the organizastional power and so might be less “susceptible” to a PM’s direction/suggestion.
It’s tough all around to be a PM, I guess. Thanks for another good read.