Scribd Logo
Upload

Welcome to Scribd!

  • 20 views

    BAs Work Flow in The Project

    Uploaded by

    manoj sharma
    The document outlines the typical flow of work for a Business Analyst (BA) on a project. It describes 15 steps from initially joining the project to requirements gathering, documentation, testing and eventual completion. The BA is involved in meetings, documentation, requirements elicitation, analysis, supporting design and development, training, and ultimately software launch.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd

    BAs Work Flow in The Project

    Uploaded by

    manoj sharma
    20 views17 pages
    The document outlines the typical flow of work for a Business Analyst (BA) on a project. It describes 15 steps from initially joining the project to requirements gathering, documentation, testing and eventual completion. The BA is involved in meetings, documentation, requirements elicitation, analysis, supporting design and development, training, and ultimately software launch.

    Original Description:

    BAs work flow in the project fron start to End of project

    Original Title

    BAs work flow in the project

    Copyright

    © © All Rights Reserved

    Available Formats

    PPTX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The document outlines the typical flow of work for a Business Analyst (BA) on a project. It describes 15 steps from initially joining the project to requirements gathering, documentation, testing and eventual completion. The BA is involved in meetings, documentation, requirements elicitation, analysis, supporting design and development, training, and ultimately software launch.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    20 views17 pages

    BAs Work Flow in The Project

    Uploaded by

    manoj sharma
    The document outlines the typical flow of work for a Business Analyst (BA) on a project. It describes 15 steps from initially joining the project to requirements gathering, documentation, testing and eventual completion. The BA is involved in meetings, documentation, requirements elicitation, analysis, supporting design and development, training, and ultimately software launch.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    of 17

    BA’s Flow of Work in a

    Project

    TrainSmart Academy

    7021437151
    Step 1: BA joins the project

    • BA is selected by PM / Delivery Head to be a part of a project


    • Bas are selected on basis of their experience and domain knowledge in a project
    • BA is given existing documents by PM / Delivery Head / Sales. These may include RFP / Old BRDs / Old
    FRDs
    • BA may also start reading domain documents. (Technique used Document Analysis)
    • BA enhances his knowledge by reading domain related material from Google / internal company
    knowledge repository etc.

    Note: Old BRDs and FRDs would be only for enhancement or re-engineering projects. For new projects only RFP may be
    available
    Step 2: Kick off Meeting

    • BA, PM, PL Solution Architect all key members from vendors end have a project kick off meeting with
    the client.
    • From clients side generally Sponsor, Business, Point of contact attend this meeting. Mostly Money Men
    from clients side.
    • Kick off meeting is where the client explains first hand why is the software being created
    • BA should make a note of all the stakeholders involved in the meeting.
    • BA should ask questions around who would be the other stakeholders involved in elicitation.
    • In this meeting BA should try to gather two important details
    1. Why is there a need for the software?
    2. Who all will be involved in elicitation?

    Note: He will not get all details at this stage but just an overview. Trust me nothing valuable comes out of kick off
    meeting. This is one of the many useless meeting that software professionals attend in their career. 

    • BA should be able to explain to client how will he be doing requirements gathering

    • (Technique – Stakeholder analysis – can use RACI / Onion Diagram / Stakeholder matrix.
    Step 3: Elicitation Meetings with Sponsor and Business stakeholders to understand Scope

    • BA will have a few meetings with the clients to understand the following:

    • Need for software


    • Scope of software (Technique: Use Case Diagram / Context Diagram / Interface Analysis / Scope
    Modelling)
    • Come up with high level feature list.
    • Vision of software
    • As Is state (technique: Process Modelling / BPMN)
    • To be state
    • Change strategy (i.e. how to reach from AS IS – TO BE)

    • Documents created – Vision Document / Business Case Documents / Change Strategy / Scope
    Document / BRD

    Note: these are all documents that CAN be created at this stage. This doesn’t mean that BA will create all of them.
    Depending on company to company you may create any one of them or few of them.
    Step 4: Sign Off on Scope Document / BRD / Vision Document / Business Case

    • BA will aim to get a sign off on the initial scope.


    • To get sign off he may have a review session with the clients. (Technique – Review)
    • Initial documents depicting Scope have been signed off
    • BA by this stage has a more or less complete list of stakeholders who will be involved in elicitation. He
    can create an importance / influence matrix at this stage.
    • He will identify the elicitation meetings frequency and fixes days of elicitation with the client.
    • He will finalize the FRD template with the client
    • He will finalize the Change Request Process. Client identifies who will be responsible for approving CR
    from their side.
    Step 5: Requirements Elicitation

    • BA starts the elicitation process. He may use multiple techniques like:

    • Interviews (Video conferencing)


    • Document analysis
    • Questionnaire
    • Brainstorming
    • Focus groups
    • Workshops
    • Prototyping
    • Mock ups / Wire frames
    • Observation
    • Mind Maps
    • Functional decomposition (he may mentally break down full project into multiple requirements
    that are co-related to each other)

    Note: He uses whichever technique he feels is appropriate. It doesn’t mean he uses all of these at one time.
    Few of them are used simultaneously. BA is also learning which techniques may work well . He is also
    learning stakeholder management. Which stakeholders are good and which are pain in the - - - 
    Step 6: Requirements Analysis

    • Requirement Analysis is not really a separate phase. It just means he weeds out duplicate information,
    incorrect information. In case information is incomplete he conducts further elicitation.
    • New stakeholders may be identified in the elicitation meetings as well. Then BA needs to gather
    requirements from them as well.
    • He actually does Requirement Analysis along with elicitation.
    • He tries to see if any requirement is not gathered or missing.
    • He tries to find gaps in the requirements.
    • If all requirements seems complete he moves on to the documentation part.

    Note: Surprise BA doesn’t know but he has missed a few requirements . They will be caught by developers and testers
    further down the SDLC. They may be caught by client before FRD sign off (oh that’s not good). They may even be caught
    in the UAT (trust me if this happens BA faces music in his appraisals 

    No BA is perfect they always miss a few details


    Step 7: Requirements documentation

    • BA starts the requirement documentation.


    • He may use following to depict the requirements:

    • FRD
    • Use Cases and data elements
    • Process Modelling (Process maps / BMPN / Cross functional flowcharts)
    • Wire Frames are created either by UX UI person or BA himself
    • Data dictionary
    • Sequence Diagram
    • Data Flow diagrams

    • Note: this is an indicative list. Your company may have a different mode of gathering requirements.
    Hence you need to attend a training program @ TrainSmart Academy to know all these tools.
    Step 8: FRD Sign off

    • BA will run around trying to catch the client to get FRD sign off. Client becomes always very busy
    before the sign off . Client is never available to sign off  vagaries of the BA role.
    • To do this arduous task he would have review meetings. (Technique: Review & Workshops)
    • Change requests (CRs) can pop up anytime during elicitation, analysis, FRD documentation stage.
    • BA will have to go through the change control board if it happens.
    • BA will have to create CR documents if this happens.
    • Sign off done.
    • It does finally happen someday after a lot of following around with the client  BA is happy
    Step 9: Support Design / Development

    • The team moves into design phase.


    • BA starts training the development team on domain / requirements
    • BA has meetings with UX UI designers to help them complete the wire frames
    • BA has meetings with solution architects / Project leads so they can understand requirements better to
    design the High level and low level design documents.
    • Missed or incorrect requirements may be pointed out by UX UI Designers / solution architects / Project
    leads.
    • In this case BA will again go back to client for further elicitation meetings as and when needed
    Step 10: Development starts

    • Now the development of software has started. TL / PL has assigned work to developers.
    • BA supports all development team’s queries.
    • BA may have individual one on one sessions with each developer explaining him the requirements that
    he is supposed to code.
    • Missed requirements pointed out by development team are clarified from client
    • Client queries on development are clarified by BA by taking help from development team members
    • BA starts preparing functional test cases.
    Step 11: Testing starts

    • Now the testing of software has started.


    • BA does functional testing.
    • BA does UI Testing – checks look and feel of software is fine.
    • Manual testers do functional testing
    • Automated testers do automation testing
    • Bugs are raised
    • Once developers fixes the bugs BA needs to retest the system along with the testers.
    Step 12: UAT Testing starts

    • Hey we have solved all the bugs and submit the software to client for UAT
    • BA may or may not be a part of UAT. Depends on organization to organization.
    • He handles client queries at this stage.
    Step 13: Training of client

    • BA may be involved in creating user manuals.


    • Technical writers are supposed to create user manuals. But BAs are very skilful. In absence of technical
    writers they take on this task and create a user manuals.
    • These manuals are distributed to the client.
    • Client will need training on the software.
    • BAs are multi purpose resources they start training the client in how to use the software.
    • Client learns how to use to software project is coming to an end.
    • Again client may have CRs at this stage. BA creates relevant CR documents.
    • BA starts asking for a release from this project.

    Note: at different times of the project BA trains different people. At the start solution architect / PL in understanding
    requirements to create a High level design. In middle of the project he trains developers and testers in the domain and
    requirements and at the end of the project he trains the client on how to use the software. No wonder I became a trainer

    Step 14: software goes live

    • Client starts using the software.


    • BA is released from the project.
    • BA is looking for the next big project that will escalate his career.
    • And he is assigned in some new exciting project
    • Go back to step 1 and start the BA journey again
    Step 15: BA’s Life Cycle

    • And someday he has done enough business analysis maybe 8-10 years down the line.
    • He then decides to exit the BA role.
    • This will be the end of his BA journey.
    • Adios to BA role
    • He starts in a new role.

    Good luck to all you budding BAs


    THANK YOU!

    TrainSmart Academy

    7021437151

    You might also like