Often when I meet with clients to discuss a technology project, either ongoing or new work, we have to discuss a problem (or rather the opportunity to do better) and then we try to come up with an answer or solutions. We brain-storm, discuss, collaborate and sometimes argue to get to something we can both imagine would be the solution.

While this process works well, it really depends on a couple things that are not very dependable.

First, the person leading the conversation, usually me, has to be responsible to discuss both the possibilities and restrictions of the potential solution. Say we’re talking about a new project for a client. The client would suggest how we can do better than what’s currently available and usually there are restrictions (time, budget, resources, etc.). It’s up to me to keep these restrictions in mind, all the while suggesting the solution. It’s sort of an internal tug-of-war. I sort of imagine it as if I were Santa Claus and a tax collector rolled into one. I bring the presents and also take away the fun. As you can imagine, it can be difficult to walk this line.

The second thing that isn’t very dependable is that most of the time the clients don’t have the experience or the creativity to come up with the solution to their problem. They know the have a problem and that they need an answer and a lot of the time they have an idea of how this should be done. But, isn’t it my job to come up with something for them? I work on the Internet and look at dozens or even hundreds of websites each day, and I’m aware of the capabilities of my team, so most of the time a suggestion by me should be a bit more worthwhile to the project. The stuff that I get from clients is often simplistic or not fully formed. Worse, sometimes I get clients that are unwilling to let go of a really bad idea.

So how do we work around these two issues? This is where we look for simplicity.
While we’re in the process of analyzing the project, it’s important to keep asking the simple questions:

• Who is going to benefit from this?
• How is this going to be used? Or, how is this going to work with what people are currently doing?
• How much change will people have to endure if we do this? How much is too much?
• What are the steps of the process?

Notice there are no questions about what the solution will look like or even how it will work. We’re mainly try to figure out why we’re doing things a certain way. If we keep these questions in mind throughout the process, we’ll spend less time straying and spend more time on the project.

Additionally, if we find answers to these, it’s easier to discuss the solution with the rest of my team. It’s easier to say, “make the application do X then Y then Z,” compared to “the application should be better than our competitors and our audience loves the color red.”

So how do we do this? How do we get clients out of the narrow view?

Practice is part of it. Also, I’ve work with many clients and I’ve learned the value of sticking to my questions. Lastly, and this is the secret ingredient, I make it perfectly clear that we want what they want which is a successful project, and we’re working hard to make it happen.