A Business Analyst’s Perspective: 7 Reasons for Project Failure

Written by Lavinia Mihaela Dinca on April 4, 2016. Posted in Articles.

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.

{module ad 300×100 Large mobile}

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.

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?