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

?Questions

Jody BullenJody.bullen@yonix.com