7/27/10

Why do these techies keep asking me about requirements, I just want my problem solved!


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.
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.

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.

Bookmark and Share

2 comments:

Jason said...

Good post. The title reminds me of a meeting I had when I first started in Legal IT, the meeting consisted of a partner repeatedly banging a scrap of paper on the desk whilst shouting at the project manager "why do I need to answer your questions, you've got my requirements here!". Suffice to say the resulting application didn't quite meet his needs!

Chet said...

I once headed off a brewing impass between a team of developers and users by asking everyone to define what they meant by the word "editor." Turned out, everybody meant something slightly different - different enough that it made it impossible to agree on the solution.

I like the perspective offered by your title. All too often we worry about documenting requirements - a concept that non-tech users don't relate to. I believe that starting with "what's your problem and how can I help you solve it" gets you a lot more credibility with the user and a lot more buy-in on the solution you build.

 

© 2014, All Rights Reserved.