Let’s say a client requests an internal cloud infrastructure to handle an application his organization is launching. You can set the client up with a private cloud to run the application on if that’s what he wants. If you do, you can forget about scalability and the savings the client might experience if he were to start off with a public cloud using, say, Amazon’s EC2 cloud offering to launch a product and then help him take it private later once demands levels off to a manageable level.
The better course of action is to solve the actual problem and not just the client’s perception about the immediate need. Therefore, you should never blindly accept a client’s word about the root of the problem and his pre-determined right solution; you need to dig deeper and talk to end users to ensure you uncover the real problem that needs solving. These are the four steps (to varying degrees depending the engagement) that I usually take to determine the client’s actual problem.
1: Document the client’s perceived need
During your initial client meeting and probably during at least one subsequent meeting, you’ll discuss the client’s perceived problem or need. You should take thorough notes, and then turn those notes into a formal document that you can have the client review and sign off on it, if possible. Now you have a document that says to your client, “This is what I heard you tell me about your need, and this is what you agreed to as your need.” Granted, this is still at the high-level requirements stage (it’s more of a draft statement of work), but it will serve to draw a line in the sand on the project.
2: Identify the related core business processes
Now you must do some investigative work about how the perceived need relates to the business processes around it. If the need is for a new accounting system, then you need to understand the business processes in the client’s accounting department and how the accounting department interacts and serves other areas of the organization. The client may think he needs an entirely new accounting system (which would be great for your bottom line), but the real need may just be additional reporting. The solution to the real problem would probably lead to repeat business because you saved the client unnecessary expenses.
3: Investigate how the end users are affected
Once you understand the related core business processes, you must then meet with the end users within the organization (and external to the organization, if applicable and possible). The key here is to get the end users’ perspective on how the current system or process is being used and what needs aren’t being met. This is a great time to get users’ wish list for the system or process because you might be able to address some of their requests now more cheaply than creating a separate project several months or a year down the road.
4: Document the real need and take it to the client
After completing the previous steps, you should have a much better handle on what the client really needs. If the real problem matches what the client originally told you, it’s great; if it doesn’t, then you have some details to work out with the client, especially if the true problem or need will be considerably more expensive to address than the perceived problem or need.
You should set up a meeting and have at least a draft estimate in hand for what you think it’s going to take to solve the need. Be sure to take all of your documentation from steps one, two, and three so that you can show the client the detailed processes you followed to get to this point. You need to be prepared to defend your findings and, ultimately, be ready to walk away from the project if the client is too stubborn to listen to your recommendations. You don’t want to implement a solution the client doesn’t need and then be blamed for it in the end.
Clients sometimes mistakenly focus on the short-term problem, and you must help them see the real issue in order to implement the right solution. By following the steps outlined in this post, you might be able to show clients that their perceived needs were actually symptoms of a larger or perhaps slightly different problem. I like to be optimistic and think clients want a consultant who is an expert and not just “a yes man.”