Poor business analysis The Culprit of IT project Failure
BASIS Quality Forum Presents “Poor Business Analysis -The Culprit of IT project Failure” The Problem Statement Statistics on Project success rate
Finding the reason : the Culprit The solutions
The stakeholders role
Ecosystem of a successful Project
Published on: Mar 4, 2016
Transcripts - Poor business analysis The Culprit of IT project Failure
BASIS Quality Forum Presents
“Poor Business Analysis
-The Culprit of IT project
Failure” Karim Majumder
(Business Analysis Professional)
• Introduction by M Manjur Mahmud –
Convener BASIS Quality Forum
• The Problem Statement
• Statistics on Project success rate
• Finding the reason : the Culprit
• The solutions
• The stakeholders role
• Ecosystem of a successful Project
Most IT Projects Deliver Little or No Business Value
• Too many failed or challenged projects.
• Significant functionality is developed but never used.
• Projects seldom deliver benefits identified in the
Project Success Rates
Source: Standish Chaos Report, 2009
Project Success Rates
Completed on time and budget,
with all features and functions
Completed, but were over budget,
late, or lacking some originallyspecified features and functions.
Abandoned or cancelled at some
point and thus became a total loss.
Source: Standish Group Chaos Reports
It Gets Worse!!!
The following projects would have been considered successful if
they had delivered all planned scope on-time and on budget using
the CHAOS criteria, but …
• Solution was ultimately not used and withdrawn because of
lack of user adoption
• Solution did not deliver on business case
• Solution did not deliver expected business benefits
• Solution had poor usability, poor performance, or high error
rates requiring rework
Waste: 45% of Functionality is never used
Source: Standish Group Report at XP Conference 2002 by Jim Johnson
Where are the Benefits?
• “78% of Information Systems projects failed to realize even 50%
of the originally identified benefits.” Source: Management Today
• “Only 40% of CFOs find that their IT investments are producing
the returns they expected. ” Source: Gartner, How to Optimize IT Investment Decisions
• “30-40% of systems to support business change deliver no
benefit whatsoever.” Source: OGC, Successful Delivery Toolkit
Most Projects Deliver Little or No Business Value
Poor business analysis is at the root of most project failures.
o Poor requirements
o Poor communications between business and development teams.
o Business cases are mostly used to secure funding and are not used to
manage project outcomes.
o Low business analysis maturity levels for most organizations
Top 3 Reasons for Challenged Projects
1. Lack of User Input
2. Incomplete Requirements
3. Changing Requirements
All of these are symptoms of
Poor Business Analysis
Source: Standish Chaos Report, 2011
The Cost of Poor Business Analysis
1. Companies with poor business analysis capability will have three times as many project
failures as successes.
2. 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 the following:
• Taking over 180% of target time to deliver.
• Consuming in excess of 160% of estimated budget.
• Delivering under 70% of the target required functionality.
1. Companies pay a premium of as much as 60% on time and budget when they use poor
requirements practices on their projects.
2. 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.
3. The vast majority of projects surveyed did not utilize sufficient business analysis skills
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.
Source: Business Analysis Benchmark, IAG Consulting
Deserves true practice of
Effective Business Analysis
Effective Business Analysis Must Address Solution
Planning, Solution Delivery and Benefits Realization
•Develop business case
•Define solution scope
•Identify stakeholder needs
•Monitor project delivery
•Assess and validate solution
•Define transition requirements
•Measure performance based on KPIs
•Optimize as needed
Business Analysis is Much More than Requirements
Organization and Process Change
•Business Process Modeling
•Business Process Improvement
•Stakeholder Analysis and Communications
•Organizational Change Management
Manage Delivery of Value
•Solution Assessment and Validation
•Business Benefits Realization
•Enterprise Portfolio Management
Business Analyst Role:
More About the Business than IT
Business outcome oriented
Business process improvement skills
Organizational change skills
Broad (not deep) IT technical knowledge
Customer management skills
Ability to conceptualize and think
Can articulate a vision
Interpersonal skills, ethics, and integrity
Negotiation and conflict management skills
Analytical and communication skills
A Balanced Scorecard View of Business Value
Delivering a positive ROI for
stakeholders by increasing
revenues, decreasing costs.
Satisfying the needs of
internal and external
Internal Business Process
Learning and Growth
by reducing cycle time,
eliminating waste, avoiding
efficiency, and spending less
time on non-value added
Helping users adopt the
solution resulting in
increased skills, high
employee satisfaction, and
bringing innovation to new
and existing products.
7 Business Analysis Techniques To Deliver More
Change Project Success Focus to Delivering Value
• The ultimate success of a project involves much more than
successfully delivering the solution on time, on budget, and
with all planned scope.
• The main criteria for success is whether the business
benefits as proposed during the initial business case were
Why is a Business Case Needed?
• A well-defined business case is an essential first step
for delivering more value to the business.
• The successful business case allows the decision maker
to confidently choose a course of action. In
the end, it answers the question: “Should we
undertake this initiative?”
• The Business Case should not be used just for funding.
It should be updated and used in the benefits
realization management process.
Requirements: Three Perspectives
• Business Perspective – What business needs must be satisfied,
and what metrics identify that the project is successful?
• Customer/User Perspective – What problems needs to be
solved how will users interact with the solution?
• Technical Perspective – What technology changes are
required to ensure that the project’s objectives will be
Not adequately addressing all three of these perspectives
will result in a suboptimal solution.
5 Types of Requirements
• According to IIBA’s BABOK, there are
five types of requirements.
• The vast majority of requirements
management tool only addresses
• Business stakeholder and transition
requirements cannot be not ignored to
achieve maximum value.
• If your current requirements tool does
not support all 5 types of
requirements, find a different tool!
Good Requirements are Needed to Achieve Value
Maximize business value
Achieve user adoption and minimize post-implementation productivity
Shorten delivery cycle and eliminate waste through less rework and
Minimize post-implementation productivity drop
The Case for Good Requirements
Quality and Cost Savings
As much as a 200:1 cost savings
results from finding errors in the
requirements stage versus finding
errors in the maintenance stage of
the software lifecycle.
56% of all bugs can be traced to
errors made during the
How can better Collaboration between
the Solution Team and Stakeholders Help?
• Lack of user input is the #1 cause of project failures.
• Joint ownership of requirements results in lower costs and
higher quality solutions.
• Organization change goes more smoothly when users and
other stakeholders are involved through the entire lifecycle.
• Effective business analysis is the key for better collaboration
between stakeholders and developers.
Joint Responsibility for Requirements
Makes a Big Difference
Who owns Primary
Responsibility for Requirements
% of Target
Source IAG Business Analysis Benchmark, 2008
% of Target
% of Target
Engage your Stakeholders!!!
• Learn background and purpose of project
• Document and express needs
• Document business rules
• Gather relevant background materials
• Review and validate requirements
• Participate in requirement prioritization
• Review design documents
• Participate in software and prototype demonstrations
• Participate in retrospectives and capturing lessons learned
• Provide additional information for unclear requirements
• Build test scenarios and test cases for user acceptance testing
• Perform user acceptance tests
• Approve changes to requirement specifications
• Define transition requirements
• Help prepare the organization for change
What is Solution Scope?
Project Scope includes the
work needed to create a
product or deliver a service or
result. Project Scope defines
the work required to create
and deploy the product. The
project scope statement is
prepared by the project
The Solution Scope describes
the characteristics, features,
or functions of the product or
service to be built. Solution
scope is all about the solution
to be implemented: how will
it look, how will it function,
and other characteristics, etc.
A business analyst prepares
the product or solution scope.
Why is Solution Scope important?
• Solution scope consists of high-level Features of the proposed solution.
• Features should be prioritized based on business value.
• Features are used to capture stakeholder needs and organize requirements.
• Using features significantly reduces solution scope creep.
• Using features is highly-beneficial for both Agile and Waterfall
development, as well as implementation of Commercial Packages.
• Managing Features = Managing Business Value
Carefully defined solution scope is key to
prevent scope creep, deliver value, and
serve as a basis for gathering user needs and
developing requirement specifications.
Two Types of Value for the User
Value is helping the user get a job done faster, more
conveniently, and less expensively than before.
Identify and Understand Your Users
• Identify all your various types of users
• Prepare a persona for each user type
• The personas should contain:
Systems and Services Used
• Review the persona with real users to
ensure that it adequately represents
What are the Key Reasons Expected Business
Benefits are not Achieved?
• The business problem was poorly defined giving rise to a
flawed business case.
• The business case was poorly developed and established an
incorrect or unrealistic expectation.
• Requirements for the solution were inaccurate,
incomplete, or were poorly defined.
• Delivery of the solution was poorly executed.
• The technical solution was fundamentally flawed.
• The delivered solution was not effectively adopted by the
• The business changed significantly between inception and
Business Benefits Received
Benefits Realization Management
• Benefits realization starts with defining a realistic
• Benefits do not just happen.
• Benefits realization has its own lifecycle.
• Benefits rarely happen according to plan.
• Benefits realization is a continuous process of envisioning
results, implementing, checking intermediate results, and
dynamically adjusting the path leading from investments
to business results.
• Benefits realization is a process that can and must be
managed, just like any other business process.
Benefits Realization Management
Benefits Realization Management
1. Validate and Re-Validate the Business Case
2. Create Benefit Realization Accountability
3. Create a Benefit Realization Management Plan
4. Measure and Evaluate Benefits Realization at Key Points
5. Identify Problems and Document Solutions
6. Continually Optimize Processes, Organization, and
Technology to Achieve Benefits
7. Create a Benefits Dashboard
To what extent does your organization perform
benefits realization management ?
• Done for every project
• Occasionally for high profile projects
Portfolio Management is a corporate, strategic level process for
coordinating successful delivery across an organization's entire set of
programs and projects.
•To obtain the highest return from your available resources given
an acceptable level of risk.
•To ensure balance – in terms of investment types and organizational
•To ensure funding allocations reflect business priorities.
•To reallocate funds when performance deteriorates and/or priorities
•To manage dependencies, constraints and minimize double counting of
•To manage Portfolio-level risk and uncertainty.
•To provide transparent reporting on performance from strategic
intent to benefits realization.
Portfolio Management is More Than Just Projects
• Project Portfolio Management (PPM) is often not understood or
embraced and is often managed quite haphazardly.
• PPM is often has different tools and processes and
organizations to manage projects, processes, applications, and
• Enterprise portfolio management involves addressing strategy,
people, process, and technology.
Managing for Value
Are the benefits worth the effort and risk?
Do the projects contribute to the strategic
goals of the company?
Do we have the resources and skills to
complete the project?
Are we willing to invest something new and
will we gain a competitive advantage?
Business Value Lifecycle
“Doing the Right Projects”
that are no longer
“Doing Projects Right”
Enterprise Portfolio Management
“Harvesting the Benefits”
The Culprit is traced by the Team
So resist it for Project Success
Next Generation Business Analysis:
IIBA’s Business Analysis Framework
Version 3 is coming
There are big changes coming in the
role of business analysis. The focus will
be much more on understanding
stakeholders and their needs,
analyzing change, and delivering value.
Understanding how to use these
components and the relationships
between them results in understanding
your stakeholders, what they value, and
how to better deliver that value.