Wednesday, 10 August 2016 04:21

5 Signs You Need a Different Business Analyst on the Project

Written by
Rate this item
(5 votes)

A great business analyst can really make the technical project very successful.

I've had the pleasure of working with some very good business analysts along the way, and my project successes have been frequent as a result. Having very competent business analysts to work with has allowed me to focus more on my critical project management tasks and to be more successful and client-focused as a result.

Related Article: 5 Things a Business Analyst Wish Their Project Manager Knew

That said, there can be times when the project seems to be suffering at the hands of a less-than-productive or competent business analyst. It hasn't happened to me, but I can look back and see times where my projects would have suffered had any of these come to light...and I've seen colleagues' projects suffer in some of these areas. Here are six signs that the project business analyst likely needs to be replaced – no matter where you are in the project timeline.

1. Can't get requirements finalized.

Not all projects have the luxury of having a project manager and a business analyst; I realize that. But when they are separate positions, the business analyst is going to be the go-to tech liaison. If requirements aren't well defined, as a task, responsibility and accountability for that is going to fall more on the shoulders of the business analyst. And if they aren't working well with the project manager, project tech team and project customer to get those detailed requirements figured out and well documented, then that business analyst likely needs to be replaced before it's too late.

2. Selection of the right technical solution is not happening.

The business analyst – after working with the project manager and project customer to define customer business processes in the “as-is” state of affairs and discussing what the “to-be” environment and processes need to look like – should be the lead on determining the technical solution. Along with help from the project manager, tech lead, and customer, the business analyst will likely be the one taking charge in determining the necessary technology to get the project to where it needs to be. If that isn't happening, if the business analyst can't make that happen, then they likely aren't technically competent to work on this project. They need to be replaced at this early juncture before the project falls into a deeper technical state of trouble.

3. Tech team discord.

This is ultimately the project manager's responsibility, but if there is a dedicated business analyst on the project, then he is likely the one working with and interacting with the tech team the most while the project manager focuses on the status and organizational aspects of the project. If the technical project team is not working well as a unit, then the business analyst needs to be aware and make or suggest adjustments, have team discussions, etc. If they work closely with the tech team, and that is the overall expectation and it isn't happening, and there is discord among the team, then some of the tech team may need to be replaced. But, likely, the business analyst may need to go as well.

4. Tech document deliverables are not acceptable.

The project manager is ultimately responsible for every project deliverable that goes to the customer. I believe in having everything that goes out go through a peer review process. You can't always guarantee 100% error-free deliverables, but if everyone on the team is reviewing everything that goes out, then that makes them accountable, too. With that many eyes making sure everything is in place, the chance that you're sending out a bad deliverable is exponentially decreased.

I haven't sent out a bad project deliverable in almost 9 years as a result of project team peer reviews on all deliverables. On a tech project, the business analyst is usually working extremely closely with the tech team to produce the project deliverable documents. If the functional design document or the technical design document or any similar documents are going to the customer with errors, then it may be time to replace the business analyst. You don't get many second chances on customer satisfaction.

5. User acceptance testing goes poorly.

Often on a technical project, the tech lead will play a big role in user acceptance testing (UAT). I think we all know that on a technical project, user acceptance testing better go well, or there are going to be some big issues and problems with customer confidence, frustration, and satisfaction levels.

That critical UAT sign off is really the last significant approval point before the project goes live. If UAT doesn't go well, then the project will likely experience delays, the budget will take a hit and – even if the project has been going well to this UAT point – it will still likely turn into a failure as it limps toward go-live after the poor UAT experience.

The business analyst plays a big role in holding the client's hand through UAT preparation and the actual testing process. It needs to go well. If it doesn't, you may need a new business analyst but it is likely going to be too late to replace them and find a new one. If any signs point to a less than well-prepared for UAT experience, then action may need to be taken BEFORE UAT. Not after.

Summary / call for input

Certainly overall responsibility for failure at any point in the project lies with the project manager. It is up to the PM to ensure that everyone fits well into the project team and to take action if that is not the case. But accountability for several key elements such as these on any technical project usually goes to the business analyst. These are critical elements to project success so if they are suffering, the business analyst may need to go. Be proactive, watch for signs. Take action.

Thoughts? Do you agree with these areas? What others would you include? Please share and discuss.

Read 7715 times
Brad Egeland

Brad Egeland is a Business Solution Designer and IT/PM consultant and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Creative Design, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. Brad is married, a father of 10, and living in sunny Las Vegas, NV. Visit Brad's site at


