Why AI Based Projects Fail

The table below was adapted from guidance produced by the Office of Government Commerce, as part of their "Successful Delivery Toolkit". The original document, "Why IT Projects Fail" provides a succinct but complete characterisation of reasons for IT project failure. It can be downloaded, along with other useful guidance, from the OGC's Guidance Page

The five management (and failure) categories highlighted in the table below (Design and Definition, Decision Making, Project Discipline, Supplier Management and People) will be used as a basis for discussing, understanding and analysing failure in AI based systems in this study.

	Causes	Impact
Design and Definition Failures	Required outputs not described with sufficient clarity – no scope definition prior to authorization Over-ambition – sweeping into a single project all "good ideas" – all deliverables in one chunk Project seen as an AI project, not as part of wider process to deliver business objectives End-goal too distant with too few review points to confirm business case	Projects have little understanding of what they have to do to "succeed" and far too many stakeholders to satisfy. Without clear definition of interim success or assessment of what is achievable, projects drift into long term activities which become uncontrolled and uncontrollable. Ultimately, failure is designed in
Decision Making Failures	Prime responsibility rests with committees Consensus must be achieved on all issues No single individual in authority – project manager makes decisions in absence of sponsor	Key issues are logged but remain unresolved as all people with an interest are consulted. Outcomes of consultation will be blurred in order not to trigger opposition and veto. Projects are not given clear direction – key actions are not taken or are inconsistent. Ultimately, a failed project evolves
Project Discipline Failures	Project documentation replaces project management Milestones are too distant – slippage is not managed Weak arrangements to identify and evaluate risks and allocate them to managers with authority Requirements changes not reflected in "immutable" deadlines Contingency planning is weak or unrealistic Project beyond the experience and capability of the Project Manager	Plans are constructed based on deadlines which are pre - determined; few people actually believe they reflect reality so slippage or the impact of change is not taken seriously. Prospect of failure is not allowed to be acknowledged so few preparations are made for problems which do arise. Ultimately, the project moves, unacknowledged, into failure, costs escalate
Supplier Management Failures	Project has little understanding of supplier commercial imperatives Supplier not selected on basis of VFM Projects are launched without an agreed contractual completion date, acceptance criteria and cost limit Insufficient transparency of management information between client and supplier Suppliers managed to limit cost rather than risk – no validation of suppliers assumptions	The key early part of the project is confused by contractual debate and positioning – often leaving both sides disappointed. This mistrust is then exacerbated by misunderstanding of supplier and project motivations creating further disputes and resort to contract - leading to a culture of secrecy and "sides" Ultimately, the project focuses its energies on blame for failure
People Failure	Disconnect between project and those who own the need Culture in project teams to explain away real risks, and to hide not address problems Needs of users not understood due to secrecy or haste during definition and design phase Too few senior people with real authority	Project staff develop what they believe to be "developable" and avoid asking for guidance – given the risk of veto and delay. Requirement "owners" fail to understand what is feasible and therefore request deliverables and change which are impracticable in the given timescales or budget. Ultimately, the project delivers failure