The #1 Reason Why Software Projects Fail, and How To Make Them Succeed

The #1 Reason Why Software Projects Fail, and How To Make Them Succeed

Data says only 30% of the software projects are done successfully, and the rest are either failed or in crisis in terms of time and budget. How to make sure you are not in the rest of 70%???

I have over 14 years of project management experience primarily for the US market. While it may look unrealistic, but we had over 80% of on-time project delivery success, whereas the statistics say it's 30% worldwide. So we would like to share our thoughts on this incase it benefits you, and would like to know your story as well.?


Problem:?

Now, what is the recipe? How can we make sure our projects are finished on time and on a budget? How to make sure it is not failed or delayed???

Yes, there are several reasons for which a project fails, but to me, the most important reason is the gap between the stakeholders on what they need and how. In other words, unclear business requirements. While people say many reasons for a project failure, but many of those reasons are by product of ‘unclear business requirements’. If the scope is not well defined by the client and service provider, whatever we do, eventually it will fail or will take more time and/or budget.?


Solution:

Now, what is the solution? How can we make sure everyone is on the same page regarding what is required to deliver??

Well, different companies will have their own process. That is fine, but the core essence should be the same. I am detailing a process here. It may not need to be followed exactly, but it may help us to understand what is required and why. Once we understand what really matters, we might be able to solve it in a number of ways.?

  1. The service provider company (SP) or software development company should request the client to send the initial requirements over an email. That may not have too many details, but still, the client should send the requirements via mail or in any other written format. As an alternative, this can be done via a meeting (in person or virtual) as well. In that case, meetings need to be recorded.?
  2. The service provider company (SP) will review the requirements that they received from the client, will discuss internally, will do research as needed, and will generate questions on those.?
  3. This is the first 30% of total requirements gathering. That leaves us with the rest of the 70%.?
  4. At this stage, again needs to sit with the client possibly in person, or virtually. In this meeting, the client will clarify their requirements further, and the service provider company will ask questions and will make it further clear.?
  5. Another 30% is done. 60% of the task is completed! 40% of works are left for us to reach the milestone!
  6. The service provider company will do more internal discussions and research, will build prototypes and diagrams via any tool or even with white papers. These exercises will help the service provider company to dig more, go in depth, get more clarification, and eventually raise more questions and concerns.?
  7. Now that another 10% is done, that means 70% of our total work is done! Let's dive in to complete the rest 30%!
  8. After the prototypes and visuals are ready, there will be another meeting with the client. At this stage, after looking at the visuals, the client can have more queries, can raise more concerns, but most importantly the client can visualize what is coming to them. This will help both teams to think alike.?
  9. Consider another 20% is done. So total 90% is done & we are close to finish line with 10% of pending work.
  10. The remaining 10% will be always unclear whatever you do, you need to plan additional time and budget on project estimation and cost.?

A number of meetings with clients before boarding a project is the best way to successfully finish a software project.?


Bonus:

One more solution. Yes, apart from clarifying the requirements properly, there is one more important thing to successfully finish a project. That is ongoing client communications and interim deliveries to clients from day?


Feedback??

In your opinion, what is the core reason behind a project failure? Please share your thoughts and experiences.?



Md.Hamidur Rahman PMP? MBA

Sr Manager, Business Development | Project Management | B2B & B2C Sales | Partnership | Key Account Mgt | Operation Mgt | Digital Product & Soft Dev | Customer Experience & Service Professional

2 年

Apart from requirement specification finalization, there are few basic things that are not followed in structured ways; 1. the methodology of end to end project management integration plan and onboard clients in the process 2, know how (technical) specially, in the client side, vice versa, 3, Leadership of PM to lead the projects 4.Importance of the project, professionalism and responsibility, to know, why 5, communication and stakeholders engagement Monjurul Alam Mamun, Nice write up thanks for sharing

Abdur Rakib

??COO @ Programming Hero & Phitron.io ???? | empowering students to code_ career in Tech ??| 4k+ global job placements | 10k/yr placements by 2028 ??

2 年

Great post, Mamun Bhai! ?? I agree with your approach to requirement gathering and communication. ?? Key to successful software projects. Your process for requirement gathering is comprehensive and well thought out. ?? Interim deliveries is a great bonus tip. ?? Unclear business requirements a major factor for project failure. ?? Thanks for sharing your knowledge and experience. ????

Hasan Jaman

Cloud Architect ● Java ● AWS ● Kubernetes ● DevOps

2 年

So far I found this requirement gap many times in many places. It has a huge development cost. A smart BA can/should mitigate such issue but don't know why always found reverse. Requirements should be easy to understand, concise and wisely written as well as delivered. I prefer dev people (Team Lead/PM) should play the BA role.

Ariful Islam

Managing Director @ Generation-Next IT Solution Ltd. | ERP Specialist

2 年

Well said bhai

要查看或添加评论,请登录

Monjurul Alam Mamun的更多文章

社区洞察