Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Getting Your Business Analysis Deliverables Organized
Previous Previous
 
Next Next
New Post 3/27/2014 8:23 PM
User is offline Meta BA
19 posts
9th Level Poster


Getting Your Business Analysis Deliverables Organized 
Modified By Chris Adams  on 4/23/2014 1:33:10 PM)

 We have all seen lists of all kinds of different business analysis deliverables, what I never see is a "which one goes where" so I have broken down it down by large categories that represent the high level phases of business analysis. I'd like your opinions and thoughts because becoming a great professional is about learning from those greater than yourself! Help me make my mental model better!

Understanding The Business - Business Case 

  • This might include Enterprise Level Requirements
  • Scope diagrams (context diagrams)
  • High level solution evaluations

Planning Your Work - Business Analysis Plan 

  • This is where you find that all important activity and work breakdown structure
  • Stakeholder analysis would be done here also

Defining The Solution - Requirements Package 

Evaluating The Solution - Solution Validation

  • The deliverable here is either evaluting several potential solution options or...
  • Evalutation an already designed solution to see that it actually meets needs.

 

 
New Post 4/28/2014 2:13 PM
User is offline Stephanie Cracknell
1 posts
No Ranking


Re: Getting Your Business Analysis Deliverables Organized 

I think this is an excellent start. I think we need a bit more about the processes and techniques as well as the deliverables.

Also, I think we are missing some key elements here such as identifying stakeholders, eliciting requirements and communication.

I tend to focus my activities in line with the IIBA for best practice and tend to focus as below:

1. Understanding The Business (enterprise analysis) & Define Business Need: 

  • This might include Enterprise Level Requirements
  • Define scope of the proposed solution
  • Scope diagrams (context diagrams) , process modeling, scope modeling, organizational modeling
  • Define Business Case
  • High level solution evaluations ( I would not include this here, as I feel it is too soon, and would include it as part of determining the solution approach), at this stage you would really just document what was in scope and out of scope

Outputs: Business Need, required capabilities, solution approach, solution scope, Business Case

  • 2. Planning Your Work - Business Analysis Plan & Monitor (the approach to performing business analysis and quality of business analysis)
  • ID stakeholders, define roles & responsibilities
  • Estimate time for business analysis tasks.
  • Planning how the BA will communicate with stakeholders.
  • Planning how requirements will be approached, traced, & prioritized.
  • Determining the deliverables that the BA will produce throughout the lifecycle of the project
  • Defining process for carrying out business analysis (methodology of project can dictate)
  • Determining the metrics that will be used for monitoring business analysis work (if your organization does this)

Outputs: BA Approach, Stakeholder list with Roles & Responsibilities, BA Plans, BA Comms Plan, Requirements Mgmt Plan, BA performance assessment (not all organizations define metrics for BA performance)

3. Elicitation (this is a massive one that I feel needs to be called out)

  • Prepare for elicitation (document analysis, surveys, interface analysis etc)
  • Conduct Elicitation (interviews, reqs workshops, brainstorming, etc)
  • Document results of the ‘Conduct Elicitation’ step
  • Confirm results through interviews, observation

**Note: while the IIBA does not list this as an elicitation technique, I have found this very valuable for uncovering hidden requirements or implicit knowledge. While it is fine to use this when documenting requirements, it is helpful when preparing for elicitation, to prepare some use cases and run through them with the users to validate your knowledge, and to see during observation, whether this use case is valid or if it is missing steps. I also use use cases after my interviews, to confirm with the stakeholders, that I have understood the process correctly.

Outputs: Supporting materials, Elicitation Results, Requirements (Stated), Stakeholder concerns, Requirements (confirmed),

4. Requirements Management

  • Manage solution scope & requirements
  • Requirements Traceability (matrix)
  • Maintain reqs for re-use (if your organization does this)
  • Prepare requirements package
  • Communicate requirements via workshops or structured walkthroughs

Outputs: Requirements approved, Requirements Package (this may contain requirements for vendor selection RFI, RFQ, RFP)

5. Requirements Analysis (requires input from 1, 3, and 4)

  • Prioritize requirements (MOSCOW)
  • Organize requirements (data flow diagrams)
  • Model requirements (data modeling, interface analysis, process modeling, prototyping, use cases/user stories)
  • Define assumptions and constraints (Risk analysis)
  • Validate requirements with stakeholders (acceptance criteria)

Outputs: Requirements (prioritized and verified), Assumptions & Constraints

6. Solution Assessment & Validation

  • Assessment of proposed solution with acceptance criteria/vendor assessment
  • Assess organizational readiness (SWOT, Force field analysis)
  • Define transitional requirements (where needed) these temporary requirements would apply to things such as data migration and disappear once they have been completed
  • Validate solution (identify defects)
  • Evaluate solution (solution performance assessment)

Outputs: Assessments of proposed solution, organizational readiness assessment, Transitional requirements, Identified defects how these will be mitigated, Solution performance assessment
 

Best Regards

Stephanie

 

 
New Post 6/23/2014 7:09 PM
User is offline Meta BA
19 posts
9th Level Poster


Re: Getting Your Business Analysis Deliverables Organized 

Stephanie,

Your confusing Deliverable with Work Product. Most of what you stated are considered work items. Which are things you produce to help you do your job as a business analyst. You can check the IIBA definitions on these two terms and how they differ.  

A deliverable is essentially valuable information that someone else wants out of you. For example, if you were a contractor, your client would expect a GAP analysis, Requirements document, or solution assessment.  They aren't the concerned on what you produce to get there like plans or elicitation results. 

Deliverables = the Job

Work Products = doing the job right

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Getting Your Business Analysis Deliverables Organized

Community Blog - Latest Posts

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC