Project Failure

From GTwM

Jump to: navigation, search

Albert Einstein once said “The definition of insanity is doing the same thing over and over again and expecting different results”.  Unfortunately longtitudinal research from a variety of different sources suggests the software development process contines to be very flawed.

Chaos Report 

One of the most commonly quoted source of metrics re project failure are the Chaos Reports, produced by the Standish Group over the last fifteen years, which argue that only around 29% of projects come in on time and budget (see below).

Image:Success_failure_rates_12years.png 

Image:Cost_overrun_12_years_graph.png

With big projects failing more dramatically than smaller ones.


Image:Project_failure_by_revenue_graph_from_standish_group_report.gif


Whilst these statistics have been queried by other academics because of their research methodology they form the basis for much conjecture.

According to research by the Butler Group, poor IT governance is one of the key causes of failure in big business transformation projects.

A report from the analyst house found IT governance initiatives were usually deployed only within the IT department, leading to a lack of co-ordination between the IT-led elements of projects and the wider management of business transformation initiatives.

The results of poor IT governance are increased costs due to the inefficiencies of short-term; tactical IT deployments; risk of breaching data security and regulatory compliance requirements; and unproductive use of people and IT assets.

Alan Calder, author of IT Governance: A Manager's Guide blamed a lack of IT-awareness in boardrooms for this poor governance and project failure.

Calder told silicon.com: "IT governance is the board's job. It is the board's job to make sure this huge capital expenditure is managed in a transparent way. But most boards still have directors who have their PAs print their emails out for them. They are just simply from the wrong generation. You need IT-aware executives and non-executives."

Calder advised businesses to have a separate IT governance committee with non-IT executives to oversee and scrutinise big IT projects and stop them from becoming a black hole for wasting money when things start to go wrong.

He added: "The committee should be there to make sure risks are identified and mitigated and that there is transparency - to ask what methodology, what skills, how much are you planning to spend. You need to have someone who can say 'no, you can't have more money' and who can pull plug if they need to."

Tim Jennings, research director at Butler Group and author of the report, said medium-sized companies of up to 5,000 employees are particularly susceptible to poor returns on IT investment because they are less likely to have the required disciplines in place than large organisations - with many still relying on simple spreadsheets to manage projects.

He said: "Many new business initiatives are reliant on information systems, so the impact of poor IT governance is not just an IT issue but directly reduces the potential business benefits."

Best In Class Performance

Image:Software_Maturity_Metrics_-_Aberdeen_Group.JPG


Image:Strategies_for_success_in_software_development.JPG

The above diagrams summarises the research conducted by the Aberdeen Group which gives detail of performance differences within this sector (rather than the composite picture painted by the Standish Group) and strategies that underpin these differences.

Beyond Budget and Schedule - Agile Criticism

Most discussion re project failure rates assumes that the traditional project triangle (Time, Resources, Outputs) is unproblematic, a project is a failure if it fails to deliver it's outputs in the specified time and budget. However the last twenty years has seen the rise of the agile movement and debate around "adding value" versus "ouptuts".

In this area of debate the core measure is "percentage of features that are rarely or never used". Research again by Standish shows that

64% of features included in products are rarely or never used!

Image:Software_feature_bloat.jpg

(see also Common Project Issues, The Fifth Discipline, Illusion Of ControlThe Cone Of Uncertainty)

Perhaps a positive way to begin a reflection on risk and failure would be to look at stats re climbing Everest

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox