From ‘Project Immortality’ to ‘Project Moksha’

Projects are not living organisms, but they inevitably assume a life of their own. They are born from an idea, they have a lifecycle, they consume resources, they grow, they facilitate development of a social structure around it, they have a hearbeat and a rhythm…and they eventually die. While a natural death looks like the logical end for a project – for it marks successful accomplishment of the initially set objectives – many projects die an unnatural death, only to be reborn as yet another maintenance project, or a feature enhancement on a previously unfinished work! I have seen enough projects where planning for a next service pack would start even before code freeze of the mainline release! How can we ensure that “immortal” projects achieve “moksha” from this non-stop nonsensical cycle of life, pseudo-death and rebirth?

Most projects die of unnatural death because we overpromise the project one way or the other – it might be undeliverable deliverables, or  impossible deadlines, or unreasonable cost, at unachievable quality, or any other deeply questionable and highly unattainable outcome of the project. In a way, there is one single reason: mismatch between project’s ‘supply’ (e.g., time, money, resources, etc.) and project’s ‘demand’ (e.g., deadline, scope, quality, budget targets, etc.), with the former heavily outweighed by the often unreasonably-sounding latter. So, we often blame the this mismatch and the result is an immortal project!

So, why do we still overpromise ? Is is that we pursue the glory of an immortal project, often confusing it with immortality of a project’s creation, or project’s creator? Or, we are too naive or timid to let the project sponsor and the customers know of the reality? Or, we deliberately create such situations and thrive on the resulting chaos because a fighting (even if losing) project looks good on our resume than a rock-solid project delivered without its fair share of trials and tribulations?

It turns out there are really only two main reasons: intentional and improper analysis.


Quite often, stating the cold facts and bitter truth might mean that the project simply won’t take-off. Try telling a customer that you can’t build a compiler in three months and see him taking the business to your competitor. So, a way to get started is to sugercoat the issues and somehow get it started. Once the game is on, the deadlines and budgets keep inflating because aborting the project midway might mean loss of face (or office, or both) for the decision-makers (who perhaps have a hefty year-end bonus tied to that project). So, after some 5x budget overrun and 4x of original schedule, the project finally ‘delivers’ something that might have never happened as per the original business case. Is it a right thing to do? I don’t know, but it surely is a great way to get things started, when otherwise they won’t :). Virtually all megaprojects happen like this. You tell the project sponsor (Government, in most cases) that developing this world-class fighter jet will cost $5 Billion and the file will go in the deep freezer. But tell that in $1Billion, you will develop core technologies and do a pilot demonstration. Then somewhere near the project complete date, you come out with list of Murphys, list of new innovations, blah, blah, blah….alongwith a bill for another $1 Billion funding. The politicians, by then, have been sold on the idea, and they have used that project to come to power – so, there is no reason they can back off from their pet project. And the fun goes on…

In some cases, it is unconventional and extremely rare wisdom to cause project immortality intentionally and avoid a harakiri of one’s professional career. However, there are often accidental geniuses who don’t speak up because they are too naive or too timid to speak up the truth. The result is still the same…

Surely, we can’t help such projects attain moksha because these projects are designed to achieve objectives at any cost, come what may. Such projects have nine lives, and so, they are destined to play their part to the hilt. At the cost of inviting wrath from project management community, I would say that if that is the only way such a project can get started, one might as well plan it ‘incrementally’ and deliver the benefits such that it is never ‘too little, too late’ lest project sponsors forget what the project was all about :). 

Improper Analysis

Ignorance about facts could invariably lead to wrong assumptions, many of which might remain unverified due to carelessness or a perception about its real threat value. These could, in turn, lead to inadequate risk identification, and thus lack of any planned and systematic response to those risks . This, then, leads to an optimistic planning about the real effort required to accomplish something, the number of resources and schedule required to complete the task, and so on. Most people who challenge planning cite the fact that a plan undergoes changes all the time, so any planning is a futile exercise. They couldn’t be more right. However, what they ignore is the fact that a plan is perhaps fourth or fifth order derivative of facts, and by eliminating the process of planning, they are only half-baking their project. If all facts about a project have been objectively verified, we can safely come out with set of assumptions. It is perfectly ok for various team members to have different perception about probability and impact of such assumptions and risks, but by choosing not to analyse those facts, we could never reach that point, could we?

However, such projects finish-off careers, tank companies, destroy health and families, in addition to never meeting their original objectives. If they are fixed price, they spawn enhancement / feature addition / maintenance projects. If they are T&M projects, they just go on and on. If the project is of strategic importance, it continues. If not, they are buried deep where no one can find them. If a key executive was behind the idea, it is never discussed in the company thereafter. Sometimes, such immortal projects are used a proxy for boardroom politics. In any case, the eventual responsibility for avoiding such immortal projects lies with the project manager.

We all know the rhetoric, but still we somehow manage to immortalize the project by making wrong choices abour project planning and execution. As project manager, the following steps could help you avoid project immortality and take you towards project moksha:

  1. Get agreement on project scope in mutually agreeable terms. If you don’t precisely know what is required, you may not be able to deliver precisely what is required.
  2. Validate every assumption. This is perhaps the single biggest source of gaps in project analysis and planning.
  3. While analysing risks, don’t ignore risks that have high impact but low probability – if it materializes, the impact could still kill the project.
  4. Get your team to make and own project commitments, and review them throughout the lifecycle.
  5. Measure twice, thrice or even ten times till you have confidence in your numbers. And only then cut the cloth. Of what use is a commitment to the customer when the team itself doesn’t have confidence in it?
  6. Learn to say ‘NO’ and to substantiate it with your line of reasoning till your project stakeholder and project sponsers are convinced.
  7. Fred Brooks was right – it is the termites that kill the project and not tornadoes. Ignore daily delays at your own peril.

Surely, these simple steps won’t guarantee your project’s salvation. At best they will remind you of some of the critical things you could do to reduce chance of a project immortality. At worst, they will be of no use, simply because something else will come from left field and hit your project. In this blog post, I wanted to introduce the concept of project immortality and project moksha that I found interesting while thinking on those lines. It offers a different perspective to how projects evolve into often unexpected lifeforms.

So, do you want your next project to be immortalized 🙂 ?

4 thoughts on “From ‘Project Immortality’ to ‘Project Moksha’

  1. Ravi Maganti


    Project delays and re-estimation which mostly makes projects immortal is common in the new world – sometimes, the Project Manager and/or Management are heavily inclined to enrich feature-function at the cost of attaining Moksha albeit unaware.

    Project Management is continously increasing in complexity as projects get bigger and more complex; as we move forward, only visionaries are likely to attain Moksha and that is succinctly explained in this article – I look forward for more gyaan.

    Thank you.

    1. TV Post author

      @Ravi: You are spot on. Some project managers only believe in adding features after features – often even well after feature complete, and never quite focus on making the software robust enough to ship. As we all know, Pareto’s Law makes sure 80% of those features are never used (or provide only 20% value to the user), so adding all those frivilous features not only makes bad economic sense for development teams, it is even more worse for the customer who is overpaying for features that he never wanted in the first place, and because of which, the software is buggy, unstable, costlier and late! I think the future belongs to people who eventually figure out what not to build rather than what to build :).

Leave a Reply