The Unsung Heroes- Business Analyst

2
400

It is very common for large organisations to hire Business Analysts (BA) in droves when working on a very large project. This is possibly due to the positive impacts BAs have on projects and most importantly the value a good BA brings on board until questions start popping up about BAs.

It is not uncommon to find business unit heads, project sponsors, and so on, asking why a BA is needed in the first place. You usually hear things like “why do we need a BA, it is a technology-driven project, let the tech guys do all the job”; a common one being “all BAs do is to sit down and write a requirement document all day long, I could pay the techies to do same”.

It is quite easy to have these sorts of sentences flying around a project delivery environment. This is possibly so because the project teams only get artefacts from BAs and the art and science of being a BA and documenting those high-quality artefacts are quickly forgotten. After all, I get a requirement document and my “tech guys” build something tangible from it and at the end of the day, real value comes from the end product. Wrong!!!

Real value can be directly attributed to every detail that goes into designing, documenting, creating and implementing something that the end user will be able to consume in an easy, manageable and sustainable way. The end user is the one who truly decides whether a deliverable is valuable or not and truly that is where a BA’s actual value is derived.

BAs are usually the internal consultants who carry the load of ensuring that a project delivers a tangible or intangible result that solves a problem. To be able to proffer a solution to a problem, the BA goes into an investigative mode.  They strip the identified problems into the granular elements to understand the root-cause. They perform an in-depth current state analysis and help shape the future state analysis; at the end of this exercise, they draw up a comprehensive GAP analysis. They identify the processes to see where an improvement, design or consolidation is required. They perform detailed end to end analysis to help uncover how the problems should be approached. The end result is a very detailed requirement document which identifies the functional and non-functional requirements along with the criteria to determine the acceptability of the requirement when tests are being performed. These requirement documents then go through their life cycle to ensure they are of Gold Standard, and they meet the business expectations.

The job of a BA does not end there; they play a support role during the technical design phase, helping to close any gaps that exist between the technical designers and the business owners. They then support the testers before the projects “go-live” to ensure the deliverables perform as they are meant to and finally to ensure they are fit for purpose (what’s the point in delivering something so beautiful that only the eyes can appreciate and users cannot use?). Those untrained in the art and science of business analysis will say “job done, give ‘the BAs a standing ovation”. Sorry can do, but our jobs do not end there.

As BAs, we continue to provide support during the early deployment of the project. We also help the business to define and identify the Key Performance Indicators (KPI), after which we help with firming up new processes identified along with the work instructions (a level five process). Then we help to train the users and finally, we carry out the post implementation or benefits realisation review. After all, is said and done, we either remain as a “Subject Matter Expert (SME)” or move on to perform the same Art and Science of Business Analysis on other projects.

So looking at this gives an idea of just the tip of the iceberg in what BAs do, it makes me wonder, do BAs need to wear a cape and glide around the company shooting out infra-red beams from our eyes or blowing out ice from our breath in order to be recognised for the values we add to an organisation’s project or do they just remain as the quiet unknown “Clark Kent” who is seen as just another dead weight to an organisation?

That is a question for employers, Project owners, Department heads, etc., to answer.

I will conclude that BAs do a darn fine job, and they need to be recognised along with other hard-working project teams who bring a project to a successful conclusion.

About the Author

?
Toyin Aromire is the Co-founder of Analyst2Hire. He is also a Lead Business Analyst in one of UK’s top Telecommunications company. He has got extensive experience across different industry sectors

2 COMMENTS

  1. I guess the main challenge is being able to distinguish where the remit of a BA lies and perhaps starting off with a BA plan will help set the boundaries for what is required. It’s good to add value as a BA and sometimes, you need to consider how much value you can add as a BA. one way to do that might be to check the level of support required for each of the project impacted area and ensure you do not cross the line from being a BA (business analyst) to being a BA (bloody anything)

  2. So true. And some people even think that BA stands for Blooody Anything and distract the BA onto other tasks not related to ensuring customer requirements are explicit.

LEAVE A REPLY