Principles of Business Analyst

Principles of Business Analyst

Business analyst is liaison with all the stakeholders. This eventually a center of attraction in any project. I would say, rather than a Project manager, the Business analyst certainly a driver of wholesome.

If you could perceive an architecture of a building, Business analyst is base of a building, roof and cement. Having said that Business analyst a wholesome. I might be biased here as a Business analyst, i am trying to express that business analyst is every part of a cellular structure in a project. You can’t ignore this.

Business Analyst a courage to say, 

• We align the assumptions, disagreements, Implicit and explicit asks by business, desired needs in order.
• Clarity in picture in mind of stakeholders with all chaos and silos of information.
• Responsible for captive changes in an organization that might impact different segments, business units and benefit cycle may extend to their customers and suppliers.

You have always this honour badge, Ladies and Gentlemen !

Responsible to jot down few principles that could help us in focusing the goals and end results in right order.

1. Stay Hungry for Knowledge
2. Don’t jump to Solution Quickly
3. Running a Rhythmic Mind Mapping in Elicitation
4. Courage is Must
5. Not to be Biased
6. Advocate on Alternatives
7. You are the Owner — Accept it
8. Transparency Communicator
9. You are Driver, don’t Forget to Reach the Destination
10. Playback is Imperative

Let’s go in detail

Stay Hungry for Knowledge

Prepare prepare prepare before you dwell into requirements session. Review and Research of previous projects lesson learnt on same conditions.

Collect and Review the secondary documentation of the Business. Out of box, Yes ! then knowledge experiment on industry best solutions on same conditional problem statement.

Caution! Doing all these activities just to rack up your knowledge base, don’t jump to solution or ideas or biased information. When the requirement sessions are started, i always be a keen listener and whatever i just prepared / reviewed is only for analysis and that should not pull you in conversation that i have a solution or i read like this, why can’t we do this?

Don’t jump to Solution Quickly

Allow freedom of speech, Listening is the key element !!

Solution proposals are on-going process. Requirement elicitation is to just conserve the verbatim of the Customers. Just focus on Stakeholders asks, Caution — Choose your right stakeholders.

Focusing and discussing solutions upfront in initial discovery phase, you tend to lose the information, the actual requirements. Both of you, i meant Business Analyst and Interviewee should communicate on the requirements not the solutions. 

This is the trap of losing information, focus is important. You are a facilitator, so the session engagement and boundary definitions are all yours. 

Facilitation of the meeting session is an Art.

If boundary is not defined, you again fall into a rabbit hole of Scope creep. Sad right !! But that not a big deal. Enjoy the facilitation in listening and speak on boundary deviations. Analysis and Solutions are next phase. 

Keep Simple, that works in Discovery phase. 

Running a rhythmic mind mapping in elicitation

Having said, the Listening is Prima factor. This helps me in rhythmic mind mapping in elicitation. This is not in the Discovery phase, i practice this in next phase Elaboration.

Always i will structure and prepare my mind with the granular structure of asks and ready with documents for Interview. Any answers, i play a rhythmic mind mapping, the multiple if then statements. This helps to understand the alternatives. Caution ! Don’t jump again on the solution and technology, then you lose the alternatives that adds the real value.

Rhythmic is not visible to others, that is internal to your mind. Caution — But don’t loose focus on the meeting.

Focus on the specification in granularity, till i find no granular. Caution — To many if then statements, questions may harm the actual requirements discussed. You should know what should be asked and what will deviate the study. Sometimes, these questions ask, you might be secret agent for Scope creep.

This help us in understanding the Alternatives, Assumptions and Exceptional flow.

Courage is Must

You are empowered for the first time right. 

Highlight the risks and don’t be afraid of escalations. Highlighting upfront will save lot’s of efforts, other people’s efforts too. Believe this will bring more surprises on cost and timelines of projects slippage later.

Caution — Don’t be in a separate track, sometime in project interest should ride along the wave. But don’t be biased with the people’s interest.

