Question

Read the following article below and state how they might have done things differently to not put them (collectively) in a project failure mode, discuss this in 2 ~ 3 paragraphs.

A study in project failure

Research highlights that only one in eight information technology projects can be considered truly successful (failure being described as those projects that do not meet the original time, cost and (quality) requirements criteria).

Despite such failures, huge sums continue to be invested in information systems projects and written off. For example the cost of project failure across the European Union was €142 billion in 2004.

The research looked at 214 information systems (IS) projects at the same time, interviews were conducted with a selective number of project managers to follow up issues or clarify points of interest. The period of analysis covered 1998-2005 the number of information systems projects examined across the European Union.

Number of IS projects examined within European Union

Rank	Sector	No. of projects examined
1	Manufacturing	43
2	Retail	36
3	Financial services	33
4	Transport	27
5	Health	18
6	Education	17
7	Defence	13
8	Construction	12
9	Logistics	9
10	Agriculture	6
Total		214

Project value in millions of Euros

Value range in millions (€)	Number of projects	Percentage (%)	Accumulative (%)
0 – 1	51	23.831	23.831
1 – 2	20	9.346	33.177
2 - 3	11	5.140	38.317
3 - 5	33	15.421	53.738
5 - 10	4	1.869	55.607
10 - 20	87	40.654	96.261
20 - 50	6	2.804	99.065
50 - 80	2	0.935	100.000
Totals	214	100.00	100.00

At what stage in the project lifecycle are projects cancelled (or abandoned as failures)?

Prior research by the authors in 2002 identified that 7 out of 10 software projects undertaken in the UK adopted the waterfall method for software development and delivery. Results from the analysis of cases indicates that almost one in four of the projects examined were abandoned after the feasibility stage of those projects completed approximately one in three were schedule and budget overruns.

Project completions, cancellations and overruns

Waterfall method lifecycle stage	Number of projects cancelled	Number of projects completed	Number of projects overrun (schedule and/or cost)
Feasibility	None	214	None
Requirements analysis	3	211	None
Design	28	183	32
Code	15	168	57
Testing	4	164	57
Implementation	1	163	69
Handover	None	163	69
Percentages	23.8%	76.2%

Of the initial 214 projects studied 51 (23.8 per cent were cancelled) - a summary of the principal reasons why projects were cancelled is given below. Our earlier research elaborated on the symptoms of information systems project failure in three specific areas: frequent requests by users to change the system; insufficient communication between the different members of the team working on the project and the end users (stakeholders); and no clear requirements definitions. Whilst communication between team and end users was still perceived as an issue within some projects; the top three issues from this study are: business process alignment; requirements management; and overspends.

One notable causal factor in these abandonment's was the lack of due diligence at the requirements phase, an important factor here was the level of skill in design and poor management judgement in selecting software engineers with the right skill sets. Equally the authors found some evidence in poor tool set selection in that end users found it difficult to sign-off design work - in that they could not relate process and data model output with their reality and practical knowledge of the business processes.

Key reasons why projects get cancelled

Business reasons for project failure

Business strategy superseded;

Business processes change (poor alignment);

Poor requirements management;

Business benefits not clearly communicated or overstated;

Failure of parent company to deliver;

Governance issues within the contract;

Higher cost of capital;

Inability to provide investment capital;

Inappropriate disaster recovery;

Misuse of financial resources;

Overspends in excess of agreed budgets;

Poor project board composition;

Take-over of client firm;

Too big a project portfolio.

Management reasons

Ability to adapt to new resource combinations;

Differences between management and client;

Insufficient risk management;

Insufficient end-user management;

Insufficient domain knowledge;

Insufficient software metrics;

Insufficient training of users;

Inappropriate procedures and routines;

Lack of management judgement;

Lack of software development metrics;

Loss of key personnel;

Managing legacy replacement;

Poor vendor management

Poor software productivity;

Poor communication between stakeholders;

Poor contract management;

Poor financial management;

Project management capability;

Poor delegation and decision making;

Unfilled promises to users and other stakeholders.

Technical reasons

Inappropriate architecture;

Insufficient reuse of existing technical objects;

Inappropriate testing tools;

Inappropriate coding language;

Inappropriate technical methodologies;

Lack of formal technical standards;

