IT organizations have worked hard to get away from the problems that had plagued their past project delivery processes.\n\nThey have replaced expansive scopes, the waterfall methodology, and long timelines with iterative development, the agile approach, and multiweek sprints, hoping to avert the big failures that have littered IT\u2019s history.\n\nThose changes have indeed helped, but many IT projects still fail.\n\nTrue, project failure no longer brings down the whole IT environment \u2014 as it might have done a few decades ago. Nor does it typically mean a new system doesn\u2019t work at all and needs to be completely scrapped, another scenario from IT\u2019s checkered project-delivery history.\n\nInstead, failure today means an IT project doesn\u2019t deliver some or all its expected benefits, according to CIOs, project leaders, researchers, and IT consultants. Or failure may mean a project doesn\u2019t produce returns, runs so late as to be obsolete when completed, or doesn\u2019t engage users who then shun it in response.\n\n\u201cToday, with the advances in agile, the definition of \u2018failure\u2019 has morphed,\u201d says Te Wu, CEO and chief project officer of PMO Advisory, an associate professor at Montclair State University, and a Project Management Professional (PMP) who also serves as co-chair of the Project Management Institute\u2019s development team on the portfolio management standard.\n\nIn other words, IT project failure now is more about missed marks than technological disasters.\n\nSome studies bear that out. According to KPMG\u2019s 2023 Technology Survey, 51% of the responding 400 US technology executives said they have seen no increase in performance or profitability from their digital transformation investments in the past two years.\n\nSurveys and studies are inconsistent on the rate of IT project failures, but researchers confirm that the percentage of IT projects falling short continues to be higher than hoped.\n\nSo what\u2019s going on? Why do IT projects continue to fail? There are some common culprits.\n\n1. Lack of project management expertise\n\nWorkers are often tapped to take on extra work, and for IT workers that sometimes means being tasked to lead projects.\n\nBut those workers don\u2019t necessarily have the expertise, training, or experience necessary to succeed in the project manager role, nor are they given enough time to learn what it takes to manage a project or to complete the extra project management tasks.\n\n\u201cWe expect people who have no training to run projects. Or we expect managers who have a full-time job doing something else to also manage a project,\u201d says Zach Rossmiller, CIO for the University of Montana.\n\nRossmiller knows the consequences of that approach as his IT department has had a history of doing as much.\n\n\u201cWe\u2019d have a couple hundred different projects going on and were expecting our managers to run them and run them efficiently,\u201d he says. \u201cIf we had a project management office dedicated to running projects, I think we would have been a lot better off.\u201d\n\nRossmiller is addressing this situation, with IT recently adding two project managers to its team. The addition of trained project management professionals is already delivering improvements, Rossmiller says, particularly in streamlining efforts and making project delivery more efficient.\n\nThat\u2019s because trained project managers are better able to corral and schedule resources, coordinate staff schedules, and get everyone moving in the same direction \u2014 and do so across multiple projects, he says. They\u2019re also more capable of implementing the governance needed to keep projects on target to deliver what\u2019s expected and not let scope creep run up costs and schedules without adding additional value.\n\n2. Little or no executive support\n\nAnother leadership problem that can tank an IT project: top-level indifference.\n\nThat scenario happens more than it should, veteran project leaders say.\n\n\u201cWe have had meetings and project status reports where executives were asking, \u2018Why are we doing this?\u2019 They truly didn\u2019t grasp the importance of where we were going,\u201d says Karla Eidem, a Project Management Professional and PMI\u2019s North America regional operations manager.\n\nEidem says a lack of executive support can happen even when the project has a business unit sponsor \u2014 a situation which indicates that the project, while maybe a localized priority, isn\u2019t aligned to organizational goals.\n\nIn such cases, there\u2019s a need to realign.\n\n\u201cIt may mean asking the [executive team]: Given all the facts that are laid in front of you, is this project a go or no-go? Sometimes it is a no-go for some reason, but that decision has to be made,\u201d Eidem says, explaining that executive support is crucial for success because it ensures that the resources \u2014 money, people power, attention, and so on \u2014 will be made available.\n\n3. No business sponsor accountability\n\nSimilarly, releasing the project\u2019s business sponsor from accountability for the tech project\u2019s success \u2014 and putting it all on IT \u2014 can doom the project.\n\n\u201cYou really want to have good project leadership, and that starts with the person who wrote the business case being the sponsor, making sure the project is done realistically and being a champion,\u201d Wu says.\n\nBusiness sponsors, like executives, play an important role in articulating the business reasons for the project, establishing the expected benefits, and rallying resources to the cause. Their support also signals to staff the project\u2019s importance, which helps drive adoption of new technologies and any associated process changes, Wu adds.\n\n4. Lack of business sponsor engagement\n\nA supportive and informed business sponsor can remove roadblocks and bottlenecks that arise, they can escalate problems to help get them solved quickly, and they can champion successes to build momentum and excitement for the changes ahead, Eidem says.\n\nThose benefits go away when a business sponsor is MIA.\n\nEidem has seen that happen.\n\nShe was working on a complex multilocation software implementation that was steadily progressing until she needed that business sponsor to bring together regional divisions for the next step in the process. The sponsor dropped the ball on that, leaving some operational teams in the dark about what was happening and others questioning why they had to participate.\n\n\u201cWe were seeing that information wasn\u2019t cascading, and there was some resistance in some areas,\u201d Eidem says, adding that the situation jeopardized the project\u2019s forward momentum.\n\nEidem says she discovered that the business sponsor had been pulled away from the project by another big issue and as a result wasn\u2019t as attentive as needed in delivering information about the project to the impacted regions.\n\n\u201cI needed the sponsor to be focused on this project, but he had too many other priorities. So I had to be clear: As an organization, we said this project was the No. 1 priority,\u201d she says.\n\nTo prevent the project from collapsing, Eidem scheduled more one-on-one meetings with the sponsor to build a stronger relationship and to allow for more direct communication about the project\u2019s needs, which helped refocus the sponsor and get the project rolling again.\n\n5. Not involving all stakeholders\n\nIT project manager Krista Phillips recounts one case in which a large multinational corporation implemented a new technology across its companies but caught one division completely unaware of the ongoing implementation work.\n\nTurns out that specific division had been left out of all the planning and project processes.\n\n\u201cI don\u2019t know how the [project leaders] missed that, but they missed a whole unit. So when the system went live, they were like, \u2018What is this?\u2019 That caused the project team to miss scope,\u201d says Phillips, a PMP holder serving as president of PMI\u2019s Pikes Peak Regional Chapter in Colorado.\n\nPhillips acknowledges that project teams don\u2019t usually overlook entire divisions, but they sometimes fail to identify and include all the stakeholders they should in the project process. Consequently they miss key requirements to include, regulations to consider, and opportunities to capitalize on.\n\n6. Not enough resources or not the right ones\n\nSome project leaders list the prevailing do-more-with-less expectation as another reason for failed IT projects today. They say this mentality generally leads to project teams lacking the resources that they need to get the desired work done on time.\n\n\u201cEverybody is very concerned with that bottom line, and they should be concerned about that, but the other side of that is they\u2019re expecting a few people to do a lot of things,\u201d Phillips says.\n\nFor example, she says workers are frequently assigned to multiple projects simultaneously, and many are assigned to that project work on top of their existing duties. As a result, these workers are pulled in too many different directions.\n\nOthers say enterprise leaders underestimate costs and the time required to complete the work or they fail to allocate the right talent to the team (thinking untrained or inexperienced workers will develop the required skills on the job), even as project managers surface the consequences of under-allocating the money, talent, and time needed for success.\n\nExperienced project leaders say it\u2019s crucial for IT project managers and CIOs themselves to ensure that the business sponsors and C-suite executives get the information they need to be realistic about the required resources, support, and schedules.\n\nThose project leaders, however, also acknowledge that\u2019s a continuously tough task.\n\nTo help, they advise implementing a portfolio management program to bring visibility into all the work happening and to break down project siloes that can sometimes contribute to that under-allocation of resources.\n\n\u201cAn emphasis on portfolio management can close a lot of the productivity pain,\u201d Wu says. \u201cDo fewer things, too, and do them well; that\u2019s a hallmark of portfolio management.\u201d\n\n7. Lack of in-person collaboration\n\nWu acknowledges the benefits that the shift to widescale remote work has brought, such as the ability to scale project work globally. But he also sees how the virtual work environment can create pain points in project delivery.\n\nTo start, Wu says he has found virtual teams have a harder time coming together to solve the harder problems. \u201cI think when it comes to tackling module tasks, virtual is good. But solving big, complex problems, there\u2019s only so much you can do over Zoom,\u201d he says.\n\nWu says he also sees some teams struggle to bond in virtual work environments. \u201cYou sacrifice the human connection,\u201d he adds.\n\nConsequently, Wu says work can take longer; solving a problem that would take an hour working together face to face might take 90 minutes in a virtual environment. And handoffs that went quickly and smoothly when teams were physically side by side now often require more time to coordinate across computer screens.\n\n\u201cPeople are spending more time to get to the same net effectiveness, and I think human relationships are starting to fray,\u201d he says, noting that newer employees in particular may be missing out on the informal mentoring and learning that happens in person when they can readily see good role models and good work patterns to emulate.\n\nWu says these dynamics in turn put more work onto project managers who must \u201cput in far more work and time to be collaborative and to communicate,\u201d adding that he hasn\u2019t yet seen any remedies to these challenges. \u201cI know the problem, but I don\u2019t have a solution,\u201d he says.\n\n8. Disjointed handoffs\n\nAt some point a project moves into production, project managers move on, and the IT initiative is then expected to show its value.\n\nThose steps in many organizations mean that projects \u2014 and any remaining problems with them \u2014 are still being tossed over the fence, leading to disjointed accountability that does not lead to success, Wu says.\n\n\u201cIf the business case is one party, and the project manager is another party, and then people managing the results of the project, who are even further removed from the business case for the project, are another party, then you can see the disjointed connections,\u201d Wu says.\n\nThat disjointedness can mean missed opportunities, wrong turns, and miscommunications that lead to final products that are suboptimal.\n\nWu says that disjointedness can happen even in organizations using Agile and DevOps methodologies, saying that those \u201care just different ways of carrying the water from one side to another.\u201d\n\nHe adds: \u201cDevOps can address a change very quickly, but whether that change is the right change or if it delivers ROI is a very different question.\u201d\n\nTo counteract that, Wu and others point to the need for good management and strong project governance that continually link the project\u2019s business case to its deliverables throughout the project work as well as through the implementation and adoption phases.