Business Analysts are asked to do many things: elicit, document, and manage requirements; facilitate meetings; fit/gap and feasibility studies; act as a bridge or liaison between functional and technical groups. We often look at this mix of activities and think “This is my job”. Through this series of articles, I’m going to talk about the things that a BA needs to do as part of their “Real Job”. Not just the skills and activities we practice on a day to day basis nor the tasks that we are assigned and complete from project to project basis, but the reasons behind those skills and activities; the what and why of delivering value to the business via IT projects.

Charles Kettering said “A problem well stated is a problem half solved” more than half a century ago, and it is still true today. Helping the customer come to an understanding of what they want to do and why is the crucial first step to getting a project going. Without this understanding, the project is off on the wrong foot. Sometimes, though, reaching this understanding is not that easy.

In this article, I address the perception common among BAs that “I [help] solve problems”. While this is partly true, I think that the Real Job of the BA is to help the customer accurately and succinctly define problems (or issues, the preferred term for business-side people).

How many times have you started a project where the customer asks you to implement something, and you realize it is really a solution? Do you forge ahead, holding requirements workshops and putting the documents together?  Or do you stop and ask them why they want the project, only to have them say “Because I said so, that’s why!”?

Be careful. Either approach could get you in trouble, and knowing when and how to do both as appropriate is one of the things that identifies a real BA. Which brings us back to this part of the BA’s “Real  Job”: defining the problem or clarifying the issue.

 Clarifying the issue involves working closely with the customer to understand the rationale for the project and how it fits in to the business. Whatever level you are working at in a given project, from high-level strategy to enhancement of an existing system, help the customer articulate the business value of the project by showing how it will address an issue (solve an existing problem).

There are as many levels of business issues as there are types of requirements, and in fact we can  map them nicely. I’ve created a modified version of the venerable V-diagram to show how business issues map to requirements.

You‘ll notice the two-headed arrows on the slide; this is because requirements don’t exist in a vacuum. In examining a requirement at any level you can turn it on its head and look at what issue that requirement is intended to address. As you dig in, be sure to ask “are we solving the right problem?” This may lead you to uncover issues at other levels; issues that, when addressed, may make the problem you are currently examining simply disappear.

Carefully articulating the issues or problems when documenting requirements can lead to improved

traceability and provide a common language when discussing matters of scope. It can also help with the all-important prioritization of requirements, that often onerous job of separating the ‘must haves’ from the ‘should haves’ and the ‘like to haves’.  Clearly, if a requirement is related to a core problem that the system is intended to address it is a must-have, while those requirements that don’t actually address an issue probably are not.

CONCLUSION: There is little business value in a solution in search of a problem, sometimes known as “build it and they will come”. On the other hand, even an average solution to a problem shared by many people will be embraced and used. Keep in mind that problems and requirements go hand in hand. Make sure that you work with the customer to understand and clarify the right problem, and you’ll be well on your way to doing your “Real Job”.

Don't forget to leave your comments below.

Greg Busby, CBAP(R), provides leadership for  Cornell University's BA practice, which he helped start 5 years ago. With over 25 years experience in IT, including Business Analysis, Product Management, Consulting, and Development. Greg's focus is on establishing and maintaining the partnership between IT and business units to help ensure that technology projects support and further the institutional strategy and goals. His primary areas of interest are enterprise analysis, portfolio planning and analysis, BA/PM teamwork, and professional development of BAs.