In the IT-Software domain, all work begins with thoughtful planning over the product in making. At the onset, important facts and figures like current competition, market potential, target customer base, product features, unique selling points, conversion ratio, etc. are analyzed, compared and selectively chosen so that any gaps in the current potential can be covered and the product stands out.

The brain behind, thinking it all carefully, planning it precisely, and articulating it elaborately has to do it from primarily two different perspectives – the client (product sponsor) and the customer (product consumer). A person who can ruminate and write sane is required. Designers or developers cannot be introduced at this stage, and a tester just isn’t sufficient. Hence arrives a BA to set the fire ablaze.

Kicking off with the stage where the product life-cycle is planned – process flows, product functionality, user personas, use cases, testing scenarios, UI/UX best practices, customer onboarding, and a host of other software modeling topics are thought out and documented. It all begins with having a set of requirements, explaining them in detail and exploding in granular tidbits which have to make complete sense to each of the intended audience – promoters, the client, developers, designers, testers, UAT members, and everyone else.

Key Performance Indicators (KPIs) for Business Analysts

A Business Analyst starts at elaborating what the client wants and ends at trying to get it delivered. For everything in between, it all builds up a pile-full of various artifacts describing and detailing out the product that is waiting to go in the making – BRD, FRS/SRS, RTM/WBS, mock-ups, wireframes, test plans, epics/ stories/ tasks, etc.

And then gears start rolling; the BA teams up with members to carefully explain the product in every possible detail, getting mock-ups out in shape with designers, aligning with developers for logics and prototypes before bits and bytes of functionality, and sessions with testers over what is to be ticked vs crossed.

Shortly when outputs start rolling out, the BA takes care that the client dry-runs all this piece-meal as they always need to (and when they need not, they should) know what is happening from time to time – milestone to milestone.

At every iteration, the BA refers to the heavy set of documents, page-by-page and gives a demo on the outcome, co-testing it with how the client envisaged (well, initially). To avoid going astray and identifying early derailing on a smaller piece of the product rather than wait for the last mile U-turn on a full-throttle, the BA carefully scales between what was required and what is being delivered – with clear-cut exceptions and right expectations, every time.

Additional work requirements and change in preferences start creeping now that the client starts understanding. Re-work amidst those short-burst deliveries end up having to further analyze, document and plan the product. And who else than BA could be the best person to do it all with all the handy details from the back of their mind.

After numerous cycles of stop-change-restart on those gears, the ultimate dawn breaks and the product goes live, wide in the open. Staff training, how-to guides, product KB, etc. come to the front foot. The BA transfers all product know-how, it’s all at the top of their mind, after all.

And because BA has to write it all, communicate with the client, and deliver presentations/demos, they need to be a second-in-Shakespeare with their language skills; and a writer, of course.

So much for a BA to try taking over the world.. and all their world is – a happy, smiling client.