Why IT projects fail even though processes, tools, and service providers are in place

How a lack of service provider management in a regulated environment leads to high support costs and visible problems

In many organizations, the starting point is similar: there are established processes, modern tools, and experienced service providers. And yet IT projects fail time and time again in everyday life. Systems do not function reliably, support costs rise, and the impression quickly arises that something is fundamentally wrong.

The reason for this is rarely a lack of competence or the wrong technology. In practice, a different pattern emerges: there is a lack of clear control in the collaboration with external service providers. This problem is particularly evident in regulated environments, where mistakes are noticed more quickly and have a greater external impact.

When a successful product reaches its limits in operation

One of our projects involved a SharePoint-based collaboration product that was originally introduced for internal collaboration. Due to its success, it was later expanded to include external partners and customers. Technically, the product was stable, but the real problems arose at the interfaces.

Application processes and the assignment of rights and roles ran via ServiceNow and other downstream systems. Several service providers were involved and responsibilities were distributed. In this constellation, errors occurred repeatedly that were incomprehensible to users. Externally, the effect was clear: the product did not work. Internally, this led to a sharp increase in support costs, long processing times, and growing frustration in the departments.

Finger pointing instead of responsibility

What was particularly striking was how these errors were handled. In support cases, a familiar pattern quickly emerged: everyone involved was able to explain why the cause of the error was not within their area of responsibility.

Service providers referred to upstream or downstream systems, while technical terms often obscured who was actually responsible. Support tickets were processed individually without recognizing patterns or permanently fixing causes. In the end, the feeling remained that no one was really taking responsibility and no one really knew what the underlying problems were. This is not an isolated case, but typical of IT landscapes in which several service providers work together without clear management.

Why processes and tools alone are not enough

At first glance, all the prerequisites were in place. There were defined processes, established systems, and contractually bound service providers. Nevertheless, support costs escalated.

The reason for this was not a lack of rules, but their effectiveness. Processes were in place, but they were not managed effectively. Tools were in use, but they were not established as a common working instrument. Service providers were involved without clear priorities or responsibilities.

In such situations, IT projects fail not because of technology, but because of a lack of control logic.

Control begins with an overview

A key step in the project was therefore to make the complexity manageable. This required someone who could quickly familiarize themselves with the systems and technical contexts involved and who could identify the actual contact persons behind formal roles and responsibilities.

Support cases were systematically categorized, and a clear procedure was defined and documented for typical error patterns. At the same time, the system landscape was structured and documented in a comprehensible manner, based on open and common standards – as a working basis for support, operation, and further development.

Clear control reduces friction

With increasing transparency, collaboration also changed. Responsibilities became clearer, escalations became less frequent, and errors could be identified and corrected more quickly.

The effect was measurable:

  • Support costs fell by around 30 percent.
  • Stable workflows enabled the automated provision of the external SharePoint product.
  • The product became reliably usable for users.

This also significantly improved the external image. Collaboration between the customer and its external partners became easier and more predictable.

What companies can learn from this

This project exemplifies why IT projects fail even though everything seems to be in place:

  • High support costs are often a symptom of a lack of service provider management.
  • Complex system landscapes require transparency and clear responsibilities.
  • Service providers deliver better when expectations, priorities, and processes are clear.
  • Documentation only reveals its value when it is actively used to make decisions.

Service provider management creates the basis for IT services to run smoothly, responsibilities to be clear, and problems to remain solvable.

flowciety supports companies where systems, processes, and external service providers come together—with the aim of reducing support costs, improving external impact, and making collaboration manageable.

Find out in our white paper on IT architecture how you can manage projects and services in a predictable manner with clear structures and stable foundations: from collaboration with service providers to stable operation.

Cover image source: Resume Genius

Exclusive insights for you!

Almost done! Please enter your email address and name to download the white paper.

No spam, ever.

Do you have any questions about our white paper? We are just one phone call away – feel free to contact us!