Why IT projects fail in mid-sized companies

IT projects in mid-sized companies rarely fail because of the technology. They fail because of unclear scope that only becomes obvious during implementation, a missing clear contact on the client side, changes carried out during live operations without a fallback plan, sign-off without complete documentation, and nobody clearly responsible once the project is over. In most cases the technology ends up working fine – the project still fails, because these five points were never clarified beforehand.

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 in the next ten minutes.

• 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 what response times apply or who the contact is for ongoing operations.

• 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.