“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