Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value.
Business Analysis Book of Knowledge (v3)
Note that this definition does not ascribe the responsibility of performing business analysis tasks to a specific stakeholder in a project. In fact, the same standard states that a business analyst is anyone who performs those tasks, not necessarily a person who has the job title or role “business analyst”. This is why you will read about “business analysis as a mindset” not as as a project role [1]. In reality, the business analysis field gains its vitality from the broad range of skills and backgrounds of professionals from many different fields, technical or otherwise.
Naturally you may ask why then do we need the business analyst role in projects, since not only anyone can perform those tasks but they rightly should be expected to do so. You will understand the answer to this while you read my answer to the heading question as well.
To fully understand this article you need to keep in mind the definition of “stakeholder”. A stakeholder is anyone who as a stake or an interest in a change initiative, that is, someone who is or will be affected by the outcome of the project, directly or indirectly. This includes those who pay for a product or for its development, those who use it, those who build it, and even regulatory bodies who may not even know about the existance of the initiative (until they are required to perform their role). When I started my career (not that long ago) I often heard managers use this definition incorrectly. For them the most important people were those paying, but that is not what defines a stakeholder. End users couldn’t care less about who payed the developers to build the product they use.
As a side note, poor management (and poorly skilled managers) is one of the biggest roadblocks to busyness analysis and its role in achieveng meaningful change, but I will delve into this deeper in other posts.
Now lets answer the heading question starting with an analysis on the definition above.
Enabling change
If we accept as given that organizations need to change in time, then our focus will be in understanding how to enable change.
Now if we accept that a single individual in a organization cannot alone accomplish change, which will be a logical necessity because 1) an organization is comprised of many inter-related individuals and 2) each individual has a particular set of interests or stakes in a given project, then we need to accept that either 1) many individuals will be able to concile their approaches into a single best common strategy or 2) a few indivuals will need to focus on this task alone.
Defining needs
Who is to be responsible for needs definition? Can the party who has the primary driver to satisfy the needs define them alone? As explained before, this may be straightforward in small simple projects or organizations, but not much so otherwise.
And how should that be done? Again, should a single party set the standard of operations? How effectively will a business manager be able to explain his needs to a developer or an end user? Do the work methods of a Director make it easy for a client using the solution to understand if their needs match?
Clearly, there is a need to 1) adopt a common standard in the organization for identifying needs and to 2) devise a way to make it clear if the understanding about the needs agrees between all the stakeholders in the initiative, and finally to 3) reach alignment about the needs the project should address between all parties involved, from business to developers and end users.
I once was in a project that was peculiar in several regards, one of them in that there as an elicitation made (by me) at the same time the developers team was building the solution, that is, they were with me in the same requirements meetings and after each they would turn their understanding into SW while I was updating the elicitation and making the actual analysis work. This was a very good experience in that it allowed to test the subject of this article — did the developers really need a formal elicitation analysis to deliver? The results couldn’t be more clear:
- after the 7th delivery of the team they were still grasping the basic understanding of the overall scope they were working in for several months
- core functional concepts were not properly understood
- not a single of their deliveries passed enough quality criteria to even finish the quality assessments
- each developer had his own understanding of the meetings despite the frequent live interactions with the client and his availability
- they did not verbalize many of their doubts and when they did (often after wasting working hours), I showed them that the answer was already clear in the elicitation I was making even before it was finished
- the client would sometimes contradict himself or leave ambiguity which made things even worse for them (frequent and frustrating rework)
It was months of work of several developers wasted in reaching no specific end goal besides a generalist and poorly functional prototype. The initial assumption, proven wrong in the worst possible way, was that everyone would get the same picture of the needs and in the quality assessment stage only minor deviations would need to be corrected. Does this sound convincing to you?
Recommending solutions
Is a business manager likely to recommend the same approach to addresss a need as that of a computer engineer? Are even technology specialists always on the same page regarding the same problem?
It is obvious that decisions will have to be made by the accountable parties, and sound decision making relies on sound data to support it. This is where business analysis tasks add value to projects. A business analyst (unlike a functional analyst) will many times not have the business or industry expertise required to fullfill this task alone, but it is up to him to reach for the subject matter experts to provide those essential inputs.
I once was in a project with a large team. I got to know about a technical problem the implementation team was facing that was blocking them from being able to reproduce a highly integrated workflow end-to-end, without being stuck in the middle waiting for a reply from an external system. I made an assessment to it and I concluded that we might be able to solve the problem by understanding a feature that that external entity was using for communicating with our system, which as an adaptation of a standard.
When I told a senior SW engineer about this, he promptly replied “we have no budget for that”, even before I laid out my arguments. Clearly he did not understand my position and he had many other (for him more important) things to worry about than my analysis. Faced with this reaction and because of the impact of the problem, I decided to try to solve it myself. I succeeded and soon after the whole project was benefitting from it in hours of work, in complexity of work, in quality of delivery.
Although I as an analyst was not expected to actually build a solution, my point here is that it was essential to have a person in the project who was not being subjected to delivery or management pressure and to be able to clearly and unbiasedly assess a problem and devise a solution. If you are going to make decisions, base your approach on anything better than your casual-under-pressure gut instinct. If you cannot do so on your own, then ask an analyst to help you.
Delivering value to stakeholders
How do you get a dozen or more people agree on the definition of value and on how to deliver it? Do you believe “value” derives univocally from a stakeholder’s need? If that is so, then is the financial value for the Finance Department the same and aligned with, the business value of the Administration Board or with the value of using a solution by the cients?
Clearly there is the need to follow a process to assess the multivaried dimensions of the value that the initiative may bring and to concile those dimensions.
That is a great part of what the business analysis processes are devised for.
A rationale for the change
Can you justify a thousand dollars initiative with a wish from a client, a need from a specific stakeholder, or a management doctrine? If so, then you do not need business analysis.
If you cannot, which will be very likely in not-so-simple change initiatives, then you will need to be able in the end of analysis and prior to implementation, to explain in clear terms why the change has been accepted and why it is being carried out as a initiative with the involvement of many different stakeholders.
Conclusion
By now you should be convinced of the advantages of a business analysis approach.
As a final takeaway, I want you to take the opportunity to realize the implications of all this for the profile of a business analyst.
Do you believe that a person who helps identify needs, understands needs, promotes alignment, assesses value, recommends solutions, has a narrow or highly specialized training or expertise?
Its the precise opposite. The business analyst, if there is one, should be a generalist.
Industry expertise will always be a plus, if managed adequately and this is what is not always granted. On the other hand, a narrow expertise will surely hinder the capability to delier value to the initiative.
I often had to face skepticism from highly specialized SW engineers, until the moment when I told them how to apply mathematics to a problem (or how they were doing it the wrong way) or when I pulled my sleeves back and coded a C# snippet to correctly parse a numerical string value according to regional (locale) settings. I had skeptics from business because I was new to the industry while they were specialized in it, until I gathered their inputs with others and presented them findings which they not only had to accept as correct but that actually brought value to them in the form of new insights or easier approaches to obtain the needed insights.
In this regard, it is important to understand that the industrial education we have today, namely higher education, while it can excel in supplying specialized workers for our industries, is very poor in delivering the broad range of skills an analyst needs.
The implication of this is that 1) experience is more effective in building an analyst profile than formal education and 2) there needs to be an active search for improvement and autonomy of learning from a prospective analyst.
One of the reasons why I love this job is that I can work in completely different areas or industries, which allows me to learn a lot during my working life. This is because an analyst is to master not a specific industry knowledge but a set of skills and tools that allow him to work with industry experts in any field.
I recently learned about the concept of Exformation developed by Francis Laleman [2] and I found it so important that I want to use it to close this article. Exformation is about the (ever shifting) structure underlying knowledge, not about knowledge itself, and that is why it is universally applicable especially in Education (learning & training, which Laleman can show you about in his workshops). Well, because an analyst cannot base his approach on the “knows” given alone (which will often be incomplete and contradict themselves), that is, he also needs to discover new “knows”, he needs a (flexible) structure no less than he needs the actual information — this is where exformative approaches add value tho this business.
____________
[1] Yulia Kosarenko has relevant pedagogical work about this subject and BA in general.
[2] You can learn about Francis and his work at Beyond Borders. If you connect with him on LinkedIn you will benefit much from his insights on a variety of subjects.
Compliments of the Author 