How to project-manage an IT change in a small business

Define the goal and the scope

Start by writing down what the project should achieve, in business terms. Staff can access files securely from anywhere is a goal; install a new system is not. Then define the scope: what is included, what is not, which people and systems are affected, and what must not be disrupted. A clear scope protects you from the project growing quietly until it overruns.

Agree how you will know it succeeded. Measurable criteria, such as all staff migrated with no lost files, the new phone system answering every number or the old server switched off by a date, make sign-off straightforward and give everyone a shared target. Write them into the quote or statement of work so the provider is working towards the same definition of done.

Give it an owner inside the business

Even when an IT provider does the technical work, the business needs its own project owner: someone with authority to make decisions, approve changes and coordinate staff. Without one, questions sit unanswered, decisions are delayed and the provider ends up guessing what the business wants. Guesses made under time pressure are rarely the ones you would have chosen.

The owner does not need to be technical. They need time set aside for the project, a clear line to whoever approves spending, and the confidence to raise concerns. In a small business this is often an owner or operations manager, and the project should be acknowledged as part of their workload rather than squeezed in around everything else.

Build a realistic plan

Work with the provider or implementer to break the project into stages with dates, dependencies and responsibilities. Include ordering lead times, data preparation, setup, testing, training, go-live and follow-up support. Identify the steps that depend on others, such as an internet provider install or a vendor migration, because those are the usual source of delays.

Build in contingency for time and money. Unexpected issues are normal, from old data that needs cleaning to a compatibility problem with an obscure application. Get a written quote that separates fixed elements from variable ones, and agree how changes to the scope will be approved and priced before work starts. A short weekly check-in, even fifteen minutes by video, keeps everyone aligned and surfaces problems while they are still small.

Test before go-live

Testing is where many small projects cut corners, and where many problems should have been caught. Before switching over, test the new setup with real users doing real tasks, check that data has migrated correctly, confirm integrations work and make sure security settings are in place. Include people from different teams, because they use systems in different ways.

Prepare a rollback plan. If the switch goes badly, how will you return to the previous setup, and how long can you wait before deciding? Knowing the fallback reduces pressure and helps the team make clear decisions on the day. Schedule the switch for a quiet time, such as a Friday evening or weekend, with enough slack to finish and test before staff return.

Communicate with staff

People cope with change far better when they know what is happening and why. Tell staff early about the project, what it means for them and when it will affect them. Before go-live, give clear instructions on what they need to do, such as signing in to a new system or saving files somewhere specific, and where to get help.

Provide training at the right level and time, ideally just before people need it. Short, practical sessions focused on everyday tasks work better than long demonstrations. After go-live, make support visible and easy to reach for the first few days, and gather feedback on what is not working. Quick fixes made in the first week build confidence in the change; complaints left unanswered quickly turn into resistance.

Close the project properly

Finish with a handover. Make sure documentation is updated, admin access is recorded in the business password manager, old equipment and accounts are retired, and support arrangements for the new system are clear. Check the success criteria and confirm whether each was met. Only then should the project be signed off. Hold back the final payment until the handover items are complete, if your agreement allows it.

Hold a short review afterwards. What went well, what caused delays, and what would you do differently? A few notes stored with the project records make the next IT change smoother and help you choose and brief suppliers better next time. Share the review with the provider as well, because a good one will want to know what could have gone better from your side.