1.  Ask the right questions to get the right answers.
2. Challenge the process controls, alternatives and the way the actual practices where the development in previous projects.
3. Right to Escalate.
4. Don’t accept the Solutions or Requirements, until you analyse and accept. People might think that you don’t believe others but keep this practice internally.
5. Be Transparent on Project Status on the Requirement Phase. Highlight the Risks.
6. Courage to discuss the values and challenge solutions with Leadership teams. Each stakeholders sees their own values. End user want an ease of use product, Middle managers wants the lesser turnaround time, Leadership team wants the cost optimized product. Challenge everybody at each stakeholder level.

Not to be Biased

Biased can be a People, Stakeholder Authority, Client Profile, Information, Assumption etc.,

In General, Biased free will be the non-ambiguous requirement.

Even sometimes, biased on the Knowledge of the Interviewee. Stakeholders will not have requirements and they do not know, how to express or articulate it.

Remember you should elicit the requirement and don’t expect that they will give you all asks or needs they want. In many projects, i have seen this context that these are never said in the requirement sessions and it is a new requirement in UAT, so it a change that goes in to Change Management. No dears, this is not a fair and right approach. Clients trusted you and your company, it is your duty to collect the actual needs. Envisage the requirements and discuss.

Remember that requirements don’t exist until business analyst analyse them. This mindset shift alleviates some of the main complaints from Business Analysts; namely the business doesn’t know what they want and the requirements keep changing.

Advocate on Alternatives

You are lawyer who never goes to law college. Yes ! it is true, advocate on the alternatives and ranks basis the business value. Discuss the alternatives, simulate the benefits and choose the best one.

Caution — Don’t apply the technological or predetermined solution factors while advocating an alternative.

Choose an alternative and then apply all the other factors to choose the effective approach. I always love doing this.

You are the Owner — Accept it

I said in this initial read that you are driver. Yes ! you are a driver and owner of the Bus. You are the owner of the Solutions, Requirements, Communication to right people.

I always go by my leader’s thoughts, Accept Failures. Success is just a success, but failures are real lessons in part of your journey.

Your ownership doesn’t just drop by completing the System Requirements Document or whatever the other documents, after passing on to development team. You are a driver, don’t forget. Remember that the document should be the recording of all the communication that has occurred beforehand, not the communication itself.

Collaborate with your team and you are a liaison with all teams. Be an owner till it is delivered. Learn, Adapt and keep others learn.

Transparency Communicator

This principle is very straight, be a transparent communicator. Chose the right stakeholders and right communication that reaches them.

Communication or status publishing is not only through mails

Communication has many platforms like meetings, calls, emails etc., choose the right medium to communicate and more important the right information.

Time of communication is also important. I have heard from business analyst folks, that i have sent them an e-mail and it is his / her fault where he didn’t replied or seen my mail, how can this be my fault. It is true, but let us take some accountability of following up until the action is commissioned.

Choose the time of your mail it reaches their inbox and probability of reading it and those mails should not go-off or ignored with plenty of mails that reaches their inbox. Follow-up gently until you see some actions on it.

You are Driver, don’t forget to reach the destination

Having said in this read, drive your bus till it reaches the destination that is Go-Live and support. Your responsibility should not stop after the requirements are signed-off.

Training and you should be change agent. There will be always a change resistance in customer end, but you can easily crack this code by exhibiting the benefits for them. When you talk to end customers, talk in their beneficial language. 

You can have a best solution in the world, eventually this should be accepted by the users. Transition this state cautiously and enjoy this transition.

I will always love in seeing happy faces when they see some benefits to them which make them happier. This happy face always motivates me to go longer and longer on. 

Playback is Imperative

I always express as Story line whatever i gathered so far. Sometimes i playback the functionality and sometimes a whole application.

This playback sessions, is the other form of conformance of requirements.

In today’s world, Design thinking is revolved around this play back.

Readers, these are my experienced principles. These are not only the principles, just thought of sharing my experiences. Cheers!!