On a regular basis around HMS we get specifications from clients of what they’d like to have our TimeControl timesheet do for them. It’s a necessary part of the evaluation process for a client to find the right type of timesheet for their particular business challenge.
The problem is that the language that the specifications are put in are rarely those of business. Most often the specifications are made in terms of features as in “the timesheet screen should have a button that when pressed, does this”. In the context of a solution provider, it is as though the client is writing their description of the solution without identifying the problem.
This has been a challenge even internally when clients try to explain to their own IT department what they need developed for them. Instead of identifying the business challenge that they are facing, they leap forward to try to describe what the solution the IT department should write. The newly popular role of Business Analyst was supposed to fix that. BA’s (I know, I know, everything important is always referred to by its acronym!) were expected to interpret the requests of the client and articulate them to the IT department in more technical terms. BAs were expected to the Tower of Babel that instantly interpreted client-speak and turned it into programmer-speak and vice-versa.
But BAs have had challenges too. They too often arrived after the process of making a request to IT has already been underway for some time. The “solution” is already being drawn up and the technical staff including the Business Analyst are then enticed down a path of speaking of the project in terms of what features the client has invented.
If we look to the International Institute of Business Analysis (IIBA), they define a Business Analyst as “a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.”(1)
And, where do these features of the client come from? Often enough, from existing software or systems they are already using. Perhaps it’s an old legacy system which is being retired or perhaps it is something they use in their personal life and they’d like that feature to come into their business application. Very rarely, is the feature the result of thinking of the business challenge facing the organization which evolves into a technical request.
In our world here at HMS we get that too. A spreadsheet arrives with 250 characters of text describing each “requirement”. The reason for the feature is almost never apparent. Often there are feature requests which contradict each other which indicates that more than one person has put their demands into the list.
Wouldn’t it be easier if instead of describing features, the client described their business problem? Solution providers like us and IT departments who need to deliver a solution could then consider many possible solutions. A Business Analyst who started in on the project at this point instead of much later in the proces would be able to consider changing a process instead of writing some software. Perhaps there’s an online service that would help or some training that would fix an underlying problem.
Bringing Business Analyst thinking early into the specification process is almost always going to result in stronger answers to business questions. Whether you have an official BA role or not, think about the business challenge and getting that articulated before you jump ahead to how you’d solve it.
