A software business analyst (BA) has one simple mission: Maximize software value to the customer.
This breaks down into smaller goals, of course, like conducting interviews, writing clear requirements, communication, facilitation, etc. The BA heartbeat, however, needs to be crystal clear so that we don’t get lost in all the project noise: Represent the customer.
Developers want to write great software, testers want to deliver quality products, and project managers want to hit deadlines and budgets. Others surrounding the project have their own missions and motivations, but they are all different from the BA. Sure, you can argue that the entire team should be focused on the same goal, but that’s corporate speak that doesn’t reflect the nuances of how team roles differ.
Every day the BA shoulders the responsibility of translating customer pain and desire into prioritized actionable requests that a software team can efficiently understand, design and deliver.
We patiently endure hours of meetings, ubiquitous customer desires to design things and the tedious writing of feature definitions. We counsel and cajole and pry into the mysteries of our customer’s business until we can nearly run it for them, so familiar are we with the functional operations.
We forge a bond with our customer that both we and they depend on. Through the laughter, the frustration and the smell of dry erase markers we carefully stitch together a relationship that becomes a conduit connecting need with capacity.
When someone on our team suggests that the customer does not need something that we have painstakingly defined, we suffer the setback emotionally, buffering the customer from this techno-rejection and we fight for them, wielding the best business case we can make so that they can prevail in absentia.
We bring perspective and balance to the tug-of-war that is software development. We strive for the ideal solution while staying rooted in the reality of our constraints.
We track every change flowing from the customer’s dynamic world into the tower of the software genius, minimizing the impact of change where possible and accelerating understanding through diagrams, narrative, emails, knowledgebase updates and *gasp* meetings.
In the end, when the bug lists are clean and the stress of the rollout is a distant memory, we take satisfaction in having delivered on the trust our customer and our development team placed in us — a charge to deliver the most valuable software we could, given limited time and money.
If you recognized your own heartbeat in the description above and you are not working as a business analyst, maybe you are carrying the wrong title.