Unfortunate, organizations actively avoid making data about failures public.  It may be difficult for you to obtain this data (but I hope you do). 

Roy and Aubert studied systems failure with qualitative case studies with face to face interviews with employees.  The employees and company names were kept confidential.  See this reference:

Roy, Vital, and Benoit A. Aubert. "A Dream Project Turns Nightmare: How Flawless Software Never Got Implemented." Cahier du GReSI no 2 (2002): 05.

http://expertise.hec.ca/gresi/wp-content/uploads/2013/02/cahier0205.pdf

This paper was published as book chapter:

You may be able to obtain data about the "Canadian Firearms Information Systems" which was a spectacular failure in terms of cost over runs, and project management and implementation problems.  Since it is a government project, a great deal of data should be obtainable.

http://www.oag-bvg.gc.ca/internet/English/parl_oag_200605_04_e_14961.html#ch4hd4d

Thanks Francine, very helpful indeed.

I am particularly enjoying going through the flawless insurance software project designed by those brilliant actuaries...

Then abruptly put on hold; indefinitely!

I'll finish going through the material and see how I can structure my data to depict a trend, if any.

You have an interesting research project in my judgment of high potential utility to IT management, and you have good advice from Francine about the cover-up of data.  Of perhaps a half dozen project failures I witnessed in a consultant role, sometimes called in to rescue some value from them, I have never seen a post mortem analysis by management that identified the real causes of failure. Often the failure symptoms combined technical obstacles with contract management and project management inadequacies.

In one such case known to me, a systems manufacturer tried to put together software products (a file manager and a networking system) developed by different groups in the company which did not intercommunicate reliably because neither group anticipated that their respective works would be used together almost in prototype form. Ignoring the technical interoperability of components and that the contract manager on the seller's side had committed to functionality and delivery time without having previously consulted the engineers, line management blamed the failure on inadequate staffing even though the project manager had warned at inception that the delivery time was extremely risky regardless of the staff level.

Having seen cases like this, the three groups on whose information I would rely are not line management but contract management, project management, and engineering. These three groups are more likely to have both detailed knowledge and less biased perception of the outcomes.

How can you find them? For the period of the 1990's it is not so recent that you would not find knowledgeable retirees or persons relatively unemployable (due to age) who could be surveyed. Often they can be found in professional social media websites, which have corporate "alumni" groups. If you must rely on published post mortem analyses, it may be worthwhile to factor the aforesaid considerations into a filter for selecting your sources.  I hope this little bit of insight helps.

Thanks Albert this is really an eye opener. I'm also very reliant on my supervisor's direction who has supervised and published a number of academic journals and what you are saying is very much in line with what he communicated a while ago.

He is also keen on narrowing the scope for optimal output. I guess his experience is his source of wisdom to ensure I don't overwhelm myself and fail to complete my dissertation.

I wonder why you say: "I hope this little bit of insight helps." when you are spot on and fairly comprehensive on your response.

Thanks a lot, it's good to be part of the virtual global research community.