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).
Once refocused and with a clear description of the problem on paper, we started to carve out the solution requirements (the spec). I asked Billy to describe how he would imagine using this tool. I encouraged him to approach it like the proverbial kid in a candy store. If you can have anything you want, what would that be? This is an important step, it allows me to understand what language Billy is comfortable using. I can pick up on key terms and reuse them when speaking with Billy. It gives me some insight into Billy’s understanding of technology and how important he feels this solution really is.
This is where the dialog generally goes in one of two directions:
- 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.
- 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”.
Providing technology solutions is an iterative process. You start by framing the issue or opportunity and putting general ideas on paper. Once both sides are comfortable with the framework, the technologists need to work through the build or buy process. Is there already a technology solution available that addresses these needs? If there is nothing on the market that meets the needs, you will need to proceed with building the solution. The process must include the providers of the solution and the consumers of the solution, not just the original architect and the requester. It must be an iterative process with everybody helping to create the solution.