A new server, a move to Microsoft 365, a phone system changeover, an office move. Few IT projects begin with the intention of running late. Yet plenty do. Deadlines slip, costs creep and the job that was meant to take a fortnight is still going a month later.
Usually it isn’t because anyone was careless. It’s because the same handful of things get overlooked at the start.
The scope was never properly pinned down
“Move us to the cloud” can mean many things. Does it include email, files, line-of-business software, printers and phones? If different people picture different outcomes, extras quietly creep in, and each one adds time and cost.
Agreeing in writing exactly what’s included, and what isn’t, is one of the cheapest ways to protect a project.
Nobody looked closely at what’s already there
Most businesses have systems nobody fully remembers setting up: a forgotten server running one crucial application, a printer that only works with an old configuration, a connection between two programmes that a former colleague arranged years ago.
Even a simple inventory of devices, software, licences and connections gives everyone a more realistic starting point. Without one, these tend to surface halfway through a project as unwelcome surprises. A proper discovery phase before committing to a timeline costs far less than finding them mid-job.
Dependencies are underestimated
Changing one thing often touches several others. A new email setup can affect domain settings, security tools, phones and third-party software. And some of the biggest delays come from outside your business entirely: waiting for a broadband provider to complete an order, or for a software supplier to respond.
If a plan assumes everyone replies on time, it’s an optimistic plan. It helps to list every third party involved at the outset, along with how long each typically takes to respond, so the timeline reflects reality.
The people side gets forgotten
Technology is only half of any project. Staff need to know what’s changing, when it’s happening and what it means for their day. They need time to learn new tools and to test that things work as they should.
Appointing a couple of enthusiastic colleagues as early testers can help, as they spot problems quickly and become useful advocates among the team. A technically flawless project that leaves everyone confused is not a success. And if testing is left to “whenever we have a spare moment”, it usually doesn’t happen until something goes wrong.
The timing was never ideal
Starting a project in the busiest week of the month, or just before a holiday, is a recipe for compromise. Key people are unavailable, testing gets rushed and problems arrive when nobody has the time to deal with them. A slightly later start with the right people available often finishes sooner.
There’s no contingency and no plan B
Many project budgets assume everything goes right. In reality, something rarely does. Building in some contingency, for both time and money, turns a surprise into a manageable event rather than a crisis.
It’s also worth asking a simple question: if the changeover doesn’t work, how do we go back? A rollback plan is the project equivalent of a seatbelt. You hope not to need it, but you’ll be glad it’s there.
Nobody owns the decisions
Projects stall when decisions wait for sign-off from someone who’s too busy to give it. Having one person on the business side who can answer questions and make decisions keeps momentum going. Without them, small queries turn into long delays.
What helps projects finish on track
None of this is complicated, but it does take discipline at the start:
- Define the outcome: be clear about what you want and how you’ll know it has been achieved.
- Invest in discovery: understand the current environment before promising dates.
- Work in phases: smaller stages are easier to manage, test and correct than one big switchover.
- Allow contingency: assume something will take longer than expected.
- Plan for people: include communication, training and testing in the timetable.
- Agree how changes are handled: new requests should be considered, priced and approved, not slipped in.
- Choose experience: someone who has delivered similar projects will spot problems before they become expensive.
Honest planning beats optimistic planning
The projects that run smoothly aren’t necessarily the simplest ones. They’re the ones where someone asked awkward questions early, wrote down the answers and planned for the things that might go wrong.
A realistic timeline can feel less appealing than an optimistic one at the start. By the end, it’s almost always the one you’ll be glad you chose.
It’s also fair to expect your IT partner to tell you when something is going off track. Early bad news is manageable. Late bad news is expensive.
Planning a major change to your IT? Provident IT Solutions can help you scope, plan and deliver your project properly, with fewer surprises along the way. Find out more about our IT Projects service or get in touch for a friendly, jargon-free chat.
