As SQL Server consultants, we’re always working with customer requirements and tackling diverse database needs, from the mundane to the critical. Clients turn to us for various reasons—maybe they don’t have the personnel, maybe the challenge is beyond their skill—but regardless of the circumstance, without question we have more SQL Server knowledge than they do.
That probably doesn’t read very well, and it’s not meant as a knock on our clients. But, if it weren’t true, they wouldn’t hire us, right?
Back to working with customer requirements. I recently blogged about times when too much knowledge could impede problem solving. This sparked further internal discussions about potentially uncomfortable situations where the customer provide solutions, especially when the problem is ill-defined. (This is a plate of spaghetti…let’s see if it will stick to the wall). This invariably leads to lots of wheel spinning. Here’s a comical look at how this might go.
In contrast, when the client provides accurate business requirements, we can get right down to brass tacks.
Acting like a Consultant
This is where soft skills are so important. You clearly don’t want to alienate or offend a client. And, after all, you’re working with their data and their systems. On the other hand, if they could have solved it, they wouldn’t have called you. The challenge of the client presenting consultants—a team of experts—with a solution to an urgent problem is that the identified problem may very well not be the root cause of the issue and even if it is, the proposed solutions may not be the best way to solve the problem.
So how do we, at SSG, handle “solutions” that are brought to us when a customer has an urgent crisis or emergency? First, we hope that our customers realize that SQL Server is what we do day in and day out. That, collectively, there is more than 75 years of SQL Server experience at SSG. We’ve seen it all and done it all, which is why our clients trust us to fix their problems.
Secondly, we take the time to talk to our customers and listen to their experiences so we can get to the highly useful accurate business requirements. What problem do they perceive, and what are the symptoms? What is the pain that motivated them to seek out a team with more knowledge and experience with SQL? Did they develop a solution?
When a customer comes to us with a requirement for solving a problem, we have to step back and evaluate if the customer even wants us to make sure they have identified the real problem. Sometimes, customers really do just want us to quickly throw together their solution and worry about the next problem later. Honestly, we do that sometimes. We let customers know that there may be a bigger issue, that there may be other things that arise later. Or, that ultimately down the road they will run into more problems. If that is the path they choose, that’s OK as well.
Getting to the Solution
Well I tell them there’s no problems…only solutions.
— John Lennon
Ultimately, if you want to get your problem solved quickly, correctly, and efficiently, you don’t need to spend a ton of time creating a list of requirements. Bring us the problem, and let us work with you as we make sure the real problem has been identified and then develop a robust solution. In this sense, it doesn’t really matter if the customer is always right. It only matters if we can come to grips with the problem and find the appropriate solution in short order.
We’ll come back to this issue again in the near future to address proper collection of requirements.
