Member Services

01 23 777 88

or complete our Contact Form


01 23 777 23

or complete our Contact Form


The challenges facing Business Analysts

1. Misconception of BA’s scope of work

There are differences between Business Analyst’s actual functions and tasks they really should perform. This 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 here:

  • Type: Wireframe
  • Effort: Low
  • Fidelity: Low
  • Goal: Functionality discussion General design solutions discussion General usability solutions discussion
  • Traits: Sketchy, Black & White & Gray representation
  • Type: Mockup
  • Effort: Middle
  • Fidelity: Middle
  • Goal: previous goals + Design discussion Presentation to stakeholders
  • Traits: Static visualization
  • Type: Prototype
  • Effort: High
  • Fidelity: High
  • Goal: previous goals + User testing
  • Traits: Interactive

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 shown, 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 developer.
  • 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.

3. Changing requirements or business needs

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.

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:

Reason 1

Some external organizations require changes in a current business process (for instance, new rules, laws, or instructions are adopted by government).

Possible solution

New requirements have to be accepted while postponing planned project deliverables.

Reason 2

Requirements elicitation problems: requirements were not fully defined, not all the “right” users/stakeholders were involved in an elicitation and approval process.

Possible solution

  • Improvement of the requirements elicitation process.
  • Requirements review by stakeholders.
  • Applying requirements according to a change management process that had to be agreed with stakeholders before a project start.

Reason 3

Customers are not sure what functionality they need (requirements were agreed)

Possible solution

  • Apply incremental development approach to respond promptly to required changes.
  • Include extra time in the project schedule to apply changes.
  • Agree project timeline and discuss possibility:

- to implement reduced project scope because of new/changed requirements;
- to include required changes in the next project stages.

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.

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.

5. Undocumented processes

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.

If you would like to know more about becoming a Business Analyst, please visit here.

Share this article!