Lack of technical innovation (obsolescence);

Misstatement of technical risk;

Obsolescence of technology;

Poor interface specifications;

Poor quality code;

Poor systems testing;

Poor data migration;

Poor systems integration;

Poor configuration management;

Poor change management procedures;

Poor technical judgement.

What is the average schedule and budget overrun?

In examining the cases it was noted that the average duration of a project was just over 26 months (115 weeks) and the average budget was approximate 6 million Euros, (Table 5). In many instances information on a project being over schedule and over budget will force senior management to act, however, the search for the underlying factors should begin else where in the projects history.

The pattern that emerges from a synthesis of case data is complex and multifaceted. In a few of the of cases examined the project commentary and history was ambiguous; however, once a decision had been made to support a project which was over schedule or over budget the ends usually justified the means irrespective of the viewpoints of individual project managers or stakeholders.

Cost and schedule overruns (N=69)

Projects From Sample	2 (2)	11 (13)	19 (32)	25 (57)	12 (69)
Schedule Overrun	11 weeks	29 weeks	46 weeks	80 weeks	103 weeks
Range	Average Budget + 10%	Average Budget + 25%	Average Budget + 40%	Average Budget + 70%	Average Budget + 90%
Cost Overrun	€600,000	€1,500,000	€2,400,000	€4,200,000	€5,400,000

What are the major causal factors contributing to project failure?

Judgements by project stakeholders about the relative success or failure of projects tend to be made early in the projects life cycle. On examination of the project stage reports it became apparent that many project managers plan for failure rather than success.

If we consider the inherent complexity of risk associated with software project delivery it is not too surprising that only a small number of projects are delivered to the original time, cost, and quality requirements.

Our evidence suggests that the culture within many organisation's is often such that leadership, stakeholder and risk management issues are not factored into projects early on and in many instances cannot formally be written down for political reasons and are rarely discussed openly at project board or steering group meetings although they may be discussed at length behind closed doors.

Despite attempts to make software development and project delivery more rigorous, a considerable proportion of delivery effort results in systems that do not meet user expectations and are subsequently cancelled. In our view this is attributed to the fact that very few organisation's have the infrastructure, education, training, or management discipline to bring projects to successful completion.

One of the major weaknesses uncovered during the analysis was the total reliance placed on project and development methodologies. One explanation for the reliance on methodology is the absence of leadership within the delivery process. Processes alone are far from enough to cover the complexity and human aspects of many large projects subject to multiple stakeholders, resource and ethical constraints.

Although our understanding of the importance of project failure has increased, the underlying reasons still remain an issue and a point of contention for both practitioners and academics alike. Without doubt there is still a lot to learn from studying project failure.

Going back to the research undertaken there is little evidence that the issues of project failure have been fully addressed within information systems project management. Based on this research project failure requires recognition of the influence multiple stakeholders have on projects, and a broad based view of project leadership and stakeholder management.

Developing an alternative methodology for project management founded on a leadership, stakeholder and risk management should lead to a better understanding of the management issues that may contribute to the successful delivery of information systems projects.

Answer 1

Answer:

By using given data,

Let us,Inspite of higher failure rate of IT projects many companies to undertake IT projects for simple reason that, if these project succeed .It would bring lot of cost savings to the company in success years. This shows the power of IT projects.

According to my side major reasons for IT failure is poor understanding of requirements of project by project manager, Poor training of developed software, poor financial planning and ever changing requirements from clients.

Here project manager plays a vital role in success of project. He is the key role of the project, hence it is vital for him to know, the requirements of project perfectly. Many IT project fails due to poor understanding of project by project manager.

After ,the development of software it is vital to train client regarding usage of software. If project team fails to train software to concerned parties, clients may raise objections which leads to delay of project.

Financials of the project are also important. Many times IT companies endeavor project at significantly lesser cost due to cut throat competition in the sector. This results in allocation of lesser budget to project which leads to financial constrains of project and ultimately lead to failure. Hence company should properly calculate cost of project.

Ever changing requirement of project are another major problems in IT . Clients often change their requirements which leads to considerable delay and poor designing of software. Hence it is vital to spend time with clients initially to know the requirements completely before starting the project and not to entertain any changes during the course of project.

These are the ways in which projects can be done differently to save it from failure mode.