In my previous article on technology assessments, I explained how to diagnose what’s actually broken in your technology platform. Companies typically conduct assessments for one of two reasons: either they’re experiencing technical issues with their current platform and need to identify root causes, or they need to add new business capability and want to determine how suitable their current platform is, and identify the technical gaps they’ll need to address.
Whatever the driver, you’ve now completed your assessment. You’ve identified key critical technology issues that need to be addressed. Your software is unreliable. Your infrastructure can’t scale. Your technical debt is paralyzing your development team. In other words, you know what’s broken.
Next comes the hard part. Your CTO wants to fix everything immediately. Your CFO is asking how much this will cost and whether you really need to spend that much. Your CPO is frustrated because they just want to ship features, not rebuild infrastructure. And you, as CEO, are caught in the middle, trying to figure out how to get budget approval for a multi-million dollar, multi-year technology investment when you can barely articulate what you’re getting for that money.
This gap between knowing what’s broken and actually fixing it is why most technology initiatives falter. Assessments identify problems. Traditional roadmaps might sketch out some vague timeline. But they don’t answer the questions of how to prioritize and sequence the work, what it will actually cost, or when you’ll start seeing value. Without answers to these questions, you can’t get funded. And without funding, your assessment findings become nothing more than an expensive monument to good intentions.
In this article, you’ll learn:
- Why traditional roadmaps fail to get funded and what makes a plan actually fundable
- The four components of a Multi-Release Technology Plan (MRTP) that enable board approval
- How resource modeling and scenario planning turn vague initiatives into concrete investment decisions
- Why honest planning means accepting that your first proposal will never be your final plan
- How to structure a plan so executives can approve it without understanding every technical detail
- When internal teams can create these plans themselves and when you need external help
The gap between knowing and doing
When we complete a technology assessment, we deliver a detailed analysis of what’s broken and why. We identify architectural gaps, process breakdowns, organizational misalignments. We prioritize the findings into immediate, high, and medium priority categories. And we describe the target state architecture – what your technology platform should look like when you’re done fixing things.
The next step is to create a detailed roadmap for how to get from your current state to that target state, what it will cost to make the journey, and when you can expect to see business value along the way.
That’s what a Multi-Release Technology Plan provides. It bridges the gap between diagnosis and execution. Without a fundable plan, there’s no way to move forward. You can’t go to your board and say, “We need to do digital transformation.” They’ll ask three questions you can’t answer:
How much will this cost? Not vague estimates like “a few million dollars,” but actual models based on resource requirements and realistic timelines.
When will we see value? Not “in three years when it’s all done,” but incremental milestones where specific business capabilities come online.
What if we can’t afford to do everything? What are our options? What trade-offs can we make? What’s the minimum viable transformation that’s still worth doing?
A Multi-Release Technology Plan answers all three questions.
We worked with a digital media licensing company a few years back. The assessment identified fundamental data architecture problems that were preventing them from scaling. Based on the resources available at the time, we presented a twenty four month roadmap to modernize their platform. The company couldn’t sell a two-year investment to their stakeholders. It was too long, with too much uncertainty, and too much money tied up before seeing any return.
We compressed the plan to eighteen months by cutting scope and increasing resources. Even that was a hard sell internally. But the plan provided value. It forced honest conversations about what was actually required. It created organizational alignment around realistic expectations. When reality diverged from the plan – which it always does – the company had a framework for making informed decisions about how to adapt.
What makes a plan fundable
A Multi-Release Technology Plan has four core components. Each one addresses a specific question that decision-makers need answered before they’ll approve funding for a major technology initiative.
Component 1: Target state architecture
We use a layered approach that connects strategy to implementation. Different types of stakeholders are interested in different parts of this, usually focusing on the layer most relevant to them. Your COO and CFO will look at the high-level diagrams to understand conceptually what you’re building and how it drives the outcomes they are looking for. Your CTO and technical leads will dig into the detailed specifications to validate that the approach is sound and to understand how it affects the current technology landscape.
It starts with the Business and Context Layer, where we map high-level interactions, workflows, and user journeys so the system design aligns with real business goals.
Below that sits the Domain and Functional Architecture that describe the system capabilities and workflows.
The Data Architecture defines the logical data model, data stores, and governance. We emphasize clarity here early, changing your data model later often means painful migrations and ripple effects across every service. The target state architecture needs to take into account the team’s technology stack and expertise.
Next is the Application and Integration Layer, detailing service boundaries and interfaces, and integration patterns, including cross-platform authentication and authorization models. The Security Architecture describes data security models and where applicable compliance mapping.
Finally, we anchor everything in an Infrastructure and Operations Layer, specifying cloud topology, Infrastructure as Code, CI/CD pipelines, monitoring, and observability. These elements are notoriously hard to bolt on after the fact; building without them is like flying blind when something breaks.
The target state architecture defines what you’re building in enough detail that your team could actually start building it. The architecture section is detailed enough that you could convert the components into epics within your agile framework, then break those epics down into user stories. We’re giving you everything you need to build this thing on your own, besides actually writing the code and setting up the databases.
Component 2: Incremental future states
You can’t just describe the end goal. You need to show the path to get there, broken into releases that each deliver meaningful business value.
We talk about this in terms of incremental future states. You have a target state where you want to end up, but you’re not going to get there in one giant leap. You’re going to move through a series of intermediate states, and each one needs to represent a prioritized stable, valuable plateau where the system works and delivers business capability.
When we helped modernize a rankings platform for a digital media company, we sequenced releases around their publishing schedule. They needed to publish rankings on specific dates throughout the year. We couldn’t disrupt those deadlines, so each release had to be complete and stable before their publishing windows. This meant we were building in cycles tied to their business calendar, not just arbitrary sprint boundaries.
For a music royalty processing company, we were migrating users from a large monolith system they’d used for thirty years to a modern web platform. We couldn’t do that in one big bang. We had to use a strangler pattern – gradually building out new capabilities while users continued working in the old system, then migrating them over, piece by piece.
The release structure depends on your business constraints, your technology constraints, and your appetite for risk. Every release needs to leave you in a stable state where you have something valuable that moves you toward your target state.
Component 3: Prioritization and dependencies
The order in which you build things matters more than most people realize. Build in the wrong sequence and you’ll spend half your time reworking things you already built, and delaying the realization of any business value from the project.
When we’re planning and strategizing, we think in terms of architectural layers so that we understand dependencies and identify what’s foundational versus what builds on top.
But during execution, we use approaches like the strangler pattern and vertical slicing to deliver business value incrementally. You build out infrastructure in parallel with new features, just enough to support what you’re delivering in each release. You’re constantly showing progress and unlocking new value, not spending six months on infrastructure before anyone sees a working feature.
Theory of Constraints thinking comes in handy here. What’s blocking the most value right now? You address this first, whether it’s infrastructure, data architecture, or application features.
Sequencing also depends on external factors. Are there marketing events where you need to demonstrate progress? Regulatory deadlines you have to meet? Publishing schedules you can’t disrupt? Customer commitments that constrain your timeline? All of these factors influence what you build when.
We worked with a financial services company where we sequenced the work around their business impact, not their technical elegance. First priority was fixing their broken development and release infrastructure – building a proper CI/CD pipeline, replacing the fragile remote desktop environment that was causing developers to lose work, implementing staging environments and automated testing. This wasn’t the most exciting work, but it was blocking everything else. Once that was in place, they could actually make changes to their systems in days instead of months.
Next priority was modernizing their forty-year-old mainframe credit scoring model. This was directly revenue-impacting. Their old model took months to update, which meant they couldn’t respond to market conditions in real-time. Moving to a modern machine learning application in the cloud transformed their revenue funnel from a cycle time of months to minutes.
That sequencing meant they saw results within weeks of starting, not years. They didn’t have to wait for a complete platform modernization before they could unlock business value.
Component 4: Resource models and cost estimates
This is where most plans fail before they even start. This is because humans are really, really bad at estimating things. We can describe what to build and when to build it, but we don’t have an accurate and reliable way to model cost and schedule estimates that decision-makers can use to make decisions. And things get worse: under pressure to commit, early estimates often get locked into hard dates and budgets, leaving little room for adjustment as things are learned down the road.
Rough order of magnitude (ROM) estimates are the place to start and give you a handle on the resource requirements for executing the plan. How many people do you need? Are they staffed from internal resources or external partners? What skills do they need? How long will they need to work on this? What’s the total cost in time and money for the initial build, for iterations and completion? And just as important, how much will this cost to operate and maintain annually?
Understand that these ROMs come with error bars, depending on how much information is available up-front and whether a solid methodology was used, they could be off anywhere from +/- 30% to +/- 70%. As they say, “the map is not the terrain”.
For a music royalty company we worked with, we went deep on cost modeling because they needed board approval for a multi-year investment. We estimated the project would take twenty-four months with a specific team composition. We detailed our assumptions. We ran multiple scenarios to show them their options.
ROM estimates, when done with sound methodology, give you the data points you need to make that business case to your board. When you’re talking about a project that will take two or three years and cost you a couple million to ten million dollars, you need budget approval. These cost models give you the ammunition to have that conversation with confidence.
Planning for different scenarios
Single-point estimates never survive contact with reality. Boards know this. When you present them with one timeline and one cost figure, they don’t trust it. They know from experience that it comes with a hedge.
That’s why we often develop alternative scenarios that show different ways you could execute the plan. A common question that should be addressed in scenarios is how much of this can we buy vs build?
Are there services in the market place that can meet the requirements? Software as a Service (SaaS) or Platform as a Service (PaaS), off-the-shelf product that can help to accelerate the initial build
What it looks like if you do this with your existing team. This is usually the riskiest and slowest option with hidden costs too. While your team is building the new technology, you still have to maintain and operate the incumbent technology. Bugs still need to be fixed. Security vulnerabilities still need to be patched. Potentially you even need to keep adding features and capabilities to the old systems. For a lot of organizations, it’s near impossible to do both things in parallel and make any progress.
What happens if you outsource the entire project to an external firm. This is usually faster because you’re paying a premium for speed and specialized expertise. But you also have knowledge transfer risk: when the external team leaves, does your internal team really understand what was built and how to maintain it?
What happens with a hybrid model – a mix of internal team and external partners. This is the sweet spot and often where organizations land. They realize they can’t hire enough people with the right skills quickly enough, so they bring in external help to accelerate specific pieces while keeping their internal team engaged for continuity and OJT up-skilling.
But beware: while modelling different scenarios gives decision-makers real choices, letting them decide how much risk they’re willing to accept, how fast they need to move, and how much they can afford to spend, too much choice can lead to analysis paralysis. Stick to two to three options in total to avoid overwhelming your deciders.
The negotiation reality
I’ve never been in a situation where a client said, “Oh, that delivery timeline is too fast.” It’s always the opposite. How can we make this faster? How can we cut scope? Do we really need all of this?
This negotiation is a feature of the MRTP process, forcing conversations that need to happen: conversations about what’s actually required to get from where you are to where you need to be.
The first draft is never the final plan. We deliver what we think is a realistic roadmap based on what we learned in the assessment. The client usually looks at it and gets sticker shock. “Twenty months? We can’t sell that to our board.”
Then we iterate. Can we cut this feature out? Do we really need this capability right now or can it wait? Can we get this done faster if we add more people? Is this timeline really achievable or are you being overly optimistic? What are the risks if we compress the schedule?
Eventually you land on a plan that’s fundable. Not the perfect plan but the fundable plan. It’s realistic enough that your team believes they can execute it. It’s ambitious enough that it’s worth the investment. And it’s backed by scenarios that show executives their options and the trade-offs between them.
This negotiation process creates organizational alignment around realistic expectations. Everyone has heard the same story about what’s required. When you finally get funding approved, there are no surprises about scope or timeline or cost.
Tailoring the plan for different audiences
The MRTP is structured to serve different audiences.
The executive summary – usually one to two pages – captures the business context, the goals you’re trying to achieve, the high-level approach, the timeline, the cost, and critically, a section on “how does this impact you?”
Most readers will read that section and not much more. Your CFO, COO and board members don’t need to understand the detailed architecture to make a funding decision. They need to understand what problem you’re solving, what it will cost, when you’ll see value, and what risks you’re accepting. The executive summary gives them everything they need to say yes or no.
The technical detail comes after that. This is for the people who will actually build this thing: your CTO, your technical leads, your senior developers, your product managers. They need to see the detailed architecture, the component specifications, the integration patterns, the technology choices. They need enough detail that they could start building tomorrow.
This two-level structure creates alignment. Everyone sees the same plan, just at their appropriate level of detail. The executives approve the direction and the budget without needing to understand the strangler pattern implementation. The builders validate that the technical approach is sound without needing to justify the business case.
We always include a section on change management and user impact. When you’re modernizing a platform, you’re changing how people work. For the music royalty company, we were asking users who had worked on a mainframe for thirty years, then a Windows desktop application for twelve years, to move to a web-based platform. That’s a massive change in their day-to-day workflows.
People who’ve been using terminal-based systems develop muscle memory. They can process records incredibly fast using just keyboard shortcuts, no mouse, no graphical interface. When you tell them they now have to use a mouse and click through web forms, they’re not thinking about all the modern benefits of cloud-based architecture. They’re thinking about how their productivity is going to crater while they relearn basic tasks.
You have to acknowledge that kind of change upfront and address it. What training will you provide? How will you roll out changes incrementally so people can adapt? How will you collect feedback and iterate? Change management is a big component of any platform modernization, and it needs to be in the plan.
The strategic advantage of honest planning
Bad planning is expensive: the adverse impact on the business goes well beyond what shows up on the balance sheet.
Years wasted on unfunded initiatives that never get budget approval because nobody could articulate what they’d actually cost. Millions spent on poorly sequenced work that has to be completely redone because you built features before you built the infrastructure to support them. Organizational paralysis where different executives have competing visions of what should happen and no shared framework for resolving those conflicts. Competitive position eroding while you argue about whether you can afford to modernize.
A Multi-Release Technology Plan addresses all of these problems.
- It enables realistic board conversations. Not magical thinking about digital transformation, but actual costs based on actual resource models and actual timelines based on realistic sequencing.
- It allows you to fail early if you need to. If you genuinely can’t fund what’s required to fix your technology problems, it’s better to find that out during planning than after you’ve spent two years and several million dollars on a partial solution that doesn’t solve anything.
- It creates stakeholder alignment. Everyone – CEO, CFO, CTO, CPO, board members – sees the same plan, understands the same trade-offs, operates from the same set of assumptions. This breaks political gridlock.
- It delivers incremental value. You’re not waiting three years to see any business capability from your investment. Each release brings specific capabilities online. If things don’t go according to plan, you’ve still made progress.
- It provides a framework for adaptation. When reality diverges from your plan – which it always does – you have structure for making informed decisions about what to do next. Perfect execution is not the goal. Fundable, adaptable, honest planning is the goal.
The MRTP is what one of our clients called “an eye-opening exercise” for their organization. They could see how the investment they were being asked to make would impact their business. They could see what value they’d get out of it. They could see what would happen if they chose not to make that investment.
Sometimes that last piece is the most valuable. We’ve done assessments where the findings identified twenty critical problems. When we put together the MRTP showing what it would take to fix all twenty problems, the honest answer was: you can’t afford to fix everything right now. That’s valuable information before you start spending money.
This forces you to make hard choices. Which problems are truly existential and which ones can you live with for now? Where do you get the most business value for your investment? What’s the minimum viable transformation that’s still worth doing?
We’ve worked with CEOs who’ve been burned by technology initiatives that never finish. They’re skeptical, and they’re right to be. The MRTP addresses that skepticism head-on by forcing honest conversations about what change actually requires before you bet the company on a plan that can’t work.
Two paths toward a fundable technology plan
So how do you actually create one of these plans?
Path one is to build it internally. This can work if you have the right skills and can afford the time needed on the new initiatives. You need architects with broad experience across business and technology who can develop detailed architecture artifacts, data models, and integration patterns. The specific expertise required depends on your target state – data platforms need data architecture skills, high-traffic applications need scalability expertise.
You also need organizational capital. The people creating this plan must be seen as fair-minded and trustworthy, with explicit authority to mandate participation. Critically, they need to be able to ask “what would I recommend if this weren’t my company?” That’s harder than it sounds when your salary depends on not asking certain uncomfortable questions.
Path two is to get external help. This makes sense in several situations.
If your internal team lacks the time or breadth of experience needed to design a target state architecture and sequence a multi-year transformation, bringing in people who’ve done this dozens of times accelerates the process and reduces risk.
If organizational politics prevent honest internal assessment – if the real problems involve leadership decisions or structural issues that are career-limiting to point out – external consultants can say things your internal team can’t safely say.
If stakes are too high for learning by doing, for example, there’s a potential acquisition pending, your largest customer is threatening to leave, or you’re facing regulatory action, then you can’t afford to get this wrong.
And if your timeline is compressed and you don’t have months to figure this out through trial and error, external help can deliver a fundable plan in weeks instead of quarters.
At the end of the day, if you can’t create a plan that’s fundable, you can’t execute. And if you can’t execute, your technology plans just become an expensive monument to good intentions.
Ten Mile Square’s Multi-Release Technology Plans translate the findings of technology assessments into board-approved, executable roadmaps. We work with CEOs and technology leaders to develop target state architectures, sequence releases for maximum business value, and model resource requirements that get funded. If you’ve identified critical technology gaps but you’re struggling to get budget approval for the fixes, contact us to learn how MRTPs turn findings into action.