A Business Analyst's Perspective: Seven Reasons for

Project Failure
http://www.batimes.com/articles/a-business-analyst-s-perspective-seven-
reasons-for-project-failure.html
Written by Lavinia Mihaela Dinca, Monday, 04 April 2016 08:20

Statistics show that the real figures regarding project success are not at all
encouraging. Only 30% of projects are considered successful; the others are
challenged oroutright failures.
How does one determine if a project is a success? From a project management
perspective the answer is simple, the Holy Trinity - time, budget, and quality.
Reality indicates that things are more complicated. A good example is the
construction of Sydney Opera House. From a project management perspective,
this was one of the biggest planning disasters ever made. Initially budgeted at
$7 million, it ended up in costing $100 million.

On the other hand, when you think of Sydney, the Opera House is an iconic
building, immediately recognizable, placed on most tourist advertising leaflets,
and certainly a complete architectural success.
The factors of success for IT projects are the same Holy Trinity, with a twist:
quality should be defined from a business analysis perspective. Specifically, the
delivered project must be compliant with both stakeholders and current
business requirements. The last part is mostly overlooked because sometimes
the stakeholders requirements don't conform with reality.
Based on my experience as both business analyst and project manager, these
are my top seven reasons for project failure from a business analysis
perspective:
#1: Business cases are used ONLY to justify the need for the
project
I've met many project managers and business analysts who don't understand
the importance of the initial project pitch, the justification of why the project is
needed. All these people see this as a necessary evil to start the project, and
they treat it as such. The practice of the pitch translates to creating business
cases that make sense on paper to justify the money and project need.
Sometimes it's worse, the justification and business cases are valid, but the
analysts fail to see the importance, and they don't incorporate the
requirements in the project. This is why projects fail to deliver any business
value, even if they are considered successful.
Related Article: How Business Analysts Can Help Failed Projects
Succeed
Rule of thumb: all business cases must be covered by requirements.

#2: Missing stakeholders

This reason sounds like a rookie mistake and yet is so frequent I've stopped
counting. Stakeholder analysis is usually disregarded by analysts because
theory says the project manager should perform this task. Yes and no. It should
be a combined effort for both project manager and business analyst, and more
importantly, it should be revised.
Revision should also be the responsibility of the business analyst because they
are in the unique position of noticing when stakeholders are missing during the
analysis phase. Missing stakeholders translate in only one thing: missing
requirements.
Rule of thumb: revise stakeholder list frequently during the project lifecycle.

#3: No user input

This reason is closely related to no #2, and I've debated if I should list it
separately. Identifying a stakeholder doesn't mean getting the user input. I'm
going to argue this point with an example: a bank notified us, the end users,
about their improvement of the internet banking system. No one believed them
because they kept saying the same thing for two years.
The bank's officials knew we were the stakeholders in the project and also the
final users. Not once did they tried to see what our problems were, or verify
their requirements with us.
The new internet banking system was a complete failure since end users had
different expectations of what they wanted. This type of mistake often happens
to businesses, and sometimes it's even worse, when analysts end up gathering
requirements from the CFO but never talk to Jenny in Accounts Payable, who is
doing something only she knows.epartment managers don't know everything,
especially at the execution level.
Rule of thumb: talk with the stakeholders at all levels.

#4: Poor requirements and communication

Business analysis means mostly paperwork, not only client interactions. The
way a requirement is described and detailed is very important. It has happened
to all of us to know a topic very well, but when we try describing it to others,
we fail miserably, mostly because we assume people should know some basic
things.
The top reasons for incomplete requirements are a poor description, poor
communication between business analysis and development team, and missing
details. By missing I don't mean they haven't been collected (covered by points
#1), they were, but the analysts failed to fill in the matrix regarding which
business case is covered by which requirement.
Rule of thumb: assume nothing, describe and check everything!

#5: Requirements keep changing

There are many reasons why this can happen: the company is not mature
enough and doesn't have an idea of their own procedures or what they want,
the business environment changes rapidly and requirements can keep up with
it, or the legislation is missing or unclear.
From experience the following approaches help with this problem: detail the
project scope accordingly, ask for a decision manager regarding any changes,
apply penalties for changes, sign off on requirements more often, and choose
the appropriate methodology, such as Agile.
Rule of thumb: less is more!

#6: Requirements not up to date with business environment

Some businesses or CEOs live in their own bubble different than the rest of the
world. The business might still be successful due to inertia; they were in the
business a long time and their name still has value. By the end of the project,
the situation can change drastically and the project might be obsolete because
the requirements don't conform to the business reality.
Rule of thumb: check your information from third party sources.

#7: Project is a complete success, but no one is using it

The project is finished, all the requirements are met, but the application is not
used at all. Most people blame the client for not wanting to change. No, the
project failed to capture the real needs. Solve the needs/problems your client is
facing and your project will be a success.
Rule of thumb: make sure the project is solving a need/problem.
This is my short list and I'm sure there are other several factors for business
analysis failure. What do you think about this topic? What items would you add
or remove from the list?

Tagged under
Requirements
Facilitation

Lavinia Mihaela Dinca

Lavinia Mihaela Dinca is currently a Security Researcher, who has vast
experience in Project management, Business Analysis and Security. Lavinia's
experience resides from various projects he coordinated from the technical
leader perspective. In her efforts to make the technology safer for common
people, she started an online security platform for beginners. You can visit at:
www.learning-adventure.com

Related items
Is Your Project Manager-Business Analyst Collaboration a Pressure
Cooker?
 Requirements Inspiration From a Surprising Source
The Business Analyst's Role in Project Closeout
Want Faster Requirements? Build Them Like a Snowman!
6 High-Value UX Techniques to Boost Your BA Role

More in this category:

Five Easy Ways to Make the BABOK an Irresistible Read Requirements
Inspiration From a Surprising Source