What is business analysis?
According to BABOK (A Guide to the Business Analysis Body of Knowledge), business analysis is “identifying needs and recommending solutions.” Only in this order – not any other.
Implementation of a solution for business is a process that requires the involvement and competence of many specialists. In the case of both less and more complex projects, it is essential to collect requirements that will make it possible to determine the client’s needs. Similarly, when implementing “projects” in everyday life – for example during the construction of a house – before we make an expensive investment, we consider the location and take into account such factors as preparation of the construction design, the cost of materials, and employment of the construction team. An analyst in an IT project is like an architect in a construction project.
In the case of business analysis, clients often have specific requirements, but there is a need for someone to write them down, verify whether they are feasible (or unfeasible), and then pass them on to the IT team, who will prepare a product for the client in this respect. This is where the business analyst comes in, as such a person is the intermediary between the spheres of business and technology.
The role of a business analyst
A business analyst is a person who should speak both the client’s language and IT language. For many people, an analyst is a “documentation writer.” But is this really the case? Reducing the role of an analyst to attending meetings and writing down the requirements necessary to fill in a document template is an unfair simplification. In fact, it is a person who can not only identify the client’s needs and determine the feasibility of the project, but also adopt a critical approach to the ideas presented.
In today’s rapidly changing world, an analyst often faces the need for remote cooperation with the client. “Remotely” usually means “faster and cheaper.” Regardless of the means of cooperation, the ability to work with a client is the foundation for the profession of analyst.
Can we do without a business analyst? I studied automation engineering and I consider it unlikely that robots will replace us in the near future. Anyway, research shows that programming or testing work is easier to automate than analytical processes. I have also observed projects in which the role of an analyst was entrusted to project managers or developers – unfortunately, the results were far from satisfactory.
The role of an analyst versus the methodology of their work
Communication plays a key role in increasingly popular agile projects. This is precisely defined by the Agile Manifesto, which indicates in its first line: “Individuals and interactions over processes and tools.” This principle can well be applied to the work of a business analyst, in whose work the ability to listen and talk to another individual is essential. If one has not managed to develop their communication skills well, they should rather not consider a career as a business analyst.
In the waterfall model, analysis is the second stage, as without this it is impossible to move on to the next stages of a project. Let’s try to imagine that we start work at the development stage, without having analyzed first what we are to implement, for which group of recipients, and how we plan to do it. Analysis is crucial here.
Regardless of the type of methodology of work adopted, here is what counts in the work of a business analyst:
- asking questions,
- drawing conclusions,
Mistakes in business analysis
Having familiarized ourselves with the purpose of business analysis and the role of the business analyst in the whole process, let’s move on to the seven mortal sins in business analysis. These will not always be mistakes on the part of the analyst, but the analyst should nevertheless always keep their finger on the pulse. What can possibly go wrong in business analysis?
- Wrongly defined business need
What does defining a business need consist of? “My goal as an owner is to earn higher income because I want to buy a car that is more expensive than that of my neighbor.” Does it ring a bell? Yes, it is a user story – a popular “yarn.” Nowadays, user stories are the most popular way of documenting business requirements. In addition, acceptance criteria are also important here, e.g. “My average monthly income has increased by at least 5%.” Acceptance criteria are a list of specific requirements and conditions to be met, so that the Scrum Team knows if the story was executed correctly from a business point of view.
A well-defined business need and its understanding are most important – not only from the analyst’s point of view, but also from the client’s. Whether it is on the business side or on the part of the analyst, the following thought should appear: Why do we do it? What will this give us? Unfortunately, there are situations when a business representative recommends a specific solution because he or she is, for example, the only person who knows a given application. Do they do it for the benefit of the company, or do they just want to keep their job? This is the first, and a seriously grave, sin in business analysis. A good analyst should remain vigilant in such situations and react accordingly.
- Using suboptimal business solutions
I think everyone has heard of technical debt. Technical debt arises when we “cut corners” and reach for suboptimal technical solutions in order to quickly meet business needs. These are solutions that make it difficult or even impossible to achieve future company goals. Technical debt starts accumulating from the very stage of the work done by a business analyst. This leads to a situation where e.g. new investments or improvements of specific processes in an organization are possible only after the backlog has been caught up on, i.e. after clearing the technical debt. And it would seem that this is just an incorrectly written “yarn” in Jira. How to counteract it? It turns out that “cutting corners” does not always mean doing things faster. Just as in real life, sometimes it is better to take a longer but proven route, so that we do not have to take a roundabout way.
- Presenting ready-made solutions
Another common mistake is attributable to the analyst, who – in the heat of collecting business requirements – starts to present ready-made solutions instead of writing down the client’s requirements. The correct process should be conducted in such a way that the analyst collects requirements and consults the business about them. However, at this stage there is often a temptation to propose a ready-made solution – for example, a specific application with specific parameters and functionalities, which seems to meet the client’s expectations. An analyst is only human, and to err is human. However, when collecting requirements, it is worth being critical and not letting yourself go over the top.
- Collection of indiscriminate requirements
Collecting random requirements not only happens to people taking their first steps in business analysis. It is a common mistake, and it is probably due to the desire to collect as many requirements as possible. Overzealousness is not a good method. Neither is the collection of indiscriminate requirements. My goal as an analyst is to collect important requirements. By “important” I mean justified in business terms and achievable. It may well be that business representatives will propose a solution based on an application developed 15 years ago. We like what we are familiar with, but will it also be the best solution for our clients?
An old proverb says that paper bears anything. Maybe it is so; however, it would mean we are but one step away from the erroneous “yarn” in Jira. And so we go back to point 1. Let’s not look only at the contract that binds us – common sense is what counts the most. As everywhere, it is good to aim for the golden mean. Too few requirements can lead to confusion. If, on the other hand, there are too many requirements or they are too precise, the project team will have their hands tied. The developer has to understand what to work on, and the Product Owner has to understand what they have commissioned. A good analyst will know how many requirements are optimal. However, if you do not know what to do, consult both the developer and the Product Owner.
- Misunderstanding the field
As an analyst I have worked on many projects for clients from various industries. I know that it takes time to understand a given client’s field, but it is worth being investigative and asking questions, like a journalist who collects materials. What if the term “explosion-proof housing of mining equipment” is used during a conversation, and you do not know what it is about? Ask! There are no bad questions, and without putting yourself “in your client’s shoes” you may not be able to cope. If you do not speak the client’s language, you will not be able to prepare a field data model that collects the most important terms from a given area of the client’s business (which are relevant to the analyst). This is the basic tool of UML (Unified Modeling Language), that is, the language that documents requirements. A field data model is a model that presents the most important terms in a given area of interest, as well as the dependencies between them. The model allows the analyst to organize as objects all the terms appearing in conversations about future users’ activities.
- No consultation
In most cases, there is just one analyst in the team who collects requirements. Even if the analyst has many years’ worth of project experience, you cannot expect him or her to know everything. It is worth following the principle “If you do not know what to do, ask others for their opinion.” Of course, this principle does not only apply to analysts. Regardless of their experience, competence or role in the team, consulting their ideas or doubts is good practice. Do not be discouraged. Even if you encounter someone who refuses to help you – most people will give you a helping hand.
Honesty is equally important here. Even if you are afraid to admit your shortcomings, your willingness to consult others and your openness in gaining knowledge will work to your advantage and, over time, will help you build the image of an investigative and competent individual.
- No priorities
Each of us is faced with the necessity of setting priorities every day. They allow us to organize our time efficiently. My experience shows that, in the case of business analysis, three levels of priorities are completely sufficient: high, medium and low priority. Tarring everything with the same brush and calling it “release” is usually the result of not being able to decide what is important to us at a given moment. The effect? We do everything and… nothing comes out of it. Maybe it is worth considering pilot projects? Introducing selected functionalities in batches, e.g. just for one branch of a company at a time, will make it possible to test their operation on a smaller group and pick up potential threats before implementation on a large scale.
Business analysis is a process that requires input and knowledge from business and the project team alike. A business analyst acts as an intermediary between these two worlds, which is why he or she should have the ability not only to identify mistakes on the part of the client, but also to eliminate their own faults. Although it is commonly understood that an analyst works with documentation, it is worth remembering that he or she primarily works with people – and that is why their soft skills are so important. Therefore, whether it is during the process of writing documentation or negotiating conditions with the client, the analyst must first of all analyze things. Imitative work that lacks creativity – done without the ability to bridge knowledge gaps and synthesize information – can lead to the mistakes that I described in today’s article. I hope that it will allow both business representatives and business analysts to identify areas for improvement and then turn them into strengths in business analysis.