Why IT projects fail in mid-sized companies

IT projects in mid-sized companies rarely fail because of the technology. They fail on five organisational points: unclear scope, no decision-maker on the client side, changes during live operation without a fallback plan, sign-off without complete documentation, and nobody being responsible once the project ends. All five can be settled before work starts, regardless of which technology or vendor is used.

Unclear scope

The most common reason an IT project spirals out of control is a quote based on too rough an idea of what's actually needed. "New network for the site" sounds clear enough, but it doesn't say whether video surveillance is included, whether production equipment should join the network, or whether a second server room is planned as redundancy. Gaps like these only become visible during implementation – and then the question is whether it's a change order or something that was originally agreed. You can usually spot unclear scope in the quote itself: if it fits on one page without a site visit ever having taken place, there's usually no real basis for a reliable estimate.

• Only have a quote drawn up after a site visit and stocktake, not from a brief description
• Put the scope of work in writing precisely enough that both sides share the same expectation
• Spell out explicitly what's not part of the project, not just what's included

No clear contact on the client side

A project needs someone on the client side who can actually make decisions and stays reachable throughout implementation – not just at kickoff and sign-off. If that person is missing, or changes mid-project without a handover, delays crop up at points that would technically take minutes to resolve: what IP address the new server should get, whether a certain area can be shut down over the weekend, who signs off on a firewall change. You can spot the problem when questions go unanswered for days, or get answered inconsistently by whoever happens to be filling in.

• Name a fixed contact with real decision-making authority for the duration of the project
• Clarify cover for holidays or illness in advance, rather than letting the project stall during that time
• Agree short, fixed turnaround times for decisions so delays show up early

Changes made live without a fallback plan

Network, firewall or server changes almost never happen while the business is standing still – day-to-day operations usually keep running during implementation. If such a change goes ahead without a defined way back, then if something goes wrong, nobody is choosing between two options – the whole site simply stops until the problem is fixed. This especially affects changes to central components like the firewall or the core switch, where a single mistake can cut off an entire site's communications. You usually only notice the missing fallback plan when it actually matters – when a change was planned but nobody can say how the previous state gets restored at short notice.

• Carry out critical changes outside core operating hours, when downtime costs the least
• Before any change to a central component, define the concrete way back to the previous state, not just the plan going forward
• For especially critical systems, run a test phase with a limited group of users before rolling the change out to everyone

Sign-off without documentation

A project is often considered finished once the technology works – documentation gets promised "once there's time", which in practice often means never. Sign-off then confirms a working state, but not that this state is understandable to anyone other than the technician who built it. The problem usually only shows up months or years later, when a change is due or another provider needs to take over and nobody quite knows how the system was put together. You can spot the risk right at sign-off: is complete documentation actually in hand at that point, or is it "coming later"?

• Require complete documentation (network diagram, configurations, credentials) as part of sign-off, not as a later add-on
• Only sign off once documentation is actually in hand and has been spot-checked
• Put the documentation requirement in the quote or contract from the start, not just demanded at the end

Nobody is responsible afterwards

Once sign-off happens, the project formally ends – but the infrastructure keeps running, keeps changing, needs updates and eventually adjustments. If it isn't clearly settled at that point who's responsible when in doubt, a gap opens up between two states: the project is finished, but no ongoing support agreement exists, or its content is unclear. In practice this often means that at the next incident, someone first has to work out who to even call – time that's in short supply exactly when it matters. You can spot this gap when, after the project ends, nobody can say who the contact is for ongoing operations or how an incident gets reported.

• Clarify before the project ends whether, and in what form, ongoing support will follow
• Put responsibility for ongoing operations in writing, even if it stays with the client
• Hold a handover conversation that names concrete internal responsibility for maintenance, updates and incidents

What actually makes an IT project successful?

A successful IT project rarely differs from a failed one because of better technology – it's better clarification up front: a quote based on a real stocktake, a fixed contact on both sides, a defined fallback for critical changes, sign-off that includes documentation, and a clear answer to who's responsible once the project ends. Clarifying these five points before the first piece of work starts reduces the risk of a failed project far more than the choice of any particular manufacturer or technology.

Before scope, there is often another question: which project should come first at all. Prioritising IT investments by operational relevance and risk, rather than by the age of individual devices, gives projects a clearer goal and a smaller, manageable scope.

How NDVDL delivers an IT project and supports it afterwards

NDVDL starts every project with an on-site visit: we look at the existing setup and talk with you about how the business actually works. That results in a written proposal with scope, exclusions, a way back for critical changes and documentation as part of sign-off. Implementation runs with one fixed contact person on our side. After sign-off, if you want, we take over ongoing operation and maintenance, so the question of who is responsible afterwards never comes up. Project and support then sit in one pair of hands as a managed service.