The investment buys an operating capability

An industrial operator can own an impressive application estate while still being unable to release a repair safely, promise a delivery confidently or resolve a disputed operating record. The missing object is not necessarily another system. It may be an authorised decision, an agreed meaning or an exception service that joins work across organisational boundaries. An investment charter should begin with that object. It describes what a named user will be able to decide or complete after the change, the evidence that decision needs and the consequence of making it incorrectly. This makes product discussion answerable to an operating requirement.

Consider an expressly fictional maintenance service. A technician reports a fault, a planner proposes an intervention, stores confirms parts and an operating supervisor releases the equipment. A new mobile interface might make fault entry faster. It does not by itself reconcile an ambiguous equipment identity, grant the planner authority to interrupt production or establish whether a substituted part is acceptable. If the investment promises reduced downtime, the charter must connect entry to diagnosis, approval, materials and release. Otherwise the programme can deliver its screen while leaving the causal obstacle untouched. The user-facing convenience and the operating outcome may both matter, but they are different benefits with different owners.

The decisive question is what work changes when the new information arrives. An alert is an output; a changed maintenance decision is an intervention. A dashboard is an output; an authorised response to a deviation is an intervention. A charter that stops at information availability delegates the hardest part of transformation to an unnamed future meeting. It should identify the decision rule, the person or role empowered to apply it, the cases that require escalation and the physical or commercial action that follows. This is a practical account of agency rather than a theory that every industrial choice can be automated.

A capability can therefore include people, rules, information and technology in the same investment boundary. That boundary should be broad enough to contain the mechanism of benefit and narrow enough to identify a responsible sponsor. A fault diagnosis capability might depend on a common asset register outside the initial programme. The charter must disclose that dependency rather than silently treating it as a delivered component. External dependencies can be legitimate. Hidden ones produce a benefit claim whose necessary conditions are absent from the funded work.

Before solution selection, the sponsor should be able to explain the present failure without using a vendor name. If the account is only that an application is old, the immediate decision may be replacement for continuity rather than transformation for operating improvement. Both can justify expenditure. Their evidence differs: continuity requires an account of support, security and recovery exposure; improvement requires a causal path from changed work to an outcome. Combining them in one undifferentiated promise makes later evaluation difficult.

The charter needs an operating perimeter, not merely a software perimeter. It should identify the initiating event, the terminal outcome and the intervening handoffs that the programme will change. In the fictional repair service, initiation is an accepted fault report and termination is authorised return to service with an adequate record. Procurement might buy only fault capture and planning tools. That narrower commercial scope does not redefine the operating endpoint. It creates interface obligations to stores, engineering and operations that someone must govern.

Users should be described through the work they perform and the conditions in which they perform it. A technician with gloves, intermittent connectivity and an urgent safety concern has different requirements from a planner reviewing a backlog at a desk. An operating supervisor making an interruption decision needs an intelligible tradeoff and a current equipment state. Stating these conditions early prevents a generic account of adoption from replacing real work design. It also exposes whether an apparently convenient interface transfers administrative work from a central team to a person whose attention is already constrained.

The charter should distinguish mandatory operating conditions from desirable product qualities. An authorised release and a durable decision record may be mandatory. A particular animation, report layout or integration technology may be negotiable. If all requirements receive the same status, the programme cannot trade scope intelligently. Conversely, if a mandatory condition is hidden within a broad desirability score, an attractive product can compensate numerically for an unacceptable operational omission. The distinction belongs in the decision record before bidders or internal delivery teams interpret the scope.

A benefit owner is required for each material outcome. This owner need not perform every activity, but must possess or secure authority over the work whose change produces the benefit. In the repair example, an IT manager can own availability of the planning tool while an operations manager owns the interruption policy. Neither can independently promise reduced downtime through the whole service. Their joint commitment should state who changes the policy, who tests the information and who records whether the change worked. A signature without a specific action is a weak substitute for this commitment.

The funded boundary should include transition and continuing operation. A charter that pays for configuration while assuming free reconciliation, training and exception handling will describe a capability cheaper than the one the organisation can actually sustain. This study separates the companion model's declared implementation cost from those additional responsibilities. They may be recorded qualitatively before detailed estimation, but they cannot be treated as nonexistent because a small model has no field for them. The investment case should state which costs are estimated, which are not and who will resolve the omissions.

An investment proposition should be capable of failing a useful test. The fictional operator could test whether a fault report reaches an authorised planner with an unambiguous equipment identifier and enough evidence to choose an intervention. It could then test whether the operating supervisor can accept or reject that intervention without a separate informal reconstruction of the case. These tests concern the mechanism through which the service produces value. A successful product demonstration showing that a report can be entered is relevant, but narrower.

The charter should name the present comparison practice. If a planner currently resolves missing information through a telephone call, removing that call may be an improvement, but only if the necessary context is now captured or retrieved another way. A crude measure of fewer calls can reward the disappearance of useful coordination. The evaluation should examine whether the decision became more reliable, more timely or less burdensome, and whether its exception route still works. The intended comparison is an operating practice, not an imaginary state in which every existing activity is waste.

Evidence should be collected at the point where the mechanism could break. If asset identity is contested, test reconciliation before testing dashboard usefulness. If release authority is unclear, test the approval route before promising automated scheduling. If parts confirmation is slow because suppliers do not provide reliable availability information, an internal interface alone cannot remove the external uncertainty. Sequencing discovery around these uncertainties makes a pilot informative. It avoids spending the pilot proving the easiest visible component while leaving the weakest benefit dependency unresolved.

The charter also needs a refusal condition. A sponsor might decline expansion if the service cannot preserve an auditable release decision, if the equipment identity remains unresolved or if the changed workflow requires a recurrent burden that operating teams cannot absorb. Refusal does not necessarily mean abandoning digital investment. It may mean repairing a prerequisite, narrowing the intended outcome or choosing a continuity replacement instead. By defining these possibilities beforehand, the sponsor prevents a pilot from becoming a ceremonial stage through which a predetermined procurement must pass.

Finally, a charter should be a living controlled proposition rather than a slogan. Discovery may show that the original problem was misdescribed. The programme should be allowed to revise the mechanism, subject to an accountable change in scope and benefit expectations. What should remain stable is the obligation to explain why the new work is expected to produce the new outcome. Changes in product labels, architecture diagrams or delivery methodology do not discharge that obligation. The record should preserve the superseded proposition so a later reviewer can understand what was learned.

In the fictional repair service, a programme sponsor initially requests predictive maintenance. The operating review discovers a more immediate issue: fault reports refer to local equipment names that the central register does not consistently recognise. Diagnosis is delayed while planners reconstruct identity. The proposed charter therefore separates an identity capability from a condition-analysis capability. This is not a claim that the first capability is always more valuable. It is a recognition that the second cannot act intelligibly on an unidentified object.

The revised proposition authorises a service discovery and a controlled identity reconciliation, with condition analysis retained as a later option. Engineering defines valid asset identity and substitution relationships. Operations confirms how those identities correspond to equipment actually released in the field. Technology supplies a usable capture and lookup service. The sponsor funds the reconciliation effort explicitly rather than disguising it as a software configuration task. An unresolved identity enters a controlled exception route instead of being assigned a plausible but unverified identifier to make the dashboard appear complete.

The benefit account now has a narrower and more defensible form. It expects fewer reconstructive handoffs for accepted fault cases and clearer release records. It does not yet promise a measured reduction in equipment failures, because neither condition detection nor intervention effectiveness has been demonstrated. That restraint improves the decision: a sponsor can determine whether the prerequisite capability deserves investment without being forced to accept a remote chain of unsupported benefits. Future condition analysis must establish its own mechanism on the improved operating foundation.

The programme may still decide to procure a platform early if continuity, cyber exposure or a contractual timetable requires it. The charter then records that decision separately from the operating benefit. It states which capability will initially remain immature, which manual control preserves continuity and which later release depends on improved evidence. A platform-first decision is not automatically irrational. It becomes weak when it uses the language of completed transformation to conceal a capability that remains unowned or untested.