Written by: Nan Weng (first published on LinkedIn) CareerCamp Mentor, BA Expert
I often have difficulty explaining my work to people who are distant from the project world. When I introduce myself as a Business Analyst in financial industry working in projects, I often receive questions like: how has the stock market been doing lately? Should I buy this stock now? When should I sell?
Let me try to explain here, starting with my colleagues:
The Project Manager, who thinks 9 Women can deliver a baby in 1 month.
The Development team, who estimates 18 months to deliver a baby.
The Project Coordinator, who documents 9 months for carrying a baby.
The Operation Manager, who believes 1 Woman can deliver 9 babies in 1 month, if she works hard enough.
The Executive, who thinks he can deliver a baby even if no man or woman is available.
The HR Manager, who will find the perfect man after the baby has been delivered.
The QA team, who is never happy with the delivered baby and logs every suspicious thing as a defect; however, the development team will then argue that, those are just undocumented features of a perfect baby.
The Project Sponsor, who will always claim the baby is successfully delivered in the end, on time and on budget.
The Customer, who doesn’t know why he needs a baby after all.
If Google it, you will find many slightly different versions of these hilarious definitions. They resonate with people because they, to certain extent, reflect the reality. But you don’t see me, a Business Analyst, in the picture, do you? Now, here is my contribution to the joke: the Business Analyst, who finds out that what exactly the customer needs, not a human baby, but a robotic pet!
Jokes aside, I don’t want to offend anyone I have worked with, not only because they are all decent professionals, but also because I am connected with most of them on LinkedIn, there is highly a chance they will be reading this article soon, and I am far from my retirement age.
Everyone plays an important role in a project, no doubt about that. What I want to emphasize here is only the role a Business Analyst takes in a project.
If I had to use only one sentence to summarize what a project is, I would say “plan the work and work the plan”. This I learnt when I was studying for my PMP designation about 15 years ago.
The first “work” is the “what”, what the customer needs (not whatever they want), which relies on Business Analyst to dig out and to communicate this need to all of the stakeholders. Project stakeholders includes the project team and people who will be impacted by the project work and/or project deliverables to a certain extent.
The second “work” is the execution process of delivering the solutions to meet the customer’s needs or requirements, where again the Business Analyst also plays a critical role. A Business Analyst or BA will make sure the stakeholders are on the same page regarding the first “what”, throughout the entire course of a project, especially when any change occurs. If a question comes up during the execution, for example, the defect vs. feature arbitration, the BA is the one who will clarify with the customer, then triage, then make the call.
Towards the end, the BA also helps the customer to test the solution to make sure the deliverable has satisfied the customer’s needs and prepares them for organizational change to adopt the new solutions.
In some organizations, there is another role called the Business System Analyst, who works more closely with the development team on system requirements, which refers to the technical specifications based on the business requirements. This involves translation from “what” to “how”. I have done both roles, sometimes simultaneously during one project; this can be the topic for the next article.
A project, unlike ongoing operational work, has a start and an end. It has three main constraints, time/schedule, money/budget, and people/resources. Below is an illustration of the relationship between the three constraints to the center of the project, the scope. The schedule, budget and resources are impacted by scope; the scope is defined by business requirements; and business requirements are owned by the Business Analyst.
Finally, I am in the picture:
If the schedule, budget and resources are not balanced, either the scoped work won’t be fully delivered or the quality of work will be sacrificed. Something or someone will get squeezed somehow.
Not limited to financial industry though, a good business analyst in any project is the one:
who can identify exactly what the customer really needs, through analytical and communication skills as well as business acumen, and not just go by what they want;
who can articulate the requirements clearly and efficiently (perhaps with the aid of graphics, like my beautiful pictures above); SMART* requirements are the foundation of a high-quality solution;
who helps with all aspects of a project, including planning, development, testing, organization change management, and communication; the BA leads the project through content, not through authority.
It is said that the devils are in the details; business analysts live and struggle with devils every day. This is what we do.
After you read this article, hopefully you will hold no more questions about the stock market. If I knew what to buy and when to sell, I would never need another BA job.
Note*:
SMART is an acronym for “Specific, Measurable, Attainable (Achievable), Realistic, Timely”.
The principal advantage of SMART requirements is that they are not ambiguous, easier to understand, to implement, and then be reassured that they have been done.