What are the most common IT project failures and how can you learn from them?

In today’s day and age, teams are adopting agile techniques and organisations have de-risked large scale failures that we saw a decade ago due to unclear scope. However, small agile deliverables can lead to compromises on technical design and circumventing architectural principles in order to meet deadlines. Unless supported by a strong system/product management, future development becomes increasingly difficult and expensive. The program must find creative ways to manage its technical design and architectural purity to meet business expectations in the long run.

Business outcomes either are not met, not understood or shift in the middle of the project. So status’s are incorrect until UAT testing and then it is realized this is not what they needed.

IT project failure refers to a situation where an information technology (IT) project does not meet its objectives or expectations and does not deliver the intended results within the defined scope, time, or budget. IT project failures can have significant negative impacts on an organization, including financial losses, damage to reputation, decreased employee morale, and hindered progress toward organizational goals. There are various reasons why IT projects fail, and they can vary based on the project's complexity, size, industry, and other factors like: Poorly Defined Requirements, Lack of Stakeholder Involvement and Communication,Inadequate Planning and Project Management, Scope Creep, Inadequate Resources, Inadequate Resources.

Based on my experience in cooperate groups, the following issues are among others missing or insufficient information on the background and implementation of the project, lack of involvement of the executive unit. The end date of the project is often fixed at the beginning, but the time that elapses between the decision and the start of the project does not result in a postponement of the end date. Issues such as - budget - Scope - People should be settled and agreed in advance in order to have a clearly defined start and end date for the project.

Poor scope definition will eventually cause constant additions to scope and change requests. It is equally signifficant to defina what is in scope, as well as what is out of scope. Don't be afraid to clarify it with stakeholders over and over until you reach clear understanding.

As I led one of the biggest SAP-Projects in Europe, I used close team comms as key for success. Daily, short alignment-calls for 20-30 minutes. Once per week an assembly of key stake-holders. Run through the status of each project, learn about risks and mitigation. Do not miss out on any delivery date - even if it is small things. Then you will not fail the big milestones.

In a larger projects and programs, it is also important to share information about the big picture and common plan with your team and tell your team members what is your project's and team members' role in that big picture. Many times your team is worried about the depending and impacted activities that are performed by other teams. Therefore it is important to share the common plans with your team, listen to your team members opinions and questions about those and ensure that the cooperation with other projects and teams goes well.

The culture of trust is critical - team members need to feel able and empowered to call out issues - and delays. Too many times people don't want to call out that timelines / deliverables are at risk. Early warning allows early action. How many projects are watermelons ? Green on the outside and bright red on the inside

I do recall on a major IT project I was involved in and I had the honor to work with one best of program manager (nickname ABW). The project involves multiple IT domains with each domain has a project manager. ABW runs a 9 AM call daily & have all teams listen to all project manage status short reports. This will enabled teams to know what's going on & open their eyes to all possible inter-dependences between each IT domain. I would agree that communication and collaboration are critical to IT project, but at the same time need to take into consideration that continuous bombardment of emails and live chats will take away valuable time to do actual work. Therefore there's a need for balancing act.

The article accurately points out the importance of communication in IT projects. In my experience as a Technology Manager, the form of communication matters greatly. For example, during a Scrum sprint, a quick stand-up meeting was effective in resolving an urgent issue. However, for making an informed decision on adopting a new technology stack, asynchronous methods like emails allowed for in-depth analyses from team members. It's not just about having communication tools; it's about knowing which tool is appropriate for the problem at hand. Fostering a culture that understands this nuance can significantly reduce project failures due to poor communication.

"I remember 12 years ago when I was much younger and less experienced. I started a project in which I had to upgrade an Exchange Server in an organization with over 2000 users. I invested many hours in planning the upgrade process, but I forgot about the potential 'risks.' As a result, we experienced a 5-hour email service outage. It was a valuable lesson for me."

Inadequate risk management is indeed a root cause of many IT project failures. Speaking as a Technology Manager, I find that the traditional risk assessments are often not dynamic enough to keep up with the ever-changing landscape of a complex project. For instance, we once underestimated the challenges of integrating a legacy system with a new tech stack, leading to severe delays. The lesson was clear: static risk assessments can be misleading. Now we employ a more agile approach to risk management, revisiting our risk assessments at key project milestones and employing a 'rolling risk review' mechanism. This strategy has since enabled us to preemptively identify issues and adapt more quickly, minimizing failures considerably.

Insufficient risk management is a significant contributor to IT project failures. Drawing from my experience, neglecting this aspect can lead to unforeseen crises and project derailment. To address this, begin with a thorough risk assessment at project initiation, and keep it updated. Develop a robust risk management plan that clearly outlines responsibilities, tools, and strategies to tackle potential threats and seize opportunities throughout the project lifecycle.

In my role as CTO, where I oversee IT Management and Lean Software Development, the importance of risk management cannot be overstated. While it's vital to conduct risk assessments at the beginning of projects, I've found ongoing 'risk grooming' sessions to be equally crucial. In the Scrum framework, you can incorporate this as a recurring agenda item in your Sprint Reviews or Retrospectives. We've also implemented an approach we call 'Pre-Mortem Analysis,' where we imagine the project has failed and work backward to identify likely culprits. This unconventional method sometimes reveals risks that conventional assessments overlook.

Hay situaciones que humana a veces no podemos evitar, pero hay que resolver. Recuerdo que previamente a una implementación, se detectaron 1500 vulnerabilidades, se hizo un trabajo arduo para reprogramar la fecha de implementación y resolver inconveniente.

Testing in a "boot camp" where business people are sitting close to test managers and scrum leads was one success factor when leading one of the biggest ERP-projects in Europe. Advantage is: complex iteration via test tickets back and forth could be reduced significantly. Key for in-time-delivery of the project was in-time and high quality of testing.

Insufficient testing and quality assurance can indeed be detrimental to IT projects. In my tenure as a Technology Manager, I've noticed that traditional 'waterfall' models often miss systemic issues until they're too costly to fix. That's why we integrated QA into every development phase. In a financial automation project, for example, we adopted Behavior-Driven Development (BDD). This enabled automated tests based on behavioral specs, ensuring that the system met business requirements from the outset. Moving to a 'Quality Assurance as a Service' (QAaaS) approach has not only reduced defects but also boosted stakeholder confidence. Proper planning and continuous QA are vital for the project's success.

In the context of IT Management and Lean Software Development, underestimating the importance of testing and QA can be costly. For example, in one of our Scrum-based projects, we integrated 'Quality Gates' within our Sprint cycles. This allowed us to proactively identify issues before moving to the next development phase. Another practice we’ve adopted is 'Shift Left Testing,' where testing begins much earlier in the project lifecycle. This approach allows us to catch defects sooner, making them less expensive to fix than if discovered later. We also involve stakeholders in the QA process, incorporating their feedback in real-time, thereby reducing the gap between expectations and deliverables.

Automatische Test sind sehr gut aber kein Allheilmittel. Schon für die Abnahme der Funktion sollten die Entwickler die Testung ausformulieren, der Kunde sollte den Tesfall prüfen und für die Prüfung genügend Zeit einplanen. Der Test im Labor (also auf dem Computer des Entwicklers) ist gut, aber entscheidend ist der integrierte Test auf dem Zielsystem in einer produktiv Umgebung.

An unrealistic schedule and budget can greatly impact customer expectations; these effects are generally negative: -Unmet Expectations: When a project is initially promised with an unrealistic schedule / budget, it creates high expectations for quick delivery and low costs. Customers may anticipate rapid completion and affordable prices, setting the bar unrealistically high. -Disappointment: As the project progresses, it becomes evident that the schedule and budget are unattainable. Delays and budget overruns will likely lead to customer disappointment and frustration when initial expectations are unmet. -Tension and Conflict: As disagreements arise over the project's progress, costs, and timing, tensions can escalate with the customer.

This is the most common scenario. Unrealistic schedules. Not even budgets. At some point management might decide that money is not a problem. However if a deadline is unmovable it will be the most difficult issue in the project if it's not realistic. somethings take X amount of time to be done regardless of how much money and resources are available. Unfortunately, project management theory doesn't explain clearly how to manage unrealistic expectations from management, it only points at documenting and explaining. However, in many cases management will not care about how long it is expect to take and will want it to be done either by X date or ASAP without taking into consideration how it affects other projects already on the queue.

Unrealistic scheduling and budget constraints can indeed make or break IT projects. In my experience as a Technology Manager, I've found that employing Agile methodologies can offer more flexibility and control over both time and budget. On a recent cloud migration project, we faced budget constraints and an aggressive timeline. Rather than locking ourselves into a fixed budget, we adopted a "budget-boxing" approach—allocating funds in cycles, consistent with Agile sprints. This allowed us to adapt and re-prioritize as the project evolved, effectively using the available resources. It's crucial to approach scheduling and budgeting dynamically, taking into account potential uncertainties and bottlenecks to maintain project health.

