Custom software can perform exactly as requested while changing very little about the business. A dashboard is delivered, but the decision still happens in a spreadsheet. A planning tool produces recommendations, but employees must reconstruct missing context before using them. The project completes its features while the expected operating improvement remains hypothetical.
For a sponsor, the central question is whether the proposed application has a credible path from software behavior to changed work and then to a business result. Each step needs an owner, evidence and a way to detect when the assumption is wrong.
This article addresses value failure rather than technical project failure. Reliability, security and delivery discipline remain necessary. They do not, by themselves, establish that the application solves a worthwhile problem or that the organization will use it in the way the investment case assumes.
State what the application enables a person or process to do differently. Then identify the operational effect and the business consequence. A report may help a manager identify a problem earlier; value depends on the manager having a useful response and acting while it can still change the outcome.
A practical value hypothesis therefore connects application behavior, user action, operating change and business result. This is a proposed reasoning aid, not a validated causal model. Its purpose is to expose assumptions that a feature list leaves implicit.
For each link, ask what evidence supports it. Do users currently need the information? Can they act on it? Is the required authority available? Will another constraint prevent the expected improvement? Which part is already known and which requires investigation?
The UK’s Service Standard asks teams to define success and identify measures of whether a service solves its intended problem, combining performance data with user research. Its public-service publishing obligations do not apply automatically to a private enterprise application; the underlying measurement discipline is useful. Service Standard point 10, published 2019 and updated 2022.
A software feature may improve one step while leaving the total task unchanged. Faster data entry can be offset by additional checking. A new dashboard can create another place to look without replacing an old source. An automated recommendation can require enough interpretation that the user continues with the previous method.
Observe the workflow before defining the solution. Include preparation, waiting, verification, exception handling and downstream correction. Ask users what information they trust and why they perform the workarounds that the proposal intends to remove.
Distinguish unnecessary work from work that carries an unrecognized control or decision. A manual check may exist because source data is unreliable. Removing the check without addressing that reliability can make the process faster and less dependable.
The application boundary should reflect the task that creates value. It does not need to absorb every adjacent function, but it must account for the dependencies that determine whether its output is usable.
Consider a hypothetical field-service company commissioning a custom daily planning tool. All times below are invented to illustrate the analysis, not measured client results. The existing planning process takes two hours and includes checking customer access windows and specialist availability.
The new application produces a draft plan in thirty minutes. The initial business case describes a ninety-minute saving. During a controlled pilot, however, planners spend another ninety minutes checking and correcting access constraints that the application does not receive from the source records. Total planning effort remains two hours.
The software may have reduced one activity, but the end-to-end capacity benefit has not been established. A dashboard showing faster draft generation would overstate the improvement if it omitted the verification work.
The team investigates why the constraints are missing. Some are recorded in free-text notes, some change after appointments are accepted and some are known only to a local coordinator. A better planning algorithm alone cannot resolve those information and ownership gaps.
The next experiment focuses on one service area with a controlled method for capturing and updating the required constraints. The team measures complete planning effort, the usability of the resulting schedule and the exceptions encountered during actual dispatch. It also checks whether the information-capture process adds work elsewhere.
If the revised approach produces a useful improvement, the business can evaluate whether it scales. If maintaining the input information costs more than the benefit, the right decision may be a narrower application or a different process intervention. The pilot is valuable because it tests the mechanism, not because it proves the original proposal correct.
A product owner can prioritize features without having authority to change the surrounding operating model. If the expected value depends on retiring a spreadsheet, standardizing a decision or reallocating work, identify the person who can make that change.
Assign benefit ownership to the business, with technical and operational support. The owner should understand the baseline, proposed mechanism, required behavior and review conditions. Their role continues after the development milestone.
Avoid assigning an outcome to someone who controls only one of its dependencies. A support manager may be able to change routing but not the upstream data that drives it. The sponsor must coordinate the cross-functional commitment or adjust the benefit claim.
Make the operating change visible in the delivery plan. Training, policy decisions, data stewardship and retirement of duplicate work should not appear as optional tasks after the application is considered complete.
Logins and screen visits show activity. They do not establish that users completed the intended task or made a better decision. Measure the behavior that the value hypothesis requires.
For the planning example, this might mean an authorized planner accepts a usable schedule with the necessary constraints, exceptions are handled through the intended route and the old reconstruction process is no longer required for the tested population. The exact measures should fit the work.
Observe why users choose another route. They may be avoiding a defect, compensating for missing information or using a legitimate process the design overlooked. Treat that evidence as a product finding before labeling it resistance.
Include occasional users and difficult cases in the evaluation. A product that works for its most engaged champions may still create excessive burden for the broader population. The business needs to understand that boundary before expanding the deployment.
A change in performance after launch does not automatically establish that the application caused it. Demand, staffing, customer mix, policy and other initiatives can affect the result.
GAO’s 2012 evaluation guide distinguishes evaluation questions and designs according to the decisions they need to support. Its government-program context does not supply an enterprise-software ROI formula. The relevant discipline is to choose evidence proportionate to the claim and examine context rather than treating a trend chart as complete explanation. Designing Evaluations, 2012 Revision.
Where feasible, compare similar work with and without the new approach or introduce changes in stages. Examine whether the populations and conditions are comparable. A comparison group is not automatically credible simply because it has not received the application.
Where stronger attribution is impractical, document the mechanism, observed changes, competing explanations and limitations. A bounded contribution claim can be useful. False precision about software-only savings can distort later investment decisions.
Keep economic categories separate. Released employee time is capacity until the organization uses it in a way that produces a defined benefit. A service improvement may matter without becoming a direct cash saving. Do not add several descriptions of the same effect into an inflated total.
A custom application continues to need maintenance, support, security work, data ownership and adaptation to business change. If the investment case funds only initial development, the organization may launch a capability it cannot sustain.
Include the work needed to observe performance and improve the product. A team without access to user feedback, operating evidence or qualified support cannot reliably determine why value is missing.
Preserve the ability to stop or narrow the application. Continued development should be justified by the remaining opportunity, not solely by the amount already spent. A smaller product that solves a clear problem may be preferable to completing a broad roadmap whose value assumptions have failed.
Define review points around evidence. Which assumption must be tested next? What result would justify expansion? What would trigger redesign or retirement? These decisions keep the application connected to business value rather than an endless list of requested features.
Before funding another release, ask for a concise account of the intended user action, observed workflow effect, realized or still-hypothetical business consequence and remaining operating cost. Include what the team learned that contradicted its original assumptions.
The review should lead to a decision: continue, revise the workflow, improve a dependency, narrow the population or stop a feature that does not earn its upkeep. It should not become another presentation that treats every finding as support for more development.
Custom software delivers value when its capabilities become useful changes in how the business operates. Begin by tracing one proposed feature through the complete task and the action that creates the benefit. If the chain breaks, repair the value hypothesis before adding more code.