+1 # Scot Witt 2016-08-12 10:43
I think what's described here is a byproduct of Waterfall and Iterative failures. And placing that much responsibility on the BA suggests you need to find and keep senior, experienced BAs on your bench.

Otherwise you will get 2+ risks you've identified. And that isn't the way the world turns. You seem to ignore Risk Management and Mitigation as well as the more and more Agile team (you hint around that with deliverables) but with 16 years of Agile delivery, I need to remind everyone that these issues are resolved in that method, otherwise you've just killed the sprint.
Reply | Reply with quote | Quote
+2 # David Wright 2016-08-15 09:16
To Scott: not all projects are agile, we can argue why some other time, but projects of this style are still a dominant reality.

To Brad: I agree with Scott about "placing that much responsibility on the BA". Getting the Requirements done is the BA's job, and is crucial to the rest of a project. After that, things are much more collaborative across a team, but a tech lead will be responsible for selecting technology. Good requirements can help with that, especially if evaluating vendor packaged software, but otherwise technology belongs to the technology lead. (I may come back and discuss UAT, but end my comment for now.)
Reply | Reply with quote | Quote
0 # Ronnie Olsen 2016-08-16 07:37
I don't think this article brings much to the table, since I have to agree with David, that too much responsibility are on the BA.

Any development is a collaboration and team work, but good requirements will give good foundation, but bad design, project management, or development can still make the project fail. In my experience a project with good team work and collaboration where everyone take responsible for the product will have harder time to fail than otherwise.
Reply | Reply with quote | Quote
+1 # Roopa Rajaramadoss 2016-08-23 09:44
As a BA for the past 14 years, here are my 2 cents.
1. Functional business requirements are the responsibility of the BA.
2. Ideally, if a solution architect is present, they are responsible for the technology selection in collaboration with the technical lead
3. If the BA plays a dual role like I do many a times, both Business and systems analyst then BA's review becomes critical in assessing if there is clear traceability between the Functional and non-functional Business requirements, technical/ system/ data requirements, Design, and test cases.
4. In many process oriented companies, there is always a UAT lead assigned from the testing horizontal to oversee UAT testing. The BA acts as a liaison between the UAT lead and the Business team. If there is no UAT lead, then the BA takes the lead and coordinates with the Business team.

Unfortunately, there is too many responsibilitie s placed on a BA that makes them stretched thin. If that happens the project requirements will suffer.
Reply | Reply with quote | Quote
0 # Roopa Rajaramadoss 2016-08-23 09:45
*Correction- There are too many responsibilitie s
Reply | Reply with quote | Quote
+2 # Michael 2016-08-26 22:28
Too much responsibility is often placed on the shoulders of a BA, project delivery is a team work but many organisations tend to think BA's are magicians.....t he views expressed in this article also seem to suggest the business analyst is the only nerve required for successful project delivery. As a BA I'm walked into problematic projects many times where previous BA's have been fired, only to discover the issues faced are actually not all faults of bad business analysis.
A lot of times the problems facing a project could be top-down in the organisation, over-worked stakeholders & SME's, etc I once worked as BA with an insurance company and realised there was no clearly agreed MVP with the client, and as such the scrum master kept adding more requirements that required the BA needed more time investigation acceptance criteria that eat into his time, the product owner also wasn't very hands on thereby making the scrum master feeling over-burdened. When things don't work well on projects the BA unfortunately takes all the blame. Let's be objective, this article is not fair..
Reply | Reply with quote | Quote
0 # Claudia 2017-01-09 08:45
Hi Brad, is it possible for you to do some more research on the BA role and then revise points 2, 3 and 5? I see you are 'The most read author of expert project management content on Project Times/BA Times for 2015', but I fear this article might negatively impact your credibility.
Reply | Reply with quote | Quote
0 # Eleanor 2017-01-13 10:39
Having worked as a BA/BSA for 25+ years I have been in teams where the BA is covering all the above. There was no PM or Tec lead and the BA was expected to run the show. In this scenario the BA has the authority to make Tec team changes and the duty to check all documentation going to the Users so their neck is on the block. However if there is a PM surely the buck stops there in a number of these situations. In my mind it’s a poor PM who can’t help with UAT or sort out the Tec team. As for creating the best technical solution I often find there are lots of people in the business who think they know better than the BA so it can be difficult if compromises have to be made.
(Is it just me who noticed that the paragraph above the first point says “six signs” but everywhere else says five?)
Reply | Reply with quote | Quote

Add comment

Security code

search Articles

© BA 2016

DBC canada 250