If your technology roadmap is just a list of projects the IT team wants funded, leadership is working from a wish list.
That will not help you decide where capital goes.
A real roadmap tells you what to do now, what to sequence later, and what to stop doing.
At its core, a roadmap is a business tool. It should help the company improve growth, margin, resilience, and execution. It should also help leadership avoid expensive noise. That matters even more in a mid-sized company, where budget is tighter and the bench is usually thinner.
The failure rate is high. McKinsey says 70% of large-scale transformation initiatives fail to meet their stated objectives. At the same time, the upside is huge. The top 10% of digitized incumbents capture about 80% of the total digital profit pool in their industries. The gap between those two numbers comes down to discipline.
I have spent more than 20 years doing this work across four continents, including as CTO at Shoppers Drug Mart and Loblaw. I founded Narrative Group to bring that kind of enterprise thinking to mid-sized companies. What leadership needs is a clear way to make sound funding decisions.
Start With One Question: How Do You Actually Make Money?
This is always my first question:
How do you actually make money?
Once you follow the money, the patterns show up quickly.
If I do not understand how the business creates value, I cannot help build a useful roadmap. I may be able to recommend tools. I may even recommend good tools. But I am still guessing.
I look at the business in two parts. First, there is the primary value chain: how the company sells, delivers, services, and collects. Then there are the supporting functions around it. Finance, HR, IT, compliance, and operations support all matter. They just matter in a different way.
A roadmap has to connect technology spend to one of those two areas. Either it improves how the business makes money, or it helps the support functions do more work with less friction, lower risk, and better control.
If you skip this step, you end up with technical architecture in conflict with the value chain.
I have seen the upside when this is done properly. At Loblaw, when we introduced an IT strategy, a roadmap, and a governance model, we aligned more than $300 million in capital spend to the enterprise strategy. That happened because we started with the business model, not with a pile of vendor presentations.
If you are a CFO, this should sound familiar. A global CFO/CIO survey found only 20% of CFOs were happy with the results of recent IT investments, while 72% said they were leading or approving the IT budget. The money decision is already sitting in the finance office. The roadmap needs to speak that language from day one.
Build the Baseline Before You Spend
Start with the financial facts
This is where I use a Financials First approach.
Before I recommend anything, I want to know how the company spends money on IT, how it uses capital, how much downtime it had, where the manual work sits, and what the service levels actually look like.
Ask a plain question:
What did downtime cost last year?
Not in theory. In lost hours, lost orders, delayed billing, reduced service, and frustrated people.
A high-impact outage now costs a median of $2 million per hour. Most mid-sized companies will not feel that exact number, but the principle is the same. If people cannot work, sell, ship, or serve, the business is bleeding money. And if you can see issues earlier, the economics improve quickly. Organizations using full-stack observability cut their outage costs roughly in half.
I have also seen what happens when leaders try to save money in the wrong place. They cut software spend and push the work into people. Then the labor line climbs, the process slows down, and innovation gets stuck in old habits.
One company kept an old Mail Manager tool to save emails into SharePoint because it wanted to avoid Microsoft licensing costs. Later, that one decision complicated a Windows 11 upgrade. The cheap answer became an expensive problem.
When you get the baseline right, you can build a much cleaner path forward. We did this for Canada’s largest provider of equipment for people with physical disabilities. By moving its IT function into a predictable evergreen model, service became more reliable, future spend became more predictable, and IT spend dropped from 3.5% of revenue to 2% of revenue while still supporting growth.
Map the data flows and the work
Once I understand the money, I want the picture.
What systems are in play? Who is talking to whom? How often? Where is data re-entered? Where does a person wait because one system never told the next system what already happened?
This is where many technology plans break down. People talk about applications. They do not talk enough about flow.
How does information move?
How does work move?
Where does the process stall?
Take a common example. Your e-commerce platform and your store inventory are out of sync. Where do you begin? You begin with the business model. Are you picking orders from stores? Are you fulfilling from a central distribution point? Does inventory need to update by location in real time?
Draw it out. The picture tells a thousand words.
At Narrative Group, we do exactly that in discovery. We map how data moves through the company and how the value chain is actually executed. We also go on site. We look for physical bottlenecks, visual clutter, and the little workarounds people have stopped talking about. Those things usually tell you where the documented process and the real process parted ways.
Listen to the people doing the work
Then I want to hear from the people closest to the process.
Show me the day in the life.
Show me where the frustration starts.
Show me where the technology is letting you down.
Most of the time, the signal is clear. You find role-definition problems, or you find technology not doing what the company is asking it to do. Either way, the roadmap gets better when you listen.
We had a client with six offices whose people could not connect reliably when they moved from one office to another. Their meeting rooms barely worked. Every request to IT got stuck behind a security excuse. We stabilized the infrastructure office by office, replaced core network gear and outdated servers, put devices on a lifecycle plan, and fixed the meeting room experience.
Talk is cheap. Actions speak volumes.
Three years later, the managing director told me everyone wanted the rest of the offices to look like the one we had rebuilt.
Decide What Is Unique and What Is Commodity
This is one of the hardest parts for leadership. You have to be specific and ruthless about where you are truly different.
I look at every process through three lenses. Some things create competitive advantage. Some things are table stakes. You need to be good at them because everyone else is. And some things are commodities. They simply need to work.
Your roadmap should treat those categories differently. Unless your company’s product is technology itself, what makes it unique is the people, not the technology. Core functions like master data management, inventory logic, and e-commerce process flows are very similar across companies in the same sector. For those things, use vanilla software. Stay current: mainstream, not leading edge or bleeding edge.
Cheap custom work creates hidden risk. I have watched companies rely on temporary contractors or co-op students to build software fast and cheap. It works for a while. Then the business grows. Nobody understands the code. The fixes get slower, the risk gets bigger, and the bill shows up later. The same thing happens when you underinvest in software and make people do the work manually. Human labor becomes the most expensive item on the profit and loss statement.
I also believe IT is effectively two departments. One part is commodity operations such as desktop support, network support, and foundational infrastructure. Much of that can be outsourced. The other part should stay focused on learning the business and driving the work that creates enterprise value. That same survey found 44% of CIOs are investing in emerging technologies while 36% are outsourcing application support. That split makes sense to me. Treat commodity support like a commodity. Keep your internal attention on the work that drives value.
Define Outcomes in Business Terms
Once the current state is clear, define the target state in plain business language.
Reduce order cycle time.
Improve uptime.
Increase first-time-right data.
Cut intervention rates.
Lower compliance risk.
Support growth without hiring at the same rate as revenue.
The biggest hurdle to scaling quickly is productivity. That is why the first levers I usually pull are standardization and automation. If the business wants to double its customer base over the next 24 to 36 months, can the current operating model handle it?
If the answer is no, the roadmap has to show how you fix that.
I measure productivity using the client’s own operating metrics. If a task takes 20 hours today and five hours tomorrow, that is real value. If the company works on fixed-price bids, using less labor to deliver the same work goes straight to margin.
At Shoppers Drug Mart, when we re-engineered the IT function through Project Symphony, Productivity improved by 40% year over year, based on output relative to total invested capital. That is the kind of number leadership can use.
Self-checkout is another good example. At Shoppers Drug Mart, we piloted it in two stores with a very simple user experience. It worked because the interface was easy to use and the intervention rate stayed low. That led to rollout approval across hundreds of stores.
At Loblaw, the intervention rate was so high that we had to rewrite the entire front-end experience.
Same idea. Completely different result.
The business outcome was throughput, labor leverage, and a smoother customer experience.
This is why I get cautious when someone says, “We need a big upgrade because the system is old.” Old may be true. Value still has to be proven. Only 23% of surveyed CFOs rated ERP upgrades or migrations as delivering high value. Innovation is making the operation of a business model elegant. It still has to move the business.
Sequence the Investments
Decide what happens now, what happens later, and what should stop
A roadmap has to answer three timing questions:
- what gets funded now because it removes a real constraint
- what gets sequenced later because the value is real but the dependencies are not ready
- what should stop because it will not pay back or because the process underneath it is broken
Start with the boring foundational functions. I mean that seriously.
If the network is unstable, the identity controls are weak, the devices are aging out, the master data is poor, or the meeting rooms do not work, start there.
At Loblaw, we introduced manufacturing-oriented infrastructure-as-software principles and cut provisioning from six weeks to one day. That kind of work is not flashy. It matters.
Then move into the higher-value programs. At Narrative Group, we usually organize the roadmap into a small number of themes, usually three to five. We balance longer-term ROI work with quick wins. Quick wins matter because they build trust and credibility inside the business.
I am very rarely in favor of a big-bang rollout. We assess. We test. We pilot. Then we scale.
There is nothing like real-world experience.
I learned that in a large loyalty rollout where the technology worked for a small group and then fell apart when we had to test it for millions of users hitting the same endpoint. Performance testing delayed the launch by several months. Painful, yes. Still far better than a production disaster.
At Loblaw, we completed more than 60 proofs of value in about 18 months, and more than 10 went to scale. That included self-checkout at Shoppers Drug Mart and robotic process automation across four functional areas that generated more than $10 million in annualized savings. That is how you reduce risk and still move.
Sometimes the roadmap has to say yes, but later. We are working with a payments provider in the traveler registration space where the payment platform has PCI, GDPR, and PIPEDA issues. Those issues matter. We still sequenced other scope first because it had a more immediate impact on operations and value. The roadmap gave leadership a clear basis for that call.
And sometimes the roadmap has to say no. Vendors will promise an all-singing, all-dancing tool. They will start talking in ambiguity. When the rubber hits the road, the missing business rules and messy data show up.
Put Governance Around the Money
A roadmap is not just a planning document. It is a governance document.
It tells leadership who owns the decision, how success will be measured, and when the company will review progress.
What gets measured gets managed. So measure the things that matter:
- IT spend against revenue and operating expense
- the ratio of IT labor to non-labor spend
- uptime and downtime
- cycle times
- intervention rates
- project delivery performance
Those measures belong in board-ready reporting.
At Narrative Group, we use a model that shows business leaders the contribution IT is making year over year. That matters because it changes the conversation. IT stops being a vague cost discussion and becomes a value discussion.
This also matters to boards and investors. In one engagement with a startup insurance distributor in Canada and the United States, part of our work was to identify and clearly communicate the use of funds within IT for a Series B or C raise. That governance discipline supported a $100 million raise and prepared the IT organization to scale. In another engagement, improving project execution for one of Canada’s leading reverse mortgage lenders contributed directly to enterprise value and valuation.
Technology choices show up in the balance sheet.
The good news is that the leadership connection is improving. 86% of CFOs and CIOs say their collaboration has strengthened. Keep going. The roadmap should be owned by leaders with skin in the game. My job is to give them enough information to make the decision and then help execute it.
Bring People With You
Even the best roadmap dies if people do not buy in.
This starts at the top. If the senior leaders are engaged, they help prepare the organization for change. In mid-sized businesses, especially privately held ones, the owners and senior executives are often embedded in the operation already. When they move, the company moves.
You also need empathy on the ground. When store managers or line managers see a technology team coming, many assume the team is there to judge them or automate them out of a job. That is the wrong starting point.
We are there to help because the technology is letting them down.
So listen first. Ask them to show you how the day actually works. Ask where the friction is. Ask where the handoff breaks. Once they start showing you, you have to follow through. If they take the risk of opening up and you do nothing with it, the trust is gone.
If someone is going to struggle with change, deal with that early and at the executive level. Do not ignore it. Leaders have to own those calls. My job is to give them enough information to make the decision and then help execute it.
Use AI Where It Actually Helps
AI belongs in the roadmap, but with discipline.
I am optimistic about it. I am also cautious. AI is a very good liar, and a lot of what is being sold today is not ready for prime time if you leave it unsupervised.
The pattern I see is familiar. The same global survey found 87% of CIOs are heavily investing in AI, while 94% say their data still needs major cleanup for those initiatives to succeed. That is exactly the problem. You cannot just codify broken business processes. Garbage in, garbage out still applies.
Where AI can help is in long-running workflows, better data quality, and decision support. We are doing work in those areas right now. In one case, AI and workflow automation took an e-commerce product setup cycle that had been consuming roughly three weeks of one person’s time inside a five-week cycle and brought it down to about four hours. That kind of improvement creates capacity. It frees people to move into higher-value work.
Final Thought
A good technology investment roadmap gives leadership a clear basis for decisions. It shows where money goes, what value is expected, what risks need to be managed, and what gets measured along the way.
If you follow the money, map the value chain, listen to the people doing the work, and sequence the investments with discipline, the roadmap becomes a growth tool. It moves the company away from reactive spending and toward intentional investment.
That is the whole point. Build a roadmap your business can actually execute. Focus on the things that actually drive enterprise value.
Frequently Asked Questions
How should we present our technology investment roadmap to the board of directors?
With 72% of CFOs leading IT budgets, it’s best to present it as a capital allocation strategy, not a feature list. Boards want to understand the expected effect on margin, risk, growth, and execution.
How often should executive leadership revise the technology investment roadmap?
Review sequencing, dependencies, and capital allocation regularly, often quarterly, while keeping the core business outcomes steady.
Where does cybersecurity fit within a strategic technology roadmap?
Security is foundational. A high-impact outage costs a median of $2 million per hour. Security should be addressed early enough to protect the business from operational and financial disruption while enabling the rest of the roadmap.
How do we balance funding new innovations against replacing legacy systems?
Base the decision on business value, dependency, and risk, not just system age. Only 23% of CFOs rate core ERP migrations as high value. Some legacy systems deserve stabilization before replacement.
How should a technology investment roadmap adapt during mergers and acquisitions?
McKinsey notes 70% of large transformations fail. To beat those odds, reassess the combined value chain, identify duplicated systems, stabilize the foundations, and then re-sequence investment based on the new business reality.