Presented By Jody Bullen
It’s all about stakeholder communication
The roles of the business analysis in determining the success of software development projects
• 10+ years working in Software Development
• Worked on both technical and business teams
• Variety of projects
• Business Technology Analyst
• Founder and CEO of Yonix
Introduction
• Passionate about well run and successful IT software projects.
• Frustrated with project failure rates.• ‘Calm’ is business software solution, focused on
supporting businesses in the early phases of projects where critical business and technical requirements are developed.
• Used commercially for over 3 years.• Used in Animal Health Board’s VectorNet project
• Q4 2010, Calm 2.0 Software-as-Service (SaaS)
Introduction Yonix
• Common business analysis problems faced by New Zealand organisations developing software,
• How business analysts view themselves versus how other software development roles view business analysts, and
• How to improve collaboration and communication between technical and non-technical stakeholders.
Learning Objectives
• The Standish Group Chaos Report 2009• 24% Unsuccessful • 44% Challenged
• Gartner Group 2008• 75% Failed
• VokeStream 2008 • 38% Successful
• Computerworld 2008• 46% Successful
Project Statistics
Failed Software Projects and poor IT alignment leads to:
• Missed objectives, goals and market opportunities.
• Loss of market share.
• Reduced shareholder returns.
• Damaged reputation and brands.
Impact
• Software errors cost the US economy US$59.5 billion annually.
• Impact to UK companies of re-work costs and abandoned systems upwards of US$75 billion annually.
• In Australia failing, botched, re-scoped and cancelled projects are wasting around A$197,000 per week.
• In 2004, software project failures cost the European Union €142 billion.
Impact
April 2009 we completed an extensive five month market validation and research exercise, which included:
• A Market survey,
• Interviews, and
• Analysis and review of industry research
Research
Problems in the SDLC
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5
Impa
ct
Frequency
Business benefits not clearly communicated or overstated
Insufficient risk management
Lack of management support
Loss of key personnel
Poor communication between stakeholders
Poor governance
Poor project management capability / methodology
Unrealistic schedules or inaccurate estimates of needed resources
Business needs / processes change
Feature / scope creep
Inability to deal with changing requirements
Inaccurate understanding of end-user needs
Poor communication of business requirements and goals
Poor requirements and overall system specification
Poor requirements management
Inability to handle project complexity
Inappropriate architecture and coding language
Poor data migration
Poor quality code
Poor software performance
Poor systems integration
Poor systems testing
Poor testing strategy and business requirements coverage
Use of immature technology
Low
Low High
High
• Unrealistic schedules or inaccurate estimates,
• Poor requirements and overall system specification.
• Feature / scope creep, and
• Inaccurate understanding of end-user needs.
Top Problems in the SDLC
Problems by Phase and Role
Management
Feature / scope creep Unrealistic schedules or inaccurate estimates Poor requirements and overall system specification
Business Analysis
Poor communication between stakeholders Poor governance Feature / scope creep
Development
Unrealistic schedules or inaccurate estimates Feature / scope creep Poor requirements and overall system specification
Testing
Poor requirements and overall system specification Feature / scope creep Unrealistic schedules or inaccurate estimates Business needs / processes change
• 84 Projects
• 35% private, 33% government, 17% public and 15% were charity/non-profit.
• 70% budget greater than $500k.
• 45% had a team size between 6 and 15 people. 39% more than 15 people. 21% over 25 people.
• 50% of project budgets between 500k and $5m, while 19% were $5m or over.
Project Demographics
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5Testing strategy
Testing coverage
Project management
Overall communication
Management support / governance
High level business requirements
Development methodology
Detailed business requirements / functional specification
Business case
Architecture / software performance
Over Budget / Over Schedule Within Budget / On Schedule
Project Key Success Factors
1
2
3
Lowest Rated
HighestRated
• Common theme, problem is not a technical one.
• Management roles experience the most pain, followed by Testers, Developers and finally Business Analysts.
• Most problems originate from the requirements and analysis phases.
• Struggling to capture, manage and communicate what it is that they want to build.
• When is comes to business analysis, just enough, is often not good enough.
Conclusions
• Computing Technology Industry Association (CompTIA) believe that poor communication is the reason most IT projects fail.
• Software Engineering Institute believes that requirements are primary reason for project failure.
• EBG Consulting found that 50% of defects originate from requirements and design.
• The IDC Group’s research found that 70% of project failures can be attributed to poor requirements.
Conclusions
• Organisations with poor business requirement capability will have three times as many project failures as successes*.
• 60% time and budget premium from poor requirements*
• 41.5% of budget consumed by unnecessary or poorly specified requirements*.
Conclusions
*IAG Group
• Strong business analysts can significantly increase the likelihood of project success.
• Organisations are recognising the importance of the role of the Business Analysts.
• As Business Analysts its our responsibility to improve team collaboration and communication.
Conclusions
• Spend more time upfront
• Make sure you understand the scope and the business domain
• Understand and manage your stakeholders
• Create a single source of project requirements and specifications
• Use a software solution that works across and integrates all phases of the Software Development Lifecycle
Recommendations
• Use a software solution created for your role, tasks and functions – Word is poor choice for project teams
• View the requirements exercises as a process rather than a documentation exercise
• Design what businesses need
• Create detailed specifications
• Reuse existing specifications
Recommendations Cont…
• Create baselines and provide complete traceability
• Present requirements to stakeholders in a format that is relevant and understandable to their role
• Help stakeholders visualise and understand the requirements
• Continually clarify, review and prioritise requirements with stakeholders
• Understand the technical and business domains
Recommendations Cont…
% of target
Who Owned Requirements?
Budget Time FunctionalityStakeholder
time
Business 197% 245% 110% 201%
IT 163% 172% 91% 173%
Jointly Owned
143% 159% 104% 163%
Recommendations Cont…
IAG Group : 109 Fortune 500 Projects
• Expect and plan for change
• Implement best practice methodologies, approaches and processes
• Continually optimise business analysis performance
• Influence
Recommendations Cont…
If you would like to:• know more about us,• receive our newsletter, or• learn more about our products.
Please register at:
www.yonix.com
Register with Yonix