Why Do So Many IT Project ‘Fail’? The simple answer is that many perceived IT implementation projects are “not” an IT project but mainly a business systems project. For mid-sized companies, that generally don’t have a dedicated Project Transformation team, that transformation responsibility is nevertheless frequently levelled at an IT team that is more usually just responsible for the day-to-day IT services. IT teams in that size of organisation generally don’t have the business experience, knowledge and capacity required to define a problem statement, and make key strategic decisions based on the technology and systems capabilities. This often means they miss the actual challenges the business works within and sometimes choose a product that is not sufficiently adequate to satisfy the business requirements and take advantage of new business opportunities and possibly resulting in costly project ‘failure’.

It can also be the case that the IT Services team is not necessarily sufficiently informed about how the business operates and management’s strategic goals.  That means IT Services frequently don’t have the necessary insight about business unit’s processes and how they can be made more efficient ahead of deciding what might be the most appropriate technology solution. That can mean inefficient processes are carried over to the new system, which means the system is then immediately compromised with the same inefficiencies during implementation.

Here we summarise some of the most commonly encountered obstacles experienced by companies in the course of IT project implementations, frequently compounded by not having all the right people assigned to the project elements behind each illustrative cause.

Commonly Encountered Obstacles to Successful IT Implementation

For convenience, we’ve grouped some of the common failure causes into 4 main categories, although some really sit across more than one. Here’s a list of the main reasons:

Inadequate Planning

• Ill-Defined Projects and Unclear Business Benefits from the Outset – most digital transformation projects, both big and small, are business led. So, if your own IT Services team is going to be at least part-responsible for that implementation, it is critical that they are a fully included part of the Discovery and planning, together with relevant business unit personnel and any external advisors and consultancies contributing to the exercise.
  Poor planning and scoping are major reasons for many poorly executed and/or incomplete projects. Being crystal clear on where the ROI actually resides needs to be clear from the beginning. What is the point of a shiny new system if it has been implemented in a way that replicates existing operating models, for example. Benefits result from increased revenues, increased efficiencies, reduced costs and reduced risks etc. These should be articulated clearly upfront so that the roadmap for change is executed in a way that realises these benefits in a logical and timely fashion.

• Inadequate IT Personnel Skills and Capacity – following on from a failure to include your key business resources adequately during Discovery and planning, the main cause of many IT project ‘failures’ is insufficient skill and capacity. We observe this time and time again, when taking on remedial work for new clients where projects have floundered for want of sufficient in-house skills or the capacity to achieve what was anticipated. It is really beneficial to have business resources dedicated to any implementation; to have them always on point. This dedicated staffing could involve more depending on the size and complexity of the project. So many projects ‘fail’ because there is not enough agreed buy-in from the leadership to provide key people since they are so often critical to the day-to-day running of the business.

• Inadequate Budget – obtaining and maintaining sufficient budget can prove a minefield. An ill-defined plan can leave you short on sufficient budget to meet expectations that might be far removed from the written plan.  With hindsight, clearly not a good approach.

• Unrealistic Expectations – lack of project definition, refusal to recognise limitations of internal skills sets and lack of budget can lead to altogether unrealistic expectations. The desire might be there, but the collateral necessary to meet with success is often absent from the outset.

• Unnecessary Complexity – attention to detail is absolutely required for successful project delivery. Having said that, it needs to be well thought out, clear and logical. A messy approach and structure will invariably lead to a messy result, whether delivery is complete or not.

Poor Communications and Culture

• Lack of Employee Understanding and Buy-in – we emphasise this time and again. Early and appropriate communication throughout, with respect to project rationale, responsibility, governance, budget, team and users is critical to successful delivery. This is so often ignored, or only partially practiced.

• Attempting to Satisfy ALL Stakeholders – comprehensive communication is essential but it’s important to also recognise that it’s unlikely you’ll be able to meet all stakeholders’ expectations and aspirations. That’s okay, but it means great communication is all the more important, especially if having to manage expectations downwards.

• Inadequate Management Understanding – this really refers to the managers at business unit level and below. It’s really covered by the first point here, but as managers of operations, it is imperative they are involved from the very start.  We’ve observed situations where managers have only been told of such an introduction a fortnight before ‘going live’. In such a situation a degree of resistance is almost inevitable.

• Lack of C-Suite Support – it’s not essential the C-Suite is involved in day-to-day decision making of IT project planning and delivery, but it is essential there is wholesale support and understanding of how the project, its implementation and success, will contribute to overall strategy and at what investment cost. This should ideally be unanimous, or at least without major dissent. It also requires agreed sponsorship. Determine who is accountable and what are the consequences to them and their team if the project fails.

Inadequte Governance and Assessment

• Lack of Independent Oversight – this always reads terribly self-serving but using the services of an independent consultancy can be really beneficial. Having a view, up and down the project and across all stakeholders will help ensure successful delivery, on time and on budget. Choose carefully. Make sure they have the appropriate skills and experience, of both IT and business systems, but then work closely with them to provide the value they can. At some stage, it is almost inevitable their honest, realistic and direct advice will spot any warning signs of project failure and avert project stoppages. Or at least enable a rapid unblocking.

• Poor Roadmap Navigation – your value-add project should have been properly assessed, planned and populated with important KPIs, milestones and critical dates to permit efficient continuation. They are there for a reason. Meet and stick to them to ensure project success. Though note, it’s important to realise that sometimes adapting the roadmap may be necessary. We have had to do this numerous times, in taking on new clients’ project recovery work.

• Scope Creep – in project recovery mandates, this is often encountered. Not always, but sometimes. If it is occurring within an existing project Roadmap, it’s likely a sign that the project is already ‘failing’ in some way or other. It could be time for an independent review.

• Inadequate Vendor Management – depending on the relationship and agreement, a consultancy or independent project manager can also warn where a vendor might be trying to pull the wool over their client’s eyes. They can also assess a vendor’s tendency to overpromise, and so potentially underperform. Of course, this is relevant to the initial vendor selection too.

Lack of Discovery and Unrealised Opportunity

• Lack of Full Discovery – reiterating our first point about the importance of clearly articulating the business benefits that can be achieved. In our experience some companies would rather skip this important part of the process, preferring to get on with planning the project delivery as originally envisaged. This is shame as a comprehensive Discovery phase can not only bring to light potential pitfalls that might impact project delivery but, also unveil the potential for even greater value-add; identifying new revenue streams, new products, new customers, new and more efficient working practices.  Revising processes is key – you don’t want to crowbar poor inefficient processes into your shiny new system.

• Delivery Limitation – Not conducting a Discovery phase will mean failing to identify greater potential gains. A lack of examination, both internally and externally tends to lead to compartmentalisation, thereby limiting many projects to limited and quick ‘wins’ but with the potentially greater gains “left on the table”. Again, if your Discovery and planning is comprehensive at the outset, delivery limitation is a far less likely prospect.

We saved Discovery till last because we’ll bat on about this (and do so in more detail on this in our article ‘“Getting it Right First Time!” A Bit About Discovery and Planning, or How to Avoid Project Failure and Comprehensively Plan for Success!’). It should really be a part of ‘Inadequate Planning’ but is so frequently omitted that it not only means unrealised value creation but is also often a major cause of project failure.