Why do Projects Fail?

image courtesy:http://www.davidakka.com/wp-content/uploads/2013/09/bridge-fail.jpg

It’s a generic question but with specific answers.  It can be a half-baked cake or badly-burnt dish or unfinished construction or a software gone haywire. Whilst the main reasons attributed are scope, schedule, execution or implementation, the causal analysis always reveals that the failure in capturing the business requirement is the root cause of all failures. It’s not that vendors are to be blamed; sometimes clients themselves can’t define precisely the requirements and hence find Agile handy to tweak requirements and vendors too believe it’s the best way to earn the client’s confidence and all stakeholders are on the same page. It’s all hunky dory and everyone goes home happy.

Fact can’t be far off from fallacy. At every sprint if the scope is touched, it constitutes a creep. Waterfall will readily admit it as a change request but Agile will accommodate.  It’s a subject in itself to deliberate about waterfall and Agile methodology but for now let’s get back to the topic: why do Project Fail? Communication Gap. The Business Requirement Document from the client is the feed which is passed and a complementary Software Requirement Specification document mapping each and every requirement is prepared by the vendor. If proper scrutiny and vetting is done at this stage, there would be no need of Gap Analysis document, which inevitably would be scripted sooner and the Impact Analysis document as well. Why is the need for these documents when BRS should suffice? Firstly BRS suffices? In most of the cases, the answer is a resounding NO. Is it possible  putting to print all the finer details when only the outline can be conceived and then dwell deeper to mine information and incorporate into the document? Corporates spend much time in identifying the need before the solution, and it’s a disaster when the cart is put in front of the horse when a solution is sought before the need, with its nuances, can be transcribed.

We have seen constructions completely demolished and rebuilt because the plan doesn’t match with the work-under progress and hence scrapped and sketch is revisited. The million-dollar question would be is it possible to put everything on the paper before releasing as Project requirement? Yes and no.  It would call for a tremendous vision to envisage the final product, and usually thought-through and prototypes built as per the sketches. And despite that vendors fail on their part to deliver – as committed  at cost on time for reasons as enumerated above. While the blame-game can be played all day, if only the communication was open, clear and concise, much ado about mishaps and mismanagement can be mitigated or methodically brought to closure.

You might be interested in checking out our PMP or PRINCE2 courses to know more about managing a project. http://goo.gl/U4Rtez