Business Analyst Training

  • 18,404 views
Uploaded on

A presentation pack I used when training business analysts.

A presentation pack I used when training business analysts.

More in: Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
18,404
On Slideshare
0
From Embeds
0
Number of Embeds
6

Actions

Shares
Downloads
3,342
Comments
9
Likes
46

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. For Business Analysts Craig Brown www.betterprojects.net
  • 2. Business Analyst Training
    • My agenda
    • To explain the role of the business analyst,
    • To discuss the methodology described in the BABOK
    • To discuss practical tips and techniques for doing the job well
    • To review sample requirements specifications to get an appreciation of what goes into them
    • To provide a list of further resources analysts can call upon for help
    • Your agenda
  • 3. The Business Analyst Context > Role > Skills
    • Context
    • Projects and SDLC
    • Why projects go wrong
    • Project team roles
    • 8.15-9.45
    • What BA’s do
    • Requirements Management
    • Business Processes
    • Human change management
    • Project Portfolio Planning
    • 10.00-11.00
    • Practical skills
    • Technical skills
    • Analysis exercise
    • Questions and discussion
    • 11.15-12.15
    break break
  • 4. Projects and the SDLC Release Test Close Build Design Requirements Product Scope PMI Project Management Process Waterfall Development Initiate Plan Monitor & Control Implement
  • 5. Projects and the SDLC Release Test Close Build Design Requirements Product Scope PMI Project Management Process Waterfall Development Initiate Plan Monitor & Control Implement
  • 6. Projects and the SDLC Product Scope Release Test Initiate Close Build Design Requirements PMI Project Management Process Waterfall Development SCRUM PRINCE2 SIX Sigma Agile RAD Rational Etc. Etc. Plan Monitor & Control Implement
  • 7. Projects and the SDLC Product Scope Release Test Initiate Close Build Design Requirements PMI Project Management Process Waterfall Development SCRUM PRINCE2 SIX Sigma Agile RAD Rational Etc. Etc. Plan Monitor & Control Implement
  • 8. Projects and the SDLC Release Test Initiate Close Build Design Requirements Product Scope PMI Project Management Process Waterfall Development SCRUM PRINCE2 SIX Sigma Agile RAD Rational Etc. Etc. Plan Do Check Act Plan Monitor & Control Implement
  • 9. Business Analysis and the BABOK Release Test Initiate Close Build Design Requirements Product Scope PMI Project Management Process Waterfall Development SCRUM PRINCE2 SIX Sigma Agile RAD Rational Etc. Etc. Plan Do Check Act Plan Monitor & Control Implement
  • 10. Projects and the SDLC Release Test Initiate Close Build Design Requirements Product Scope PMI Project Management Process Waterfall Development SCRUM PRINCE2 SIX Sigma Agile RAD Rational Etc. Etc. Plan Do Check Act Plan Monitor & Control Implement
  • 11. Project Failures
    • There are many reasons why projects fail.
    Poor strategic alignment Long time to delivery Poor risk management Poor planning Lack of sponsor involvement Ineffective communication Lack of handover (people change management) Team skills (esp. interpersonal skills) Poor requirements management is consistently in the top 3 reasons, regardless of the source Lack of formal pm processes Poorly defined objectives/scope Poor or wrong requirements
  • 12. The cost of bad requirements
    • The following are a few key findings and data from the study:
    • Companies with poor business analysis capability will have three times as many project failures as successes.
    • 68% of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis . In fact, 50% of this group’s projects were “runaways” which had any 2 of:
      • Taking over 180% of target time to deliver.
      • Consuming in excess of 160% of estimated budget.
      • Delivering under 70% of the target required functionality.
    • Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects.
    • Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization.
    • The vast majority of projects surveyed did not utilize sufficient business analysis skill to consistently bring projects in on time and budget. The level of competency required is higher than that employed within projects for 70% of the companies surveyed.
  • 13. The cost of bad requirements
    • The following are a few key findings and data from the study:
    • Companies with poor business analysis capability will have three times as many project failures as successes.
    • 68% of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis . In fact, 50% of this group’s projects were “runaways” which had any 2 of:
      • Taking over 180% of target time to deliver.
      • Consuming in excess of 160% of estimated budget.
      • Delivering under 70% of the target required functionality.
    • Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects.
    • Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization.
    • The vast majority of projects surveyed did not utilize sufficient business analysis skill to consistently bring projects in on time and budget. The level of competency required is higher than that employed within projects for 70% of the companies surveyed.
  • 14. The cost of bad requirements
    • The following are a few key findings and data from the study:
    • Companies with poor business analysis capability will have three times as many project failures as successes.
    • 68% of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis . In fact, 50% of this group’s projects were “runaways” which had any 2 of:
      • Taking over 180% of target time to deliver.
      • Consuming in excess of 160% of estimated budget.
      • Delivering under 70% of the target required functionality.
    • Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects.
    • Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization.
    • The vast majority of projects surveyed did not utilize sufficient business analysis skill to consistently bring projects in on time and budget. The level of competency required is higher than that employed within projects for 70% of the companies surveyed.
    Requirements Professionals ? ? ? ?
  • 15. Project Failures IAG report can be accesse at iag.biz
  • 16. Requirements Failures
    • The volume and complexity of stakeholders
    • Stakeholder expectations & involvement
    • Who is managing the requirements - skills of the requirements team
    • Process
    Not deliverables
  • 17. Requirements Failures
    • Avoid requirements failure by doing these things;
      • Feedback
      • Have developers feed back their interpretation of requirements to the stakeholders and clients. Do it early and often. Use workshops, wireframes, prototypes, or documents, but do it.
      • Bring people together
      • Bring the subject matter experts and requirements owners into the same room as the developers. Get them talking to each other. If you can't be in the same room, arrange regular meetings. Don't rely on written communication.
      • The right Requirements team
      • Make sure your BAs are trained and highly skilled at requirements management (ie not just elicitation, but the whole shebang.)
    • Practical tips
  • 18. Project Team Roles
  • 19. Project Team Roles Sponsor Project Manager Business Analyst Change Manager Quality Solutions Team Liaison Roles Process Analysts Trainers Testers Solutions Architects SMEs Systems Analysts Technical Writers Users Designers Developers
  • 20. Sponsor Project Manager Change Manager Quality Liaison Roles Process Analysts Trainers Testers Solutions Architects SMEs Systems Analysts Technical Writers Users Designers Developers Business Analyst
  • 21.
    • The IIBA and BABOK
    • Certification
    • Melbourne events
    • BABOK Chapter overview
    link link link Link 1 Link 2
  • 22. break
  • 23. WHAT DOES A BA DO?
    • Requirements Management
    • Business Processes
    • People Change Management
    • Project Portfolio Planning
  • 24. Requirements Management
  • 25. MATURITY LEVELS (SEI/IEEE)
    • Chaos
    • Written requirements
    • Organized
    • Structured
    • Integrated
  • 26. BABOK Knowledge areas
    • Defining the role, resources etc
    • BA BOK and contents
      • Planning
      • Elicitation
      • Modelling and Analysis
      • Communication
      • Validation
      • Verification
    • Enterprise analysis
    • Strategy and Structure
    • Business Process Analysis
    • Financial analysis and business cases
    • Consulting skills
    • Project Management
    Level 3?
  • 27. BABOK Knowledge areas
    • Defining the role, resources etc
    • BA BOK and contents
      • Planning
      • Elicitation
      • Modelling and Analysis
      • Communication
      • Validation
      • Verification
    • Enterprise analysis
    • Strategy and structure
    • Business process analysis
    • Financial analysis and business cases
    • Consulting skills
    • Project management
  • 28. Basic Skills
    • Requirements Management
      • Planning
      • Elicitation
      • Communication
      • Verification
      • Validation
    Plan Do Check Act
  • 29. Requirements integrity Level 4? Guy Beauchamp Modern Analyst
  • 30. Requirements integrity Guy Beauchamp Modern Analyst
  • 31. Beautiful Requirements ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Level 5?
  • 32. WHAT DOES A BA DO?
    • Understand the stakeholders
    • Break work down to activity level
      • Who does what, when and why?
    • Get lots of feedback (validation)
    • Manage expectations throughout the process
    should Requirements management
  • 33. Basic Skills
    • Requirements Management
    • Planning
    • Elicitation
    • Communication
    • Verification
    • Validation
  • 34. Requirements Planning
    • Plan before you act
      • Lack of Completeness is the greatest source of requirements problems
      • Incorrect Requirements is also an issue
    • Know the stakeholders, know their business
    • Break your work down to detailed tasks
    • Plans
    • change
  • 35. Requirements Elicitation
    • Desk research
    • Interviews
    • Workshops
    • Models
      • Flow charts (Swim Lanes)
      • Use Cases (with stories)
      • Context Diagrams
      • State Transition
    • Remember
    • Activity Level
    • Method H
  • 36. Requirements Communication
    • Know who needs to know
    • Have enough time to communicate effectively
    • Communicate through the whole lifecycle
    • No surprises, Bad news early
    • Plan your communication
  • 37. Requirements Verification
    • Document Reviews
      • 3 day review cycles don’t always work well
      • Tell people in advance
    • Reviews and Inspections are one of the most effective methods of Requirements QA
    • Walkthrough workshops have strengths and weaknesses
      • S: Group Synergies
      • W: Time and effort
    • Peer Review, Manager Review, Tester Review
    • Look for
    • completeness and accuracy
    • (in that order)
  • 38. Requirements Validation
    • Testing
    • V-Model and Agile both highlight test driven development, beginning with requirements. Waterfall also relies heavily on testing (% of time/effort)
    • UAT
    • BA role in planning, participating, assessing impact of bugs, troubleshooting, workarounds, stakeholders expectations
    • Business Acceptance
    • Contract perspective, Responsibilities of both project and business, Overlapping period
    • Validation is done by people.
    • Take them on the journey.
  • 39. Designer/Programmer Scope/ High level requirements Workshops and Interviews Identify Constraints Revise Scope/Bus Case Identify Stakeholders Document Business Requirements Approve Business Requirements Solution Design Assess Design Requirements Management Change Management BA activities
    • RTM
    • UAT
    • Ready for Service
    • Change Mgt Plan
    • Comms Plan
    • Training
    Business person IT BA Bus BA Systems Analyst Business Analyst Stakeholders IT managers, Infrastructure and network SMEs Stakeholders Business Managers and SMEs PM
  • 40. Business Processes
  • 41. 3 Things
    • Use cases
    • Swim lanes
    • Context diagrams
  • 42. Use Cases Case user Tyner Blain: Use Cases
  • 43. Swim lanes Actor 1 Actor 2 Actor 3 Actor 4 Verb/noun Binary decisions Activity level participants Boundaries Hand-over Begin and end in same lane
  • 44. Context diagrams Information flow External Internal Drilling down Context Boundary
  • 45. … and UML Diagram from Wikipedia
  • 46. … and UML Diagram from Wikipedia UML is for solution design
  • 47. People Change Management
  • 48. Changing people
    • Lewin:
    • Unfreeze > Freeze
    • Maister:
    • The Fat Smoker
    • Prosci:
    • ADKAR
    • Aware
    • Desire
    • Knowledge
    • Ability
    • Reinforce
  • 49. Changing people
    • Aware
    • Desire
    • Knowledge
    • Ability
    • Reinforce
    Stakeholder 1 A D K A R Stakeholder 2 A D K A R Stakeholder 3 A D K A R Stakeholder 4 A D K A R Stakeholder 5 A D K A R
  • 50. Project Portfolio Planning
  • 51. Project Portfolio Management
    • Enterprise Analysis
    • Defining the opportunity
    • Solution Strategies
    • Business Cases
    • Benefits management
    • Enterprise Architecture
    • Information Management
    • Application Planning
    • Business Process
  • 52. break
  • 53. workshop
    • Break into groups
    • Review examples
    • Present feedback
  • 54. workshop
    • What makes good requirements?
    • Quality of documentation
      • Completeness
      • Accuracy
      • Clarity
      • The difference between requirements and design
    • Management through the process
    Reviewing Requirements
  • 55. Resources
    • IIBA
      • New, but growing in influence.
    • BOKS
      • BA BOK
      • PM BOK
      • Others
    • Modern Analyst
      • Articles, Forums, etc
    • Ed Yourdon
      • JESA
    • TynerBlain – Structured analysis
    • BetterProjects
  • 56. Modern Analyst
    • Articles
    • Forums
    • Templates
    • Other resources
  • 57. Ed Yourdon
    • Website
    • Blog
    • Structured Analysis Wiki
    • Free download of his JESA ` book
    • And much more
  • 58. Tyner Blain
    • Software development
    • Requirements management
    • Product management
    • See
      • Structured analysis and Use Cases
    • Scott Sehlhorst, Austin Texas