A master plan is not a shopping list. For a transport business, it is also a plan for how drivers, dispatchers and depot teams will change how they work.
In brief
- An IT master plan links business goals to a sequenced set of technology decisions over about five years.
- In transport and logistics, the plan succeeds or fails on adoption: whether drivers, dispatchers, depot and warehouse staff actually use what is introduced.
- It has five parts: goals, current state, principles, roadmap and governance.
- The most common failure is a plan that lists systems but never says in what order, or how the people on the road and in the yard will be brought along.
Many IT master plans are thick documents that are produced once, approved, and then left in a drawer. A year later the fleet has grown, a customer has changed its requirements, and nobody can say which parts still apply.
In transport and logistics the gap is wider. A new system can be bought in a month. Getting it used on every vehicle, at every depot, across every shift takes far longer.
The real issue is not technology. It is sequence, reasons and adoption.
Every operator has more good ideas than budget, people or time. A master plan does one job: it decides what comes first, what waits, and what is deliberately left out, and records why. Without that, the loudest request or the most recent vendor visit sets the agenda.
For operators with drivers, dispatchers and depot teams, the plan must also say who has to change what they do, when, and what support they get. A tracking tool nobody updates is a cost, not a capability.
Five parts of a useful plan
| Part | Question it answers | What it should contain |
|---|---|---|
| 1. Business goals | What is the organisation trying to achieve? | Three to five goals in business language, such as on-time delivery, utilisation or cost per trip |
| 2. Current state | What do we have, and how well does it work? | A one-page map of systems, owners, costs and known problems, including the ones kept on paper or in chat groups |
| 3. Principles | How will we make technology choices? | Short rules, such as “buy before build”, “one source for each kind of data” or “it must work on a driver’s phone” |
| 4. Roadmap | What happens, and in what order? | Initiatives sequenced by dependency, value and the capacity of operations to absorb change |
| 5. Governance | Who decides, and how is it kept current? | An owner, a yearly review and a way to approve changes |
Building it step by step
1. Start from the goals, not the systems
Ask leadership what the next five years must deliver: growth, cost, service, compliance. Each initiative later in the plan should trace back to one of these. If it cannot, question it.
2. Draw the current state honestly
List the systems, who owns each, what they cost, what depends on them and where the pain is. Include the informal ones: the spreadsheet a dispatcher trusts, the chat group that runs a depot. This map is often the most valuable page, because few people have ever seen it in one place.
3. Write the principles before the roadmap
Principles make choices faster and more consistent. They also protect the plan when a new proposal appears that does not fit.
4. Sequence by dependency, value and adoption capacity
Some work must come before other work (shared master data before route optimisation, for example). Among the rest, rank by business value and by how much change drivers, dispatchers and depot teams can absorb at once. Roll out to one depot or route first, learn, then widen. Be explicit about what is deferred.
5. Plan the first year in detail and the rest in outline
Year one should have owners, budgets, dates and a training and support plan for the people who will use it. Years two to five should state direction and assumptions, not false precision. Each year, reset the detail for the next one.
Five mistakes we see repeatedly
- A shopping list. Systems with no reasons or order are not a plan.
- Forgetting the people on the road. A system that adds work for drivers without helping them will be bypassed.
- Rolling out everywhere at once. One depot or route first, then learn.
- No owner. A plan owned by “IT” is not owned by anyone who can trade off priorities with operations.
- Fixed for five years. Review yearly, and say openly what has changed.
How we think about it
We build the pieces that IT master plans depend on: connected systems, data migration and shared data foundations that stay trusted over time. That experience shapes how we read a roadmap: we look first at how systems connect and where data is trusted.
We can explore a first-year roadmap with you, starting from a one-page map of your systems.
Which system would you most want on that map?
A plan you will actually use
A good master plan is short enough to be read, specific enough to say no, and reviewed often enough to stay true. If yours is long, undated and unowned, start the next version with a single page: the goals, the current map and the first year.
Talk to Balerion about shaping an IT roadmap that fits your goals, your operations and your priorities. Email us at talk@balerion.co.th.
