Please login or join to subscribe to this thread
Interesting subject Anand. The list could be endless but I would add: Poor Stake Holder Management, Poor Risk Management.
I second Rami, interesting subject indeed.
I would remove "Other unexplained reasons", as PM or an Organization doing post-mortem, there can never be unexplained reasons.
I would add: Lack of Stakeholder Management, Incorrect Business Goals/Objectives, Lack of Human Resource Management.
I would add: Unclear or lack of the requirements, Underestimation of the risks.
Dedicate the most time and resources on the review and requirements analysis is a good corrective action for the Unclear or lack of the requirements causes.
I am not sure if your company has adopted the Agile methodology for your software development, but most of the items in your list can be improved through the use of the agile way of working and the practices that are used to support it. Without going into a lot of detail on Agile, it might suffice to add it to your list as another reason projects fail. My suggestion would be: Continuation of Waterfall development vs Implementation of Agile Methodology and Practices.
Good list, Anand. I would expand or edit the item #9: Lack of user education and adoption to read "Limited or no end user involvement in the development process". It is critical to include users in the design, development and testing of the product - not only to ensure the "desired" capabilities are being built, but those involved become champions of the product or system being rolled out.
Lack/ improper of Business Case/ Need
Lack of decent portfolio management process - resulting in selection of wrong projects
No Lack of change control/ risk management and other PM processes
No Benefit realization process
Great feedback already.... An additional idea that I'll throw in is related to executive involvement and support. Whether it's the formal sponsor or just key executive stakeholders, their buy-in and involvement is critical. That doesn't mean they will always give us what we want (even a timely No can be helpful for a project!). But if they don't have your back or if they're dragging their feet in making decisions, it's the kiss of death for a project.
What if you don't have it? How do you develop it?
Here's a brief video that unpacks this idea: https://vimeo.com/13808584.
There is something that is critical and is not in the list: how do you meassure if a project have failed or not? Wich is your meassure of project sucess? When you search about that (lot of debates in sites like linkedin) you will see that most of the projects that have been considered failled do not fail in reality.
Please login or join to reply