5 Signs You Need a Different Business Analyst on the Project

Written by Brad Egeland on August 10, 2016. Posted in Articles.

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.

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.