Any project that you plan to execute will have many elements to be controlled – budget, time, quality, people, stakeholders, requirements, scope-creep, and even a few “first-time” challenges such as implementing a BYOD work culture. No wonder the project managers are bound to make mistakes in their projects, leading to its failure. And that’s probably why the rate of project failure is still very high.
Such a mire of elements can create a push and pull effect and develop problems in software development at various stages. These problems will naturally be the cause of project failures. Although as an astute project manager you can still deal with a failing project, but then sometimes project failure may just be inevitable. Instead of playing the blame game, it will help if you pick out key lessons from a project failure. So, what can we learn from project failures?
Lesson 1: Understand your stakeholders’ concerns
On Monday last week, I posted a piece, How to Deal With Politics in Project Management. Here I have highlighted that not understanding your stakeholders’ concerns properly, may lead you to think that the politics is acting against the successful delivery of your project.
While the politics per se might be present, it may help if you take some time to understand the root cause of the politics or the obstacles, so to speak. You will see that it helps a lot.
Lesson 2: Communicate often
To get anything done, proper communication is the key. Take any example of any project failure and you will surely find during the post mortem, that somewhere there was a lack of proper, clear and timely communication. Remember the Titanic disaster of 1912?
But it is not about just communicating often. The communication has to be precise, concise and informative, without wasting anyone’s time, and at the same time keeping everyone concerned with the project on the same page.
Lesson 3: Document project failure
It is quite possible that the type of project that you are working at present already has a precursor. It is good to refer to the documents of similar projects and understand beforehand the reasons of its failure (or success). This will ensure that you incorporate contingency risk planning in your project plan.
So, it’s a good lesson to know that even if your project failed, it should be documented so that in future it can act as a point of reference.
On the positive side, you see, it depends a lot on what you mean by a project failure. A project that saw the doom and never got shipped at all is a failure. On the other extreme, a project can be classified as “failed” even if it did deliver but not the exact business value that the stakeholders wanted. (After all, an unhappy customer is a mark of failure!).
But no matter which way you look at it, it will still have many reasons to analyze that are worthy of documenting. A good project documenting policy will serve as the Holy Grail to ensure a lower failure rate in your company.
Thank you for spending time here!
Co-Founder at EZMove