Project Failure: Who Says?

And Some Legal Stuff

Dr. Brendan DCruz University of South Wales Can you define project failure ??? Is it easier to define project success consider quality, reliability, usability and requirements

Why Projects Fail, from The Standish Group (1996) in Computing, 27/6/96, p.31
Incomplete requirements (13.4%) Lack of user involvement (12.4%) Lack of resources (10.6%) Unrealistic expectations (9.9%) Lack of executive support (9.3%) Changing requirements (8.5%) Lack of planning (8.1%) No longer required/obsolete (7.5%) Lack of management (6.2%) Technology illiteracy (4.3%)

Management Activities by Frequency that Contribute to Failure (Taylor, 2000)

Poor scope management (81%) Poor change management (73%) Poor project management (70%) Poor monitoring and control (58%) Poor risk management (50%) Poor client management (38%) Poor communication management (35%) Poor changeover management (18%) Poor contract management (15%) Poor interface/system management (5%) Poor cost management (5%)

PM4SUCCESS (2006) Survey

Weak executive sponsorship Too many recent change initiatives Poor communications with stakeholders Unsupportive corporate culture Poor skills training/education Inadequate resources/funds Lack of line management commitment Employee/end user resistance Unclear strategy/objectives No support from top management Too much politics/self-interest Poor benefits management Mismatch of expectations Failure to confront the real issues The Not-Invented-Here syndrome Weak implementation Unrealistic timescales Lack of change management experience

The Top 10 To 2006

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Poor definition of project scope Lack of senior management/executive support Unrealistic timescales Incomplete or changing requirements and specification Poor user input (& mismatch of expectations) Lack of planning Lack of or inadequate resources Lack of leadership and/or communication skills Poor stakeholder management Lack of project specific skills/competence

Key Reasons Why Projects get Cancelled

John McManus & Trevor Wood-Harper, e-BCS PM, June 2008

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

Why Projects SUCCEED, from The Standish Group (1996) in Computing, 27/6/96, p.31
User involvement (15.9%) Executive management support (13.9%) Clear statement of requirements (13.0%) Proper planning (9.6%) Realistic expectations (8.2%) Smaller project milestones (7.7%) Competent staff (7.2%) Ownership (5.3%) Clear vision and objectives (2.9%) Hard working, focused staff (2.4%)

What? No Benefits?
Overambitious or unrealistic expectations Benefits being prescribed rather than calculated Lack of stakeholder engagement Realisation is beyond the organisational boundary Benefits that cant be measured Declaring victory to early Lack of management information Lack of skills and experience Benefits delivered AFTER project, so who cares?

Reports and Disasters

Inland Revenue system abandoned (1985) KPMG (1990) 30% of projects over budget, over time London Stock Exchange (Taurus, 1993) abandoned KPMG (1996) 85% of projects in large UK companies late, over-budget, etc. are we actually getting better?! KPMG (1997) 62% of 120 organisations had at least one runaway project Passport Office (1999) fails with much publicity Also: London Ambulance Service, DSS, DVLA, Post Office Horizon/Pathway, National Air Traffic Services, Libra, Child Support Agency, Prison Service, Wembley Stadium, Millennium Dome, Job Centre+, Terminal 5 Baggage, Dept. of Transport NHS IT (e.g. EPR), ID cards, Nimrod, Transformational Government, London 2012 Olympics! Whose money? Whose accountability? Who cares?

Project TAURUS - 1993

Transformis Consulting Ltd, 2007

LAS Computer aided dispatch - 2002

Transformis Consulting Ltd, 2007

NHS Computer Programme - 2007

Transformis Consulting Ltd, 2007

[Edit] Why Dont We Learn?

Repeated high profile and costly failures Repeated surveys: 50% 85% of projects fail in some way from academic studies? Methodologies aplenty, certifications galore Government and corporates seek improvement Drive towards professionalism is important! http://www.silicon.com/technology/itservices/2011/08/22/five-ways-to-stop-your-itprojects-spiralling-out-of-control-andoverbudget-39747844/?s_cid=193
Transformis Consulting Ltd, 2007

Interactions
Solution Delivery

The Project Board

Business acceptance Benefits realisation

Transformis Consulting Ltd, 2007

Whats going wrong?

Solution delivery
Incomplete/changing requirements Lack of business involvement Lack of resources

Business acceptance
Lack of change vision Poor communication Fear, uncertainty, doubt

Benefits realisation
Poor strategic fit Poor business case No realisation plan

Transformis Consulting Ltd, 2007

Do the key relationships work?

Sponsor

Project Manager
Solution

Requirements

Accountable Executive

Transformis Consulting Ltd, 2007

Alan Ruddock (2007): The model

Executives

The Project / Programme Board Business Acceptance Solution Delivery Benefits Delivery

Effective Risk Management Independent Assurance People Management

Staff
Transformis Consulting Ltd, 2007

Pintos Critical Success Factors

Project mission clearly defined goals/directions Top management support are they willing to give authority/power and necessary resources? Project schedule/plan action steps for implementation Client consultation active listening and engagement Personnel right people, right tasks project organisation Client acceptance sell the benefits to intended users? Technical tasks supporting technology Monitoring and feedback control information/action Communication network of information/knowledge provision e.g. Project Place, SharePoint, etc. Troubleshooting crises and deviations from plan

TC02 - Project Success and Benefits Management

Project success is the satisfaction of stakeholder needs and is measured by the success criteria as identified and agreed at the start of the project.
Benefits management is the identification of the benefits at an organisational level and the monitoring and realisation of those benefits. Competency Indicators

1 - Analyses and understands the project and its context within the proposed business change and how these can enable the expected benefits (indirect, direct, financial and non-financial). 2 - Agrees success criteria for the project with the sponsor, ensuring they are measurable. 3 - Identifies critical success factors for the project with stakeholders. 4 - Agrees KPIs, ensuring these are quantitative by using traditional time, cost and quality techniques. 5 - Understands the relationship between the timing of deliverables and the realisation of benefits. 6 - Discusses and agrees the project success criteria and benefits realisation responsibilities with all relevant stakeholders as part of the project management contract with the customer. 7 - Executes and controls PM plans and changes, and reports on project performance. 8 - Ensures that the impacts of any deviations from plan are considered against the business case and the benefits realisation plan, and are escalated to the responsible stakeholders. 9 - Collects results and prepares project performance reports against the agreed KPIs and anticipated benefits, and communicates to relevant stakeholders. 10 - Ensures that benchmark data is captured against which benefit realisation can be measured.

The Discussion
There are no magic solutions for success BUT are there better practice approaches that can help to avoid failure? Research has become more focused and pervasive, but is it still too perceptual? What else can be done? Differences between reports on projects in the public and private sector are they really that different, and why? Differences between TYPES of project do they matter? Does an entire project (or programme) not need multiple fail/succeed criteria? Name some We will look at communication, risk management, quality management, change control, configuration management, planning, etc. when we look at Prince 2TM