Posts Tagged Business analyst
Business analysts – are we really?
Since the start of our BA forum I’ve been grappling with the idea of what value I can add to assist others and also to understand how they are thinking. We often we get caught up in old thinking patterns of “this is how we always did it before”. Yes, I agree that the wheel should not be reinvented but surely we should be ADDING VALUE when recommending solutions.
This is first my stab:
BA competencies, now I’m racking my brains a bit. Google it and you’ll get thousands of hits (just a guess).…just had to for my own peace of mind, Google says about 3,200,000 results.
When chatting to other BA’s they battle to keep the stakeholders focussed on the actual business requirements, possibly because it’s easier for anyone to start thinking in solution mode. All BA’s should know that it’s imperative that we get the business requirements accurate for any project. The BABOK guide describes business requirements as “high-level statements of goals and objectives” but at times we fail to keep the stakeholders involved throughout the development of their solution. Surely it’s in our best interest to involve them as often as we can since they are closest to the requirement. Why not involve them in design decisions? Why not? My response to this – “it depends”. BA’s need to assist the stakeholders by keeping them concentrated on the problem space and at the same time ensuring that we are building the correct solution. Good BA’s are able to realise when these boundaries are about to be crossed.
My advice to BA’s is:
1. Define the business problem correctly, if not, you going to deal with scope issues.
2. Keep stakeholders involved but be aware when they are giving you the solution.
3. Ensure that you are able to validate any information elicited.
4. If possible, recommend more than one solution.
5. NEVER stop talking to the stakeholders – value “customer collaboration over contract negotiation” (a principle from the agile manifesto – http://www.agilemanifesto.org).
6. Ask why? You’ll be amazed how many times you can.
7. Remember, you play an important role in translating stakeholders’ needs into good requirements for the software development team.
I look forward to any comments.