The Lexicon of Solutions

My contention that a business analyst produces a solution in the form of a set of requirements or product backlog or user stories has met with some resistance. Not with the concept, but with the word. I’ve even taken to labeling any description of what needs to be done – business requirements document, set of use cases., desk of user stories, items on a product backlog, etc., a “solution document” as a catch-all phrase to suggest that all forms of rendering produce the same results.  Apparently many feel that there is only one solution and that is the implemented software delivered into production, and any suggestion that a business analyst might be creating a “solution” will be met with rancor and ridicule from the technical forces that produce the implemented solution.

Having been there (on both sides) I agree that stepping across that technical boundary is risky for a business analyst.  That boundary exists at the meeting of the What Domain and the How Domain.  Business analysts, even though a great many of them come from the ranks of system analysts and other technical roles, are not supposed to know or care how the solution is implemented. And, again, I agree with that.  Worrying about the technical implementation tends to skew a valid business solution in the wrong way.

However, back to the word.  Does the business analyst produce a solution?  Well, let’s look at the definition: “The act of solving a problem or question”.  Certainly a business analyst solves the business problem presented; however, there is still the question of whether a document is a solution.  So how about another two definitions: “a particular instance or method of solving”, or “a specific answer or way of answer a problem”. The business analyst does produce a solution according to either definition.   So while choice of word might be correct, there is the issue of conflict with the solution team who may claim sole possession of the solution.

The word is not important. What is important is the concept that the business analyst delivers a whole response to the business problem. I believe that all sides of the discussion agree that the business analyst must define the real problem and make sure that everyone is in agreement with the problem statement.  This is not always done and many times when the business analyst does define the problem, the results are set aside as part of some early document like a business case or project charter and assumed to have existed solely to get the project going. After that the only thing that matters is the requirements. And this is where the trouble starts.

Many times the business analyst does a fine job of eliciting the needs, wants, and BS (Blue Sky) from the customers, users, and other stakeholders. The business analyst concocts a fine list of these requirements, perhaps even prioritized.  The list is confirmed and verified by the stakeholders and passed on to the solution team. Only when the solution is near implementation, or even after implementation, is there a concern with whether all the actionable elements of the list add up to a valid, complete, accurate and usable solution to the stated problem.

I’m suggesting that there is a word, perhaps other than “solution” that will remind the business analyst that their goal is to solve the business problem, and the requirements documents the solution as much as an architect’s models and renderings document the architect’s solution to a home owner’s desires.

I considered “diagnosis”, which I mention in an earlier blog posting on BA Times, since the definition of diagnosis is “a determining or analysis of the cause or nature of a problem or situation”, or “an answer or solution to a problematic situation”.  While the definitions fit, the common interpretation of “diagnosis” is associated with medical procedures so it doesn’t extend very well to business problems.

Another possible metaphor for the requirements that I’ve heard is blueprint.  In addition to its definition as a mechanical drawing device the definition of blueprint also is “an original plan or prototype that influences subsequent design or practice”. Again the definition fits what we business analysts are trying to do, but the inference drawn from the word is much more technical than may be acceptable, especially to the solution team.

So, if we are going to have a problem with the word solution, then what word can we use to more accurately describe what it is that a business analyst produces, if not a business solution to the business problem?  Any ideas?

Don’t forget to leave your comments below.