Six months into the hold, the forecast starts drifting from plan. The CFO cannot reconcile pipeline to bookings, sales leadership cannot explain why win rates moved, and the answer everyone reaches for is a new CRM, a new ERP, or a “platform.” That is where a systems implementation for a portfolio company usually begins, and where enterprise value quietly leaks. The decision in front of the operating partner is not which vendor to sign. It is what the business needs to run differently, who owns the outcome, and how the money spent converts into EBITDA, cash-flow reliability, or a cleaner story at exit.

This guide is written for the person standing up sales and revenue operations inside a portfolio company. It walks the sequence of decisions an operating partner or portfolio executive actually controls, and how to judge whether the work is producing value or just producing activity.

1. Start with the commercial problem, not the software

A systems project almost never fails on configuration. It fails because it was framed as a technology purchase instead of a business change. Before any platform is scoped, the operating partner needs a plain statement of the commercial problem the system is meant to solve, expressed in numbers the board already tracks.

Useful framings sound like this: “Sales cycle is 40 days longer than the segment because reps rebuild quotes by hand.” “We cannot bill on time because order data lives in three systems.” “The forecast is wrong every quarter because pipeline stages mean different things to different reps.” Each of those ties to revenue, cash, or forecast reliability. “We need Salesforce” does not.

Bain’s annual private equity report has documented for years that value creation in the current cycle depends on operational improvement rather than multiple expansion. You can read the running analysis in the Bain Global Private Equity Report. A systems implementation only counts as value creation when it is tied to one of those levers, not to a feature list.

2. Decide what the system is supposed to change about the numbers

Every implementation should carry a written outcome the executive is willing to be measured against. Pick the two or three metrics the system is supposed to move, capture the baseline before anything ships, and name who owns each number.

Classify the value honestly

Not all impact is the same. Faster cash collection is realized value once the cash actually arrives. A shorter sales cycle is run-rate once it holds for a quarter. A cleaner data model that makes a bolt-on easier to absorb is enabled value. Removing a system that would have failed diligence at exit is risk avoided. Label each one. When forecast value gets reported as if it were already in the bank, the board stops trusting the workstream, and that is expensive to rebuild.

3. Set the baseline before Day 1, not after go-live

The single most common mistake is measuring after the new system is live, when there is nothing clean to compare against. The baseline belongs in diligence or the first weeks of the hold. Capture current sales cycle, quote-to-cash time, forecast accuracy versus actuals, data quality in the existing CRM, and the true count of systems the revenue process touches.

This is why the technology due diligence workstream matters even for a company that “just needs a CRM.” Diligence is where the real state of the systems gets documented before anyone has an incentive to make it look better. If you inherited a deal without that baseline, rebuild it in the first 100 days before the implementation locks decisions in.

4. Choose between fixing, replacing, and rebuilding

Executives reach for “replace” too quickly because a new platform is easier to approve than a hard conversation about process. Three options are usually on the table, and they carry very different risk.

• Fix in place. Reconfigure and clean up what exists. Lowest disruption, fastest payback, and often enough when the tool is fine but the process and data are not.
• Replace. Migrate to a new platform. Justified when the current system genuinely cannot support the model, but it imports migration risk, retraining cost, and a period where the numbers get worse before they get better.
• Rebuild the process, then decide. Fix how the revenue motion actually works, then let that dictate the tool. Slower to start, but it prevents paying to automate a broken process.

The same tradeoff shows up in adjacent decisions. The reasoning an operating partner uses for application modernization in a portfolio company and for cloud migration decisions is the same discipline: the technology choice follows the commercial case, not the other way around.

5. Assign decision rights before the project starts

Systems projects stall in the space between the operating partner, the portfolio CEO, the CFO, and whatever internal or external team is doing the work. Write down who holds each decision right: scope, go-live date, phase go/no-go, budget change approval, and sign-off on data readiness. Ambiguity here is what turns a two-quarter project into a two-year one.

Governance research collected on the Harvard Law School Forum on Corporate Governance repeatedly points to clear accountability as the difference between value creation that shows up and value creation that is announced. Name the single accountable owner for the outcome, not just the project.