In practice, insufficient capacity and budget often can be one of the main reasons for the project's failure. If these are properly addressed at the stage of the project design, businesses will significantly mitigate their potential risks and reduce potential unexpected costs.

Technology Projects are complex and entwined in human nature! Clients need to be vulnerable about their challenges and shortcomings and then work together to manage the changes across multiple internal departments with no regard for corporate politics. Service providers need to bottle creativity and serve it up at will whilst trying to ascertain what the client needs, not necessarily what they want. Just saying it like this makes it madness to try and force this onto a simplistic and milestone-driven timeline with a rigid scope. Accept the true nature of these Projects, form a collaborative partnership between service provider and client and iterate towards the solution over time with a commercial model that enables this approach.

Missing executive sponsor and business partner. If you don’t have an executive that’s helping you to drive decision making, the project will fail. If you don’t have a good business partner who can state clear requirements and hold accountability to implementations at the business level, the project will fail.

This comes back to making sure you’re solving a real problem for real key stakeholders in the business in a practical and implementable way. If the problem exists and nobody knows it does, then one must first make people aware of it and passionate about solving it before attempting to solve it. If one does this, then there is a greater probability of involvement by all the stakeholders needed.

Get users, developer scrum-leads, test-managers in one room in order to test complex applications with many interfaces. It will boost comms in your team and shorten the back-and-forth of problem solving.

Para solucionar essa falha, é crucial priorizar o envolvimento e o feedback do usuário ao longo de todo o projeto de TI. Desde a análise inicial até a avalia??o final, os usuários devem ser envolvidos e engajados. Coletar regularmente o feedback dos usuários através de pesquisas, entrevistas e testes de usabilidade é essencial. Esses dados devem ser incorporados ao desenvolvimento para garantir que o produto atenda às expectativas e necessidades dos usuários finais. Essa abordagem centrada no usuário promove a cria??o de solu??es relevantes, compatíveis e utilizáveis, aumentando a satisfa??o do usuário e o sucesso do projeto de TI como um todo.

From my point of view, it is a second most common reason for failure of IT projects, immediately after poor scope deffinition.

Culture, Sponsorship, KPI's...... A company's culture is more than just a buzzword; it's the heartbeat of any thriving organization. A harmonized culture fosters collaboration, encouraging teams to seamlessly merge their strengths, overcoming hurdles with unified vigor. Meanwhile, executive sponsorship acts as the guiding light. With robust leadership and a clear vision, teams are empowered, knowing their direction and purpose. Yet, without well-defined KPIs, our endeavors risk becoming rudderless. KPIs are our compass, keeping us aligned with our goals and ensuring every effort brings us closer to our desired destination.

I would add that a lack of understanding of the current landscape, operational challenges, process inefficiencies and general knowledge about the business are key to effective delivery. How can you know that a project is right for your business if you don't know what is really happening? A discovery phase should form every project initiation to gather this information

Key is Buy in at all levels The stakeholder needs to articulate the "why", "what" and most importantly "why now" IT management has to articulate the "how" and the incremental "whens" All members of the organisation have to truly believe that this change fulfils the promise of a better tomorrow than what we have today. Top down edicts will only get you so far. Without Buy In (and measurable success factors) just leads to disappointment from stakeholders and burnout in the IT teams who have just endured a "Death March" project. Remember this will probably double your IT teams workload having to run the "as is" estate and build the "to be" one

Culture in the team is key. Have an agreement that you do not miss out on delivery-dates. When you bring in time all the small deliverables, the big milestones will come in time. There is an effect that prerequisites of your milestones will also be delivered in time. I felt a strong spirit in the team to deliver in time. After delivering, team was "tired but happy". Everybody could have "peace of mind" after those sprints. Weekends were "holy". Everybody could recover. That is my learning on my "One.ERP-Project", delivered in time - which was one of the biggest in Europe.

Undoubtedly you need to have the right people, doing the right things, in the right way, with the right support. And good project delivery systems can help this. But even if you get all of that humming, my biggest frustration from 25 years in projects comes down to one thing. How the senior players choose to 'step up' and interact when it comes to steering the project. Politics, lack of understanding, invisibility, disinterest, self preservation. These issues and more cause your project to fail. A SteerCo that truly knows it's role, that probes for the truth, that knows the target, that can make decisions, that can align the organisation, that can remove barriers. That is the project superpower you need.