By: Mia Tsou & Brad Antcliff
This is part 1 of a 2 part series comparing the art & science of business analysis. Most business analysts would probably agree that the work they do is scientific, in that it is systematic and methodical. The art of business analysis is harder to define. Thus, we begin with the science.
Google defines Science as:
“The intellectual and practical activity encompassing the systematic study of the structure and behavior of the physical and natural world through observation and experiment.”
We as BAs naturally have a tendency to observe and thus want to instill change for the better in a project, in a team, or in an individual. We often experiment and try different things. As a result, we have defined procedures, tools, and ways to drive desired outcomes.
Certain processes have emerged or are in development for technical projects after years of trial and error. For instance, using a methodology commonly referred to as “Waterfall,” some companies prefer to define all the requirements for a product/system up front before designing or writing any line of code. This sequential process has its roots in manufacturing and assumes that rigorous analysis in the early stages of a project will save time and effort later in the development cycle. A development methodology is analogous to a “Scientific Theory.” We assume it to be true until it is proved otherwise.
More recently, Agile methodologies have taken a different approach that has many parallels with the Scientific Method. Agile projects follow a similar set of steps as demonstrated in the table below:
In this method, the analyst defines the product requirements as User Stories (essentially bite sized chunks of work) and the team works on the stories in short iterations called “sprints.” Having all phases of the SDLC in the same sprint ensures that development can react to change more efficiently. The moment we validate that a new methodology works, we stick to it and treat it as a “Scientific Theory.”
Because we’ve come to define processes that work, more and more tools have become available which allow project teams to stick to those processes. For Agile Methodologies, many tools like Rally, Mingle, etc. have been developed to streamline the process. Processes that become templatized into tools show that it’s truly become a science as tools are developed once the process has matured. Agile tools incorporate how the team should function throughout the process in addition to capturing requirements (aka User Stories).
With that, there are also tools that were designed specifically around capturing requirements. Thus, we’ve found ways to format how requirements are written with each method and tool.
“The System Shall….
As a User I can [xx] so that [xx]”
The Scientific Method does not define an appropriate level of documentation to call an experiment successful. Similarly, software development methodologies are ambiguous in how much we should use tools to document our requirements and processes. In the science of business analysis, documentation typically exists to allow all members involved with the project to understand what we are building, and for new members to quickly get up to speed by reviewing the functionality implemented so far. Regardless of the level of documentation required for a project or company, documentation can never replace face to face conversations. This may be one of the few areas where software development methodologies differ from scientific methodologies. Another scientist can usually repeat an experiment based on the experiment documentation. In the world of software, this is just not the case.
Business analysis is scientific in that the goals of a BA are to observe and deliver requirements in such a way that assumptions about users can be quickly validated or disproved. The methodologies to get to this point are very similar in structure to that of the scientific method. These methodologies are processes to build software that have been observed, tested, and are now defined for the Business Analysis profession. Scientific Theories created by software analysts. Business analysis is indeed, scientific.
Up next, Part 2: The Art.