Meeting business analyst

IT-projects may vary in resources, time frames, goals and content. But there is one risk they all share – if the developed solution doesn’t answer the customer’s business needs, the project is doomed. This is where a Business Analyst (BA) steps in. Using various techniques and tools, a Business Analyst describes business needs in the language understandable both for Business and for Development.

In the article you will find information about the role of business analysis in a project and typical challenges that Business Analysts encounter.

Business analysis in a project

As the Customers don’t fully understand the role that business analysis plays in a project, they sometimes underestimate the importance of having a BA on the software development team.

There is a common misconception that a Business Analyst is exclusively a document writer. In fact, this person should be a “handyman”. 

A significant part of BA time and effort is occupied with such activities as understanding the Customer’s business, gathering and clarifying requirements. Building trust relationship with stakeholders and identifying Customers’ needs takes a lot of BA’s time. Writing the supporting documentation is only a fraction of BA’s job that is the most visible to those, not involved in the project, but this is just a tip of the iceberg.

Thereby, a Business Analyst acts as a bridge between business representatives, who need to solve business issues and developers, who should understand these needs to tailor a solution for business.

Typical challenges that business analysts face 

1. Misconception of BA’s scope of work

Difference between Business Analyst’s actual functions and those they really should perform happens very often. It is typical for projects with Customers who haven’t had the experience with development projects. 

Possible solution
Before a project starts, it is necessary to agree with a Customer BA’s responsibilities and expected deliverables. BA should make sure that a Customer understands the meaning of all terms (wireframe, SRS, V&S document etc.). For example, Customers often cannot tell the difference between a wireframe, a mock-up and a prototype. For many people these words are synonyms. The difference is highlighted in the chart below.

In addition, Customers often think that wireframe/mock-up/prototype are terms equal to design and, therefore, require applying of styles, formatting, margins etc. which goes beyond BA’s responsibilities.

As we can see, approval of expected deliverables and their content is vital for both BA and Customers.

2. Created specifications do not satisfy the needs of the development team

The pitfalls can be the following:

• Requirements are vague and ambiguous.
• BA does not understand the level of requirements’ description needed for developers
• Inadequate time is allotted for eliciting requirements and compiling the document.

Possible solution

• Discuss and define with a project team and a Customer the necessary level of requirements’ description.
• Create and apply “Requirement Checklist” that helps determine whether the requirements are complete, accurate, verifiable and consistent.
• Use modelling techniques to identify the lacking information and add needed details.
• Reveal high level requirements first, then start on detailed requirements
• Requirements review by software test engineer at early stages. Testers check requirements for some quality issues and verifiability.
• Requirements review by developers. 

Every Business Analyst is familiar with a situation when stakeholders change their requirements. It may happen several times a week or even a day. The main dilemma for BA is whether to apply changes or ignore them.

3. Changing requirements or business needs

Possible solution

First and foremost, a BA should understand the reason for such changes. Below you can find the most popular causes and possible solutions:

 

4. Conflicts with stakeholders

The conflict between Business Analysts and stakeholders may happen when a team proposes a new approach relevant to the current business process.

Possible solution: First of all, the team needs to understand the reason for the resistance to the new solution.

There are two possible resistance scenarios:

• BA missed some critical features or didn’t take some important needs or requirements into consideration. 
• Users don’t want to change their working process and study new solutions and features.

5. Undocumented processes

In the first case the next step is evident – BA should study the process and requirements again to prepare an appropriate solution. In the second case BA should prepare a business case document for users and present it, describing the new solution and answering users’ questions. The document should contain enough details to prove the approach proposed by a decision maker.

BA is familiar with the lack of documentation on the project or poorly documented procedures and processes. At first sight it seems that every user performs their work in the same way, but when more and more details are clarified the actual process stages may vary from one user to another. So, requirements from different sources clash between each other.

Possible solution: To resolve a conflict, BA should identify the main system users and decision makers. After that a document with the description is created to show the differences in processes for users with different roles. This document should be presented to the stakeholders in order to define if described processes are suitable for the solution. BA has to focus on business needs rather than on user positions.

The list of challenges can be prolonged, but the above presented challenges  are the ones that Business Analysts most frequently face.