An ERP or CRM initiative gets chartered, funded, staffed, and delivered on time and on budget. Success gets defined as the implementation itself: the system is live, adoption logins look fine, user acceptance testing passed.
At some point, someone asks if things are better, and there is no way to answer, because nothing was named to measure against except the standard time, quality, and cost. That is not a failure. It's a gap. The project management discipline that governed the build did exactly what it was chartered to do, but the gap sits earlier: in whether anyone defined the capability the technology was supposed to create before the scope was locked, or let success default to the implementation itself because that was easier to define.
What Objective Is Supposed to Validate
An earlier piece in this series covered what makes an objective valid: a target traceable back to process data, not an expectation dressed up as a goal. That principle holds here. This piece is narrower. It is about timing, specifically on technology initiatives, where the objective work that should happen before procurement routinely gets compressed into, or skipped in favor of, the business case that justifies the purchase.
Those are not the same document. A business case exists to clear a budget gate. It answers whether the spend is justified against cost of ownership and feature comparison. A capability objective answers a different question: what specific, measurable thing will be true after this technology is live that is not true today. Most technology charters only answer the first question.
Why Technology Objectives Start Vague
Process improvement projects get chartered off a diagnosed symptom already showing up in the data: a defect rate, a cycle time, a cost per transaction. The objective is specific because the trigger was specific.
Technology initiatives get chartered off a different kind of trigger. A system reaches end of life. An acquisition forces consolidation. A vendor demo makes a strong impression. An analyst report says the market has moved on. None of those triggers name a capability, they name a condition. The objective that gets written down - modernize, transform, reimagine - inherits that vagueness honestly. It is not lazy language. It is an accurate translation of a trigger that was never translated in the first place.
Stripped down, every one of those words means the same thing: some set of business capabilities is expected to move from a current state to a better one. The words themselves carry no information about which capabilities, or how much movement is expected. That is the specific gap Objective has to close on a technology initiative, and it is a narrower, harder problem than the general case covered in the earlier piece on what makes an objective valid.
How the Sequence Usually Runs
The pattern is consistent across ERP, CRM, and most mid-size platform replacements. A trigger event starts it: a system reaches end of life, an acquisition forces consolidation, or a vendor demo makes a strong impression. A business case gets built to secure budget, usually estimating efficiency gains as a percentage assumption with no current-state baseline behind it. Vendor selection follows a feature checklist matched against what demos well. The SOW gets signed and becomes the working charter. Success criteria default to on-time, on-budget, features delivered as scoped, user acceptance testing passed.
The PMO stands up governance against that SOW: milestones, change requests, budget burn. That governance is accurate to what it was handed, a PMO scoped to schedule and budget is executing its mandate correctly even when the mandate itself never included a capability metric. Go-live gets measured by defect count and adoption logins. Benefits realization, if it happens at all, arrives twelve to eighteen months later, by which point ownership has usually rotated and there is no clean baseline left to compare against, because one was never captured before the build started.
"A PMO governing a signed SOW is governing exactly what it was chartered to govern. The gap is usually upstream, in whether the business case defined a capability or just justified a purchase."
That is consistent with the broader pattern in this series: established methodologies tend to execute rigorously against the scope they are handed. The sequencing problem sits before the methodology gets engaged, not within it.
What a Capability Map Actually Looks Like
A single capability statement works for a narrowly scoped initiative. Most ERP and CRM initiatives are not narrow. They touch several distinct capabilities at once, unevenly, and treating the whole platform as one capability is where "modernize" stays vague even after someone tries to define it. What is needed is closer to a capability map, the same structure behind a framework like APQC's Process Classification Framework or a LeanIX-style capability model: name each capability the technology is expected to move, then define the same fields per capability, not once for the whole initiative.
"Modernize the CRM" decomposes into something closer to five or six capability lines: lead management, opportunity tracking, forecasting, case management, and so on, each carrying its own current state and target. Forecasting accuracy today might sit at plus or minus 40 percent at 90 days out; the platform is expected to bring that to plus or minus 15 percent. That is a testable claim. "Modernize the CRM" is not.
For each capability on the map, six fields get filled in before procurement, not reconstructed afterward.
If any of those fields cannot be filled in for a given capability before the SOW is signed, that capability has not been defined yet, it is a hope attached to a purchase.
Most technology business cases are not empty of numbers. They usually carry ROI projections, cost reduction targets, and headcount reduction assumptions, and treating those as equivalent to a capability baseline is where objective-setting goes wrong even in organizations that believe they are being rigorous. ROI and cost figures answer whether the spend is justified; they look backward toward budget approval, not forward toward a process outcome. Headcount targets are usually a proxy for efficiency, but they are disconnected from the mechanism, the cycle time, error rate, or handoff delay, that would have to change to make the reduction real and sustainable. A capability can genuinely improve while a headcount target is missed on attrition timing, and a headcount target can be hit through reorganization while the underlying capability never moves. Cost and headcount outcomes sit downstream of capability movement. They cannot substitute for naming it.
When the Capability Was Named and Still Lost
A process engineer was brought in to evaluate BPMS platforms for workflow automation and business rules. The VP sponsoring the initiative was explicit about one requirement above the rest: simulation capability, the ability to model process flow and identify bottlenecks before changes went live.
Eight vendors were researched. Three were brought in to demo. On core features, workflow, business rules, web services, the finalists were close. On simulation specifically, two vendors were clear leaders. Evaluation surveys reflected that. The organization selected the third vendor anyway, on the strength of an existing relationship. That vendor claimed simulation capability but did not demo it and had no training path for setting it up. Its testing feature could validate a single unit moving through the flow, but had no way to model how a day's volume of concurrent work would execute, where it would queue, or where it would break down under real load. The named requirement was never met.
The capability had been named correctly. It had been tested and scored correctly. What was missing was a governance mechanism that made the named capability binding at the decision point. A survey score is a data point, not a gate. Without a documented threshold requiring the capability to be demonstrated and supported before it could count in the selection, an unrelated factor had room to override a validated requirement.
Vendor relationship is not automatically an illegitimate factor. Existing contracts, integration history, and support continuity carry real switching cost that a feature scorecard does not capture. The failure in this case was not that relationship was considered. It was that relationship was allowed to override a named, prioritized, decision-critical capability without that tradeoff being made visible to whoever signed off on the choice, and without the vendor's claim ever being held to the claimed-versus-verified standard the capability required. Objective-phase discipline does not mean relationship can never win. It means when it does win over a stated capability requirement, that is a documented decision with an owner, not a default.
Objective validates the value case before resources commit, not after the technology is live.
On technology initiatives specifically, that means a capability map exists before the SOW is signed: every capability the platform is expected to move, its baseline, its target, and a named owner distinct from the sponsor and the PMO. A vendor's claim counts only once it has been demonstrated and supported at the fidelity the capability requires. Everything downstream, including what the PMO is asked to govern, depends on that sequence holding.
Part of an ongoing series on operating model design, process transformation, and what it takes to make change endure.