The IT master plan has a poor reputation in small businesses. It is associated with large groups, months of workshops and a thick document nobody rereads once it is approved. That image describes one way of doing it, not the tool itself. Reduced to essentials, a master plan answers a simple question: what digital investments will the business make over the next three years, in what order, and why?
For a small business the answer fits in a few pages. Above all it has a quality that decisions taken as they come lack: it ties each expense to a business objective, and it is reread each year to take account of what has changed.
What an IT master plan is for
An information system master plan exists first of all to arbitrate. Each year a small business receives more investment proposals than it can fund: new management software, a website redesign, a hardware refresh, an artificial intelligence project. Without a framework, they are chosen in the order they arrive, or according to the persistence of whoever champions them.
It then serves to sequence. Some projects depend on others: you do not connect a customer relationship tool to a sales management system you are about to replace. The master plan makes these dependencies visible before they cost a project redone.
Finally, it serves to explain. To partners, a bank, an investor, a buyer: a written plan shows that digital spending follows a logic, and that it has been weighed.
What it is not should be said just as clearly. It is not a catalogue of tools to buy, nor a vendor’s roadmap renamed as a business plan, nor an exercise reserved for the IT function. A master plan written by a supplier who will sell the projects it announces is not a plan: it is a sales proposal spread over three years.
The steps: current state, target, trajectory, budget
Before the steps, a question of who takes part. A small business’s master plan is built with management, which sets objectives and arbitrates; with the heads of the business functions, who know what current tools prevent them from doing; and with suppliers, consulted for what they know, not for what they sell. Written by the IT function alone, it describes what technology would like; written by management alone, it ignores what technology makes possible.
The current state
What exists: applications, equipment, suppliers, contracts, in-house skills, and what does not work. It is often built from an IT audit for a small business, whose list of prioritised decisions directly supplies the material for the first years.
The target
What the information system must make possible in three years, described from the business’s objectives rather than from tools: serving twice as many customers without hiring at the same pace, opening a second site, selling online, securing sensitive data. The target is expressed in capabilities, not in software.
The trajectory
The path between the two, broken into projects, in an order that respects their dependencies and the business’s capacity to absorb change. Several trajectories are often possible; presenting them side by side, with their costs and risks, is the best way to get management to decide — which is the whole point of building the master plan as three costed scenarios.
The budget
Each project on the trajectory receives an estimate, as investment and as recurring cost — licences, maintenance, hosting, internal time. The master plan thus ties the plan to the annual budget: each year the corresponding slice goes into the budget, and the plan is revised in light of what has been achieved.
It is this annual review that sets a small business’s master plan apart from a large group’s document. A small business changes fast: an acquisition, a new market, a key departure. A plan reread every year follows the business; a frozen plan describes it as it was.
At the end of these four steps, the document fits in a few pages:
| Section | Content |
|---|---|
| Summary | The objectives, the chosen trajectory and the overall envelope, on one page readable by a partner or a banker |
| Current state | What exists, what works, what is blocking, and the risks identified |
| Target | The capabilities expected in three years, tied to the business’s objectives |
| Trajectory | The projects, their order, their dependencies and their owners |
| Budget | Investment and recurring cost of each project, spread by year |
| Review | The date of the next review, and what would trigger an early one |
From master plan to project scoping
The master plan says what and when. It does not say how. Each project it announces still needs, when it is launched, its own scoping: the detailed need, the users involved, the constraints, the acceptance criteria, how the supplier will be chosen.
Scoping an IT project follows the same logic as a website specification: describe the problem before the solution, make suppliers’ responses comparable, set what will be received. The master plan gives it its context — why this project, now, and with what budget — which spares it from reinventing the reasons for its existence each time.
The first project deserves particular attention. It should be chosen for what it unlocks rather than for what it shows: a low-profile project that makes the next ones possible — cleaning up accounts and access rights, making backups reliable, regaining control of a contract — is worth more than a visible project resting on fragile foundations.
The link works both ways. Scoping that reveals an unexpected cost or difficulty must feed back to the master plan, which adjusts the trajectory. Without that feedback, the plan gradually drifts away from the reality of the projects.
Client-side project support: when to get help
Client-side project support — in French, assistance à maîtrise d’ouvrage, or AMOA — means assisting the client, which expresses the need and pays, in dealing with the suppliers who deliver. Its role is to defend the client’s interests: stating the need, choosing suppliers, following delivery, accepting the result.
A small business needs such support in three cases: when it has nobody in-house to fill the role, when a project is clearly bigger than any it has run before, and when the skills gap with the supplier is such that it cannot judge what it is given. In a small business without IT leadership, it is often the part-time CIO who fills that role over time, and who carries the master plan from one year to the next.
The condition, once again, is independence. Whoever supports the client must not be paid by the supplier they help to choose. That is the position Maeliom Consulting holds on these assignments: on the side of whoever decides and pays.
Common questions
Does a small business really need an IT master plan?
As soon as it has to choose between several digital investments over several years, yes — in a short form. It avoids deciding project by project, in the order proposals arrive.
What period does a master plan cover?
Three years is a common horizon for a small business: long enough to sequence projects, short enough to stay credible. It is reviewed every year.
What is the difference between a master plan and a specification?
The master plan schedules all digital investments over several years. The specification describes one specific project when it is handed to a supplier.