![[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (12)
Similar to Yonix presents: It’s all about stakeholder communication
Similar to Yonix presents: It’s all about stakeholder communication (20)
Recently uploaded
Recently uploaded (20)
Yonix presents: It’s all about stakeholder communication
- 1. It’s all about stakeholder communication The roles of the business analysis in determining the success of software development projects Presented By Jody Bullen
- 3. Worked on both technical and business teams
- 6. Founder and CEO of YonixIntroduction
- 8. Frustrated with project failure rates.
- 9. ‘Calm’ is business software solution, focused on supporting businesses in the early phases of projects where critical business and technical requirements are developed.
- 10. Used commercially for over 3 years.
- 11. Used in Animal Health Board’s VectorNet project
- 12. Q4 2010, Calm 2.0 Software-as-Service (SaaS)Introduction Yonix
- 14. How business analysts view themselves versus how other software development roles view business analysts, and
- 15. How to improve collaboration and communication between technical and non-technical stakeholders.Learning Objectives
- 17. 24% Unsuccessful
- 18. 44% Challenged
- 20. 75% Failed
- 21. VokeStream2008
- 22. 38% Successful
- 26. Loss of market share.
- 28. Damaged reputation and brands.Impact
- 30. Impact to UK companies of re-work costs and abandoned systems upwards of US$75 billion annually.
- 31. In Australia failing, botched, re-scoped and cancelled projects are wasting around A$197,000 per week.
- 32. In 2004, software project failures cost the European Union €142 billion.Impact
- 34. Interviews, and
- 35. Analysis and review of industry researchResearch
- 36. Problems in the SDLC
- 38. Poor requirements and overall system specification.
- 39. Feature / scope creep, and
- 40. Inaccurate understanding of end-user needs.Top Problems in the SDLC
- 41. Problems by Phase and Role
- 43. 35% private, 33% government, 17% public and 15% were charity/non-profit.
- 44. 70% budget greater than $500k.
- 45. 45% had a team size between 6 and 15 people. 39% more than 15 people. 21% over 25 people.
- 46. 50% of project budgets between 500k and $5m, while 19% were $5m or over.Project Demographics
- 47. Project Key Success Factors Highest Rated 2 3 Lowest Rated 1
- 49. Management roles experience the most pain, followed by Testers, Developers and finally Business Analysts.
- 50. Most problems originate from the requirements and analysis phases.
- 51. Struggling to capture, manage and communicate what it is that they want to build.
- 52. When is comes to business analysis, just enough, is often not good enough.Conclusions
- 54. Software Engineering Institute believes that requirements are primary reason for project failure.
- 55. EBG Consulting found that 50% of defects originate from requirements and design.
- 56. The IDC Group’s research found that 70% of project failures can be attributed to poor requirements.Conclusions
- 58. 60% time and budget premium from poor requirements*
- 59. 41.5% of budget consumed by unnecessary or poorly specified requirements*.Conclusions *IAG Group
- 61. Organisations are recognising the importance of the role of the Business Analysts.
- 62. As Business Analysts its our responsibility to improve team collaboration and communication.Conclusions
- 64. Make sure you understand the scope and the business domain
- 65. Understand and manage your stakeholders
- 66. Create a single source of project requirements and specifications
- 67. Use a software solution that works across and integrates all phases of the Software Development LifecycleRecommendations
- 69. View the requirements exercises as a process rather than a documentation exercise
- 70. Design what businesses need
- 74. Present requirements to stakeholders in a format that is relevant and understandable to their role
- 75. Help stakeholders visualise and understand the requirements
- 76. Continually clarify, review and prioritise requirements with stakeholders
- 77. Understand the technical and business domainsRecommendations Cont…
- 78. Recommendations Cont… IAG Group : 109 Fortune 500 Projects
- 80. Implement best practice methodologies, approaches and processes
- 81. Continually optimise business analysis performance
- 84. receive our newsletter, or
- 85. learn more about our products.Please register at: www.yonix.com Register with Yonix
- 86. ? Questions Jody Bullen Jody.bullen@yonix.com
Editor's Notes
- It’s all about stakeholder communication: The role of business analysis in determining the success of software development projects. As business analysts, it's our job to encourage collaboration and communication between technical and non-technical stakeholders. We represent the requirements of business stakeholders and translate this to our technical team members, and vice versa. We are the in essence, conduits of information. A large majority of project failures are attributed to the requirements and analysis phases. Are we really doing what is required to meet business and stakeholder expectations? During this session, Jody Bullen, CEO of Yonix will present some findings from a recent New Zealand survey, highlighting common business analysis problems faced in software development. Learning Objectives:Common business analysis problems faced by New Zealand organisations developing softwareHow business analysts view themselves versus how other software development roles view business analystsHow to improve collaboration and communication between technical and non-technical stakeholders
- Project success is not the gold pot at the end of the rainbow. It is achievable and for the large part project failures are avoidable. So why do some organisations experience continued successes and others anything in between.
- The financial implications of such failure rates are substantial. No-one is certain of the real cost of failed software projects, but it’s big. Software errors cost the US economy US$59.5 billion annually. (National Institute of Standards and Technology (NIST)Research from British Computer Society suggests the Impact is upwards of US$75 billion a year in re-work costs and abandoned systems.
- Market survey84 Individual Responses86% from New Zealand, remainder from Australia and EuropeResponses from non-management roles reflect a typical software development project team. InterviewsCEOs, Business Decision Makers, Project Managers, Business Analysts, Architects, Software Development Managers, and Testers. SeeAnalysis and review of industry publicationsPublications, reports, reviews, articles and statistics from, but not limited to Forrester Research, Gartner, Standish Group, IDC Group, IAG Group and vokeStream.
- The top four ‘pains’ faced during the software development life-cycle, based on the frequency and their relative impact are
- In this section respondents were asked to rate on a scale of 1 – 5, where 1 = Poor and 5 = Excellent a number of key project areas for their selected project. Figure shows differences between those projects that were delivered within budget and on schedule and those projects that were delivered over budget and over schedule.
- We are the in essence, keepers of information.
- Do more work upfront Spend more time eliciting, defining and specifyingDefects costs upwards of 100x times more to fix later in the Lifecycle Upfront work is rewarded 60% time and budget premium from poor requirements41.5% of software budget will be consumed by unnecessary or poorly specified requirements Average organisations spend 45% of time on requirements (27%) and on design (18%) Immature organisations effort upfront is increased.Make sure you understand the scope and the business domain Scope document from PM If there isn’t one define it and get it signed off Understand and map the business processesUnderstand and manage your stakeholders Know who you need to speak too Formalise a plan Create working groups / stakeholder groups Keep track of all communications Most people will not turn down a free coffee This includes internal project stakeholders such as developers and testersCreate a single source of project knowledge People need to know where to find information. Retains IP
- Use a software solution created for your role, tasks and functionsWord advantagesfamiliar environment to usersno learning curve or lead time ideal distribution format. No additional investment unwise choice for project teamssignificant disadvantages, which are key contributors to today’s project failure rates. very manuallabour intensive and cumbersome processmanaging relationships, change history and providing information and key metrics reporting from various documents. Does not support concurrent users. large un-manageable documents lack traceability, are not easily analysed, reviewed, shared or amended. For these reasons, requirements are often missed, incorrect, out of date and incorrectly signed off or approved by stakeholders.View the Requirements exercises as a process rather than a documentation exercise Be an analysts not a document creator, manager and publisher Review Clarify Expand RelateDesign what businesses needThis is not always what they will ask forOften the true need is hiddenIt is always difficult for people to think outside of what they are use to and knowUse observationUnderstand what could be done better.Create detailed specificationsWe mean, Interface designs, Task/Role based property specifications (i.e. who can see what, how does the screen look for this person), validation rules and messages, field types, mappings to class models and ERDCreating detailed specifications forces you to think about the design and how the requirements can be met functionally.This again is a process, rather than a documentation exercise but from experience will uncover functional holesWhile we appreciate that systems can with the right methodology be built with without specifications there are problems down the line such as loss of IP and knowledgeRetains IP, you don’t need to look at the code to understand how the system works and why it was designed that way.You would not build a building with out architectural blueprintsReuse existing specificationsFirst of there needs to be some……see aboveLeverage previous effortsSpeeds up understanding, time to marketKeeps consistency
- Create baselines and provide complete traceability43% of respondents actually created a baseline of requirements, vokeStream Creating a baseline in a word document is not sufficient, its very difficult to track changes. Maybe possible between documents but what about from version 1.0 to 9.0?Can you easily identity changes to requirements? If you cannot measure this you cannot manage it. Traceability: Why a requirement was created, what was the need, what business objective is it meeting? who said? Who validated/approved it? Where all the necessary parties consulted? When was it specified, developed and implemented?Present requirements to stakeholders in a format that is relevant and understandable to their role.Each phase and role speaks a different language and as such business requirements are often lost translationNon-technical people do not understand use cases diagrams, class models or ERD Models.BusinessRequirements often too high-level for technical and testing teamsRight content Consistent formatThe format must meet the requirements for 4 very different user needs:Business professionalManagementBusiness AnalystDeveloper/Testers (Technical)Continually clarify existing requirementsBusiness needs and priorities changeHelp stakeholders visualise and understand the requirements Reviewed design with business stakeholders Workshops, interviews. Help interface designs, Created Interface/Web page designs, Story Boards, Prototypes
- Understand the technical and business domainsIf you don’t up skill or make sure you have the skills in your team.BA’s should be able to understand a Class Model, Entity Relationship Diagram, Key OO concepts, Usability, Limitations of technologies
- Expect and plan for changeChange is inevitableImportant to manage changeQuickly understand the impact – Resources, business case, cost benefitCorrectly communicate change / get approvalA project runs over schedule a day at a time, a change is a changeImplement best practice methodologies, approaches and processes IIBA Volere (Voh-lair-ray) the Italian verb to want, or to wish.To achieve consistent success you need consistent, repeatable and clear process The process is a discipline that requires commitment at the highest level. Training
- We are passionate about what we do