Monday, July 13, 2009

IIBA Definition of a business analyst role

A Business Analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The Business Analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.

22 Steps to a successful project

1. Clear,complete,accurate,consistent,compact documents.

2. Redundancy of information should be avoided always.

3. Scope Creep. Almost always happens. Tough to deal with but be prepared.

4. Document all communications/evidence/proof. If you don't, it bites you back later on.

5. Never commit/promise to users just based on what YOU think could be an easy turnaround. Always discuss with the correct parties involved first.

6. Keep things as simple as you can. You don't want to explain code to a business user necessarily and confuse them. Talk the language accordingly. Remember, your customers are more interested in the WHAT and not the HOW.

7.Create a context diagram, which defines our system and things that'll interact with our system.

8.Define actors and their goals.Ask questions like Does anyone will get any info from the system,Who'll maintain/install the system etc.

9.Identify how each actor will initiate or interact with the system to find out basic course of event.

10.Maintain a glossary of all the business terms.

11.Identify business rules and constraints.

12.Identify nonfunctional requirements like GUI look and feel,security,reliability,data retention etc.

13.Try to ask question in client's language because if you ask questions in their language they can understand your question better so try to learn business domain of client,their business terms etc.

14. Perform Functional & Source Data Flow Review. Keep the client in loop of whats feasible & whats not feasible

15. Document and keep the client in loop on all the assumptions in design / development phase

16. Before final delivery its very essential for a BA to perform a high level funtional review / testing of the client requirement

17. Identifying dependencies / Escalation of risks / issues likely to affect the design / development / testing phase & follow-up with the risk mitigation, resolution of issues with respective teams well in time.

18. Follow-up for a signoff & request feedback once the requirement is delivered / freezed & in use for a substancial period.

19. Keep Monitoring & try to suggest better solutuions / approaches for deliverables incase of recurring requirements (eg: reports).

20. Always try to identify the risk items at early stage. Try to build the prototype of those to seek appropriate clarifications at early stage of the project

21. Try to find out the improvement areas which can be modified/improved/enhanced in further phases.

22. Don't give surprises, instead keep your project team and clients informed about your progress and the solution you are working on.
Been a long time since i posted ... will make a resolution to be more active.

Just came across this paragraph, which neatly defines what a software should be.

Great software should do what it is supposed to do, while remaining highly maintainable, scalable and adaptable to change. It should be bug free, and easy for the users to use.