6. Sequence the work so cash comes early

A big-bang implementation that goes live in month nine gives the board nothing to judge for three quarters. Sequence the work so the earliest phases produce visible results: fix the quote process before rebuilding reporting, clean the pipeline data before layering forecasting on top of it.

This ordering is where post-merger integrations most often go wrong. The pattern behind failed RevOps integration and lost post-merger synergies is almost always sequence: teams merge systems before they agree on definitions, so the combined data is worse than either company had alone. Agree the definitions, then build.

7. Decide who does the work, and buy outcomes not hours

The build capacity comes from three places: internal hires, a staffing shop that bills time, or an embedded partner accountable for the result. For a portfolio company on a hold clock, the internal-hire path is often too slow, and the time-and-materials path bills activity regardless of whether the numbers move.

The judgment is the same one covered in hiring a sales operations consultant without buying activity and in deciding when to outsource sales operations. Contract against the metric you defined in section 2, not against a ticket queue. If the engagement cannot state what number it is accountable for, it is selling hours.

8. Do not skip compliance and data risk

Two categories of risk get ignored until they surface at exit. First, data handling: a new system that consolidates customer and financial data changes the company’s exposure, and a buyer’s diligence team will ask. Second, accessibility and regulatory obligations that ride along with any customer-facing system, covered for portfolio companies in accessibility compliance engineering decisions. McKinsey’s private capital research, published on the McKinsey site, has tracked how unaddressed operational and technology risk compresses the eventual exit multiple. Cheaper to design in now than to discover in a quality-of-earnings review later.

9. Plan for adoption, because the system is worthless unless people use it

Configuration is the easy 30 percent. Adoption is the other 70. A CRM that reps route around does not shorten the sales cycle; it just adds a data-entry tax. Enablement is not a launch email. It is manager reinforcement, incentive alignment, and the follow-through that makes the new motion the path of least resistance.

The science of motivation in employee training applies directly here: people adopt a system when it makes their own job measurably easier, not when they are told to. Build the adoption plan into the project budget, not as an afterthought once go-live is missed.

10. Instrument the project against actual versus plan

Every phase should report against the baseline and against the committed timeline. If sales cycle was supposed to drop by 20 percent and it dropped by 4, that is a signal to inspect the process, not to add features. The board conversation is simple when the metrics are named up front: here is what we committed, here is actual, here is the variance and the reason.

PitchBook and S&P Global both maintain data showing how holding periods have lengthened, which raises the cost of every quarter a systems project runs long. Their coverage is at PitchBook and S&P Global Market Intelligence. Time is the scarce resource; instrument against it.

11. How to judge the whole thing

The operating partner does not need to judge the technical architecture. The right questions are commercial, and they are the same throughout the hold. If the partner running the work cannot answer them cleanly, that is the finding.

• What number does this move, and what was the baseline?
• Who is the single accountable owner for that number?
• What is realized today versus forecast versus enabled?
• What is actual versus plan on the current phase?
• What risk does this remove from the exit story?

When those answers are vague, the project has drifted back into buying activity. The same lens applies when choosing a partner at all, which is the substance behind judging a West Monroe alternative for fit.

12. Next-step checklist

• Write the commercial problem in board-level numbers before scoping any platform.
• Capture the baseline now, in diligence or the first 100 days, not after go-live.
• Name the two or three metrics the system must move, and their owners.
• Decide fix versus replace versus rebuild-process on evidence, not preference.
• Assign every decision right in writing, including phase go/no-go.
• Sequence the work so cash-producing phases land first.
• Contract the build against the metric, not against hours or tickets.
• Budget adoption and enablement as part of the project, not after it.
• Report actual versus plan every phase, and label realized versus forecast.

Systems work that is scoped this way becomes a value-creation lever the board can see. Scoped the old way, it becomes a line item everyone regrets at exit. The difference is entirely in the decisions above, and those belong to the operating partner and the portfolio executive, not the vendor.

For teams running this inside a hold, review how embedded technology value creation is structured across the DevriX and GrowthShuttle private equity practice, and use it to pressure-test your own implementation plan against the exit thesis.