A value-creation plan has a delivery-capacity problem when a named executive owns the result but nobody can show who will perform the technical work, when they are available, or how the operating team will accept the change.
“The CFO owns pricing” is a business decision. It does not establish that someone can reconcile customer records, integrate a pricing rule with billing, test exceptions and support the release. A sponsor's operating team can help set the direction. The portfolio company still needs a workable delivery path.
Separate business ownership from delivery responsibility
For each important initiative, identify the executive who can change the process and approve the result. Then identify the people who will build, test and operate the change. They may be internal employees or external specialists. The distinction is about responsibility, not organizational prestige.
Ask the system owner who can authorize access and production changes. A senior sponsor does not automatically have those permissions. Nor does a project manager substitute for someone who understands the integration. Record both the authority and the practitioner.
Google Cloud's DORA capability guidance treats visibility of work and limits on work in process as delivery capabilities. The practical implication for a value-creation plan is straightforward: staffing cannot be evaluated independently of the work already in progress.
Turn “pricing improvement” into a bounded change
Fictional portfolio-company example
A business wants a revised discount policy working in its next billing cycle. The CFO has approved the commercial policy. The delivery work remains:
- Join customer and contract records from the CRM and billing system, and reconcile disagreements.
- Implement the permitted discount rules with an exception path for approved contracts.
- Test invoices against expected amounts and prevent duplicate updates.
- Release the change in a controlled window with a tested rollback.
- Train the billing team and assign support ownership.
A spreadsheet listing new prices covers only part of this work. The business result depends on the billing behavior.
Keep the first change small enough to test. A specific customer segment may be a better starting point than a full-system redesign. DORA's small-batch guidance emphasizes independent, testable work and faster feedback. This supports a bounded release; it does not guarantee a completion date.
For legacy systems, the choice need not be “replace everything” or “do nothing.” Microsoft's Strangler Fig pattern describes incremental replacement of functionality. Whether that approach fits depends on the application's boundaries and routing options. Have an engineer test those conditions before including it in the plan.
Count delivery capacity after existing commitments
Ask for actual availability during the relevant weeks, including business-as-usual support. Do not estimate capacity from headcount alone. A named engineer may already be the escalation point for billing incidents and an add-on integration.
Fictional weekly capacity check · estimates, not a benchmark
One integration engineer has 30 hours available after fixed support duties. Existing work takes 15 hours, pricing changes need 12 hours, and reporting needs 10 hours. The plan assigns 37 hours to 30 hours of capacity: seven hours are unfunded or must be deferred.
Resolve the conflict explicitly. Reduce scope, change sequencing, move a commitment or add qualified capacity. Calling all three workstreams “priority one” does not resolve it.
Hours alone are insufficient. Confirm the engineer has the necessary system knowledge and can obtain timely reviews. Integration with Microsoft Dataverse, for example, may require throughput testing and retry handling. A generic integration estimate that omits these conditions can leave the operating deadline exposed.
Also reserve time for acceptance and support after release. A delivery partner's completion date is not useful if the management team is unavailable to test the workflow or the internal team cannot operate it.
Define what the operating team will accept
The acceptance test should describe business behavior. In the pricing example, approved prices must reach the intended invoices, excluded contracts must remain unchanged, and the billing team must be able to investigate discrepancies. “The integration is deployed” is insufficient.
Write down who can stop the rollout and how recovery works. Microsoft's safe-deployment guidance recommends progressive exposure, health checks and halting a deployment when problems appear. Translate those ideas into the workstream's operating checks rather than leaving them as generic IT requirements.
Commercial acceptance and technical verification need different owners. The CFO approves the pricing behavior; engineering confirms the integration and recovery; the billing team demonstrates it can run the exceptions. No single sign-off substitutes for the others.
