Prioritize technology spend by tying each initiative to a value creation lever before ranking it.
Prioritizing technology spend at a portfolio company starts with a filter, not a ranking. List every proposed initiative, from the ERP upgrade to the new customer portal, and write beside each one the value creation lever it moves: pricing, margin, labor productivity, retention, add-on integration, or reporting. Anything without a lever is either maintenance or a preference, and should be budgeted as such.
Then rank the remaining initiatives against three questions. How much does it move the lever? What must be in place before it can work? What risk does it remove or create? A shorter list with those answers written down is easier for management and the board to agree on than a long wish list with rough estimates attached.
Keep the whole list in one place for the company, including the work finance, operations, and sales each want. Technology spend is usually spread across departmental budgets and vendor renewals, which hides the total and makes tradeoffs invisible. One list, reviewed by the leadership team together, turns competing requests into explicit choices about what the company can take on during the hold period.
Sequence the work by value and by what each initiative depends on.
A high-value initiative is not the right first project if it depends on something that does not exist yet. Margin analysis by customer needs clean customer and job data. A consolidated dashboard needs agreed-upon definitions. A pricing tool needs current costs. Draw the dependencies between initiatives on one page, and the true starting points usually become obvious.
Foundational work tends to rise to the top once dependencies are visible: a shared customer and product record, reliable connections between operating and accounting systems, and a reporting layer the finance team trusts. These rarely excite anyone by themselves, but several higher-value initiatives are blocked until they exist, which is the argument for funding them early.
Also sequence around the company’s capacity to absorb change. The people who must adopt each new system are running the business at the same time. Two major rollouts landing on the same operations team in the same quarter usually slow both. Stagger initiatives by the teams they affect, not only by their technical order.
Separate the work that reduces risk, the work that builds value, and the work that prepares the exit.
It helps to sort the list into three groups. Risk work comes first: administrative access, backups that have been restored, unsupported software, security gaps, and systems that depend on one person. It seldom produces a visible return, but an outage or a breach during the hold period can undo gains made elsewhere, and buyers will find these issues later regardless.
Value work is the core of the plan: the initiatives that move pricing, margin, productivity, or integration. These deserve most of the budget and management attention in the middle of the hold. Choose a small number and finish them, because a half-built quoting tool or a partial integration produces cost without the result that justified it.
Exit work prepares the company to be examined by the next buyer: documentation, a current system map, clean data, reporting that reconciles without manual effort, and evidence of the results each initiative produced. Much of it is inexpensive when done as work ships and costly when assembled at the end, so plan for it from the start.
Budget in phases, each with a written scope and a decision point.
Large technology budgets approved as a single number tend to drift. Break each initiative into phases, each with a written scope that states what will be in use at the end, who will use it, and how its effect will be measured. Fund one phase at a time, and approve the next phase on the evidence from the last one.
The first phase of a significant initiative is often a short discovery and design step that confirms the scope, the data, and the integrations before the larger commitment is made. That step turns a rough estimate into a priced plan, and it surfaces the problems that tend to derail projects later, such as poor data quality or a vendor’s limited API.
Hold a contingency at the portfolio company level rather than inside each project. Individual budgets then stay honest, and the leadership team decides deliberately where extra spending goes when an initiative needs more, instead of every project quietly absorbing a hidden overrun. The same review should also stop an initiative whose early phases have not moved its measure.
Report progress to the board in terms of the levers, not the projects.
Board reporting on technology is most useful when it follows the same structure as the value creation plan. For each initiative, show the lever, the phase it is in, what is in use and by whom, and what has changed in the measure it targets. Spend against budget belongs in the report, but it should not be the headline.
Report the risk group separately and plainly: which risks were closed, which remain, and what is planned for each. A short, stable list that shrinks between meetings is easy for a board to follow. It also gives operating partners a clear view of exit readiness without waiting for a separate review late in the hold period.
Revisit the whole list at each board cycle, since add-on acquisitions, market changes, and early results all shift priorities. Baybloom Software works with portfolio company leaders on scoped phases of this kind of plan. Whoever builds it, the discipline is the same: every initiative tied to a lever, sequenced by dependency, released in phases, and reported by outcome.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project