Business Analyst Training

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    5 Favorites & 2 Groups

    Business Analyst Training - Presentation 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
      • The IIBA and BABOK
      • Certification
      • Melbourne events
      • BABOK Chapter overview
      link link link Link 1 Link 2
    21. break
    22. WHAT DOES A BA DO?
      • Requirements Management
      • Business Processes
      • People Change Management
      • Project Portfolio Planning
    23. Requirements Management
    24. MATURITY LEVELS (SEI/IEEE)
      • Chaos
      • Written requirements
      • Organized
      • Structured
      • Integrated
    25. 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?
    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
    27. Basic Skills
      • Requirements Management
        • Planning
        • Elicitation
        • Communication
        • Verification
        • Validation
      Plan Do Check Act
    28. Requirements integrity Level 4? Guy Beauchamp Modern Analyst
    29. Requirements integrity Guy Beauchamp Modern Analyst
    30. Beautiful Requirements ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Level 5?
    31. 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
    32. Basic Skills
      • Requirements Management
      • Planning
      • Elicitation
      • Communication
      • Verification
      • Validation
    33. 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
    34. Requirements Elicitation
      • Desk research
      • Interviews
      • Workshops
      • Models
        • Flow charts (Swim Lanes)
        • Use Cases (with stories)
        • Context Diagrams
        • State Transition
      • Remember
      • Activity Level
      • Method H
    35. 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
    36. 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)
    37. 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.
    38. 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
    39. Business Processes
    40. 3 Things
      • Use cases
      • Swim lanes
      • Context diagrams
    41. Use Cases Case user Tyner Blain: Use Cases
    42. 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
    43. Context diagrams Information flow External Internal Drilling down Context Boundary
    44. … and UML Diagram from Wikipedia
    45. … and UML Diagram from Wikipedia UML is for solution design
    46. People Change Management
    47. Changing people
      • Lewin:
      • Unfreeze > Freeze
      • Maister:
      • The Fat Smoker
      • Prosci:
      • ADKAR
      • Aware
      • Desire
      • Knowledge
      • Ability
      • Reinforce
    48. 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
    49. Project Portfolio Planning
    50. Project Portfolio Management
      • Enterprise Analysis
      • Defining the opportunity
      • Solution Strategies
      • Business Cases
      • Benefits management
      • Enterprise Architecture
      • Information Management
      • Application Planning
      • Business Process
    51. break
    52. workshop
      • Break into groups
      • Review examples
      • Present feedback
    53. workshop
      • What makes good requirements?
      • Quality of documentation
        • Completeness
        • Accuracy
        • Clarity
        • The difference between requirements and design
      • Management through the process
      Reviewing Requirements
    54. 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
    55. Modern Analyst
      • Articles
      • Forums
      • Templates
      • Other resources
    56. Ed Yourdon
      • Website
      • Blog
      • Structured Analysis Wiki
      • Free download of his JESA ` book
      • And much more
    57. Tyner Blain
      • Software development
      • Requirements management
      • Product management
      • See
        • Structured analysis and Use Cases
      • Scott Sehlhorst, Austin Texas

    + Craig BrownCraig Brown, 2 years ago

    custom

    4139 views, 5 favs, 5 embeds more stats

    A presentation pack I used when training business a more

    More Info

    CC Attribution License

    Go to text version
    • Total Views 4139
      • 4010 on SlideShare
      • 129 from embeds
    • Comments 0
    • Favorites 5
    • Downloads 730
    Most viewed embeds
    • 114 views on http://www.betterprojects.net
    • 11 views on http://www.brijj.com
    • 2 views on http://www.globalprojectmanagement.org
    • 1 views on http://static.slideshare.net
    • 1 views on http://www.nueronic.com

    more

    All embeds
    • 114 views on http://www.betterprojects.net
    • 11 views on http://www.brijj.com
    • 2 views on http://www.globalprojectmanagement.org
    • 1 views on http://static.slideshare.net
    • 1 views on http://www.nueronic.com

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as innappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel

    Categories