Technologists often get approached with opportunities to solve problems using technology. We sit down and talk about the user’s desires. This happened to me last week – Billy called asking for help solving a problem, but once we sat down, Billy said “I read this article about this software product that firm x is using and we should have the software too”. The challenge here is to get the focus back to needs rather than solutions. Without refocusing the discussion, you are going to end up with more shelfware (software that is owned but not used).
- very productive with a lot of dialog and enthusiasm
- Billy simply grows quiet and makes a statement like, “just give me something to play with”. Billy has disconnected and doesn’t feel I have an ability to understand his needs.
Here are a few suggestions to help prevent the disconnect:
- Speak a Common Language – Often times technologists speak one language while the user speaks another. This leads to communication breakdown and the user tends to disengage, feeling that the technologist just doesn’t get it. Technologists need to learn the business and speak the business language. This will serve the technologist well, giving him or her more credibility with the user.
- Lose Assumptions – Just because I understand what you mean by x, y and z, you should not assume I also understand a, b and c. We need to spend the time to really understand the entire process. Without such understanding, we are going to have a partial solution at best, and often times, what gets delivered is far from what the user imagined.
- Set Expectations – Most people have never worked on providing a technology solution; they have no idea of how long it takes to build, test, fix, re-test, fix and deploy. It is important for the technologist to provide a good ‘guestimate’ of the time needed. This is essential for setting expectations. Without this, the user is going to expect the solution in a unrealistic period of time. I cannot tell you how many times I have heard “Heck, my son can build a website in an afternoon”.
Solving technology problems is much like purchasing a house. Is there a solution on the market that meets your needs? This approach is like buying a house that is already built. Depending on budget, you can get a house that meets your needs, but you will not have the flexibility to make the house exactly as you imagined. For many this is great, the builder has already answered all those pesky questions. If there is no solution currently available, then you need to build the house. You will start with an architect and he or she will ask a bunch of questions. How many bathrooms, how many bedrooms, three car garage, one story or two? You get the point. This process takes much longer than buying something already built, but you will get, budget willing, exactly what you want. During those initial meetings the architect will not ask you what types of countertops you want in the kitchen and bathrooms, those types of questions come later. The first thing is to agree on the basics of the house (the framework). Likewise, with technology you need to start with the basic framework. All too often the user is more interested in the placement of buttons or colors of the background than in discussing the problem. That is like selecting countertops before discussing floor plans.