Why Hire a BA for Your IT project? Part 1

First thing first, who’s a BA?

Let’s learn by example.

Say, you finally set your mind on repairing your leaking roof. It has been bothering you for too long, and you cannot wait to see it new and shiny and perfectly leakproof. So you go to the store to buy the tools and materials you need. Wandering helplessly from isle to isle you realize you know nothing about roof repair!

Next thing you know, you come home and start googling intensely. 

Sleepless nights watching youtube follow. 

Finally, you come to the conclusion you’d better contract someone to do it for you. And here’s where our hero shows up.

No, it’s not an all-smiling construction firm consultant who tells you the team will do the job in the twinkling of an eye. It is that down-to-earth precise guy or a girl who’s been asking too many questions from the very start of the project. Far too many.

Frankly speaking, by day 5 he/she is totally driving you nuts with the incessant flow of emails specifying each and every detail of your future roof.

Long story short, after two weeks of exceptionally unwanted socializing, you come to see the result. And here’s the moment of truth. That very hue of sky blue, that very texture of the metal surface, that very everything. You’re even ashamed a little bit of the hard feelings that would arise each time the Business Analyst tried to connect to you.

So, yes. A BA is a project team member whose mission is to clarify business objectives and system requirements. It is necessary to help the team build exactly what you need so that in the end you’d stand smiling and a bit at a loss “How come it is exactly as I imagined this?”.

For an IT project, the BA’s roles and responsibilities include:

• Studying the business model
• Collecting stakeholders requirements
• Wireframes and prototypes development
• Preparing project documentation.

More specifically, BA’s duties and responsibilities feature

1. Study the market and make a competitive analysis first.
2. A thorough requirement collection process follows with all the stakeholders involved. 
3. Later the BA draws up Vision & Scope, which is a very high-level description of the business objectives, users and stakeholders, system overview and core functionality, benefits and risks, etc.
4. The next step implies developing wireframes or a prototype and presenting it to the investors and clients for approval.
5. As long as the necessary corrections are made, the BA proceeds with the documentation to capture in writing all the wishes of the stakeholders in a clear and concise manner for the developers. The documentation package may include a full set consisting of the BRD (Business Requirement Plan), the FRS (Functional Requirements Specification), the SRS (Software Requirements Specification) or be limited only to SRS.
6. To help the software developers better understand the intended system behavior, BA creates dozens of user stories or use cases (one per feature or covering several features at once).
7. It is important to have all the functionality described in a neat and concise manner in a separate document mapped to the particular test cases. Such a document would allow seeing if all the functionality is covered with tests and if there are any defects left unattended. For this purpose, the BA creates a Traceability Matrix.
8. Along the software development path, changes can be introduced to the system. So the BA’s duty is to capture those changes and properly document them as well.

For a more detailed description of the project documentation that BA gets ready for the client, see this article

Looks like a huge piece of work, doesn’t it? However, a lot of clients believe that BA’s contribution isn’t worth the money. How come? Read on for the answers.

The most common reason is that the clients do not understand the value that a BA brings to the project. 

Oftentimes they see a BA as some extra resource that’ll help the vendor simply charge more for their services. As a rule, this is typical of clients who have little to no experience in software projects. Those with larger experience usually do not hesitate as to whether a BA should or should not join the project team as the value is too obvious to deny.

Nevertheless, suppose you belong to the first group of the BA-value deniers. How can a vendor convince you to add a BA to the team?

Well, they can try to explain to you what the BA’s duties are. Are you in now? Not at all!

After a detailed explanation pretty much every client who wasn’t going to pay for the BA’s services states he/she can do the job themselves!

Thus, a client refuses to hire a BA because of the two major reasons: 

1. They do not understand what a BA does on the project
2. They are sure they can do this chunk of work themselves.

OK, so be it. 

Let’s assume that the client chose to move forward on their own. This would have saved them about 4,500 to 12,000 USD of the 3-months worth of BA work (given the average BA salary is from 1,500 to 4,000 per month in Europe (3,800 USD/month in Spain, 3,300 USD/month in the Czechia, 2,240 USD/month in Poland, and 1 000 USD/month in Ukraine)).

However, a bigger picture shows that while cost saving is important, only reasonable savings bring the desired outcomes. Without a BA, the system may not be up and running as it should by the deadline, and the business objective may never be met.

The good news is that the costs would never exceed the initially specified amount. However, what’s the point of producing the system no one needs with functionality no one uses within the budget?

Let’s get straight to the point right away – is a BA a must?

There’s no project without a BA existing, only there are projects where a BA’s role is performed by someone else. That is, the business analysis will always be part of the project. Sometimes business analysis will be performed by a BA, and sometimes it will be up to someone else to do (which is not a good thing).

However, do you need exactly a BA or another talent who will agree to perform those duties will do just fine?

It depends. If the BA’s duties are performed by a PM or a QA manager and everything goes as planned (business objectives are met, developers know what to do, no issues arise along the project progression), the team can do very well without a BA. 

However, as the project team grows bigger, there will be a more acute need for a BA. Bigger teams mean more communication; more communication means more information should be shared, captured, and documented. Consequently more information can be lost as it often happens if there is no specific talent on the project who’s in charge of capturing it from multiple communication channels.

The bottomline brings us back to the very first stats we mentioned in this article – 70 percent of the IT projects fail. What can be the reasons behind such a drastic failure rate?

Steve Andriole, Professor of Business Technology, states all 6 reasons in his Forbes article. Those can be divided into two groups according to solvable/unsolvable criteria:

“Invest as much as you can in the top three – definition, scope and management – problems because the bottom three are essentially unsolvable” – Andriole sums up.

More specifically, very often companies know or at least can find out 

1. What product/system the market needs (business objective)
2. How to build it (system requirements)
3. How to manage the project growth and development (project management).

The remaining three are lethal all too often because companies ignore or deny them.

Therefore, Andriole recommends focusing at least on the three solvable issues to mitigate execution risks. In other words, to safeguard your project from failure, you’ll need to approach with the utmost attention at least business objectives, business analysis and project management. So, for what it seems, Business Analysis is not a choice. To have a broader picture we recommend reading the full article and have placed the link above.

We’ll be back shortly with the second piece to give you more on BA’s craft. Stay tuned to find about the qualifications that a great BA should possess, see whether a PM can perform the BA’s functions, and most importantly - read how BA can save the day for your project.