The document discusses the role of business analysts and requirements management. It covers topics like why projects fail, the cost of poor requirements, business analysis skills, requirements practices, and techniques like use cases and swim lanes. The goal is to explain the business analyst role and how to effectively manage requirements to improve project success.

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