When software implementation meets the brief but leaves a business decision unsupported

A system can meet its specification without changing a company’s commercial result. The specification defines what was commissioned. It does not necessarily identify which business decisions determine capacity, delivery cost, service quality or the ability to accept profitable work. Before proposing another system, I examine the decision and the conditions under which the organisation makes it.

Why the original project boundary matters

An implementation normally begins with a request. Someone has a budget, a defined operational concern and the authority to commission work. A sales leader may request better pipeline visibility. A service director may request scheduling. Finance may request cost reporting. The supplier then scopes the work around the agreed need and implements it.

This is not inherently a design failure. The supplier has a contractual boundary, and the buyer has a legitimate reason to concentrate on a particular function. The limitation appears when someone treats the project scope as if it described the complete business. A successful CRM deployment can improve pipeline reporting while leaving decisions about service capacity, actual delivery cost or contract acceptance in separate systems or processes.

Those decisions may already be well managed. Alternatively, the information needed for them may be scattered, recorded at the wrong level or never created. The research problem is to distinguish these cases before choosing a technical response.

Trace the business requirement backwards from the decision

I use five questions in sequence. Each answer changes the next question; skipping one creates plausible but unreliable implementation recommendations.

The chain does not prove that a business needs new technology. It establishes where an IT partner should ask its client for evidence. If an owner or system cannot be identified from public information and the implementation documents, the correct label is not established, not absent.

Worked example: a service contract sold before its delivery is understood

Consider a hypothetical maintenance company. Its CRM partner has implemented an opportunity pipeline and an automated handover when a deal is closed. The pipeline works: contract values are reported and jobs are sent to the service team. The company also sells response-time commitments that depend on engineer availability, travel and parts.

Suppose the partner is considering another automation because service mobilisation sometimes requires clarification. A convenient solution would be to add required CRM fields and another notification. That may help, but several different operating conditions could explain the same symptom.

These are alternative explanations, not four findings about one company. The information needed to choose between them belongs with the end client. ProperBizFix can formulate the tests; it cannot infer which explanation is true merely from the CRM scope.

When a missing system reflects an unmanaged part of the operating model

Some activities occur every day without a single person owning the outcome across departments. Sales accepts commitments; Delivery handles execution; Finance sees the final cost. Each function may have adequate tools for its own work, while no one has defined who should compare a promise with the resources required to fulfil it.

That can create an information gap. A service system may record hours, a CRM may record quoted value and an accounting tool may record invoices, but there is no agreed business event at which those records are reconciled or acted upon.

It does not follow that every company needs centralised control, job-level costing or another application. The decision may be immaterial for its operating model, the cost of capture may exceed the benefit, or authority may be deliberately distributed through working controls. These possibilities must be tested rather than assumed.

For an IT supplier, the distinction is commercially important. If the client has not decided who will act on a new metric, building a dashboard first risks delivering technically correct information with no operational use. The better next conversation may be about operating rules rather than a software feature.

How I decide whether something becomes an Intervention Candidate

I retain a candidate only when the available evidence supports a specific, consequential question. Each record contains:

1. Economic relevance: the revenue, cost, capacity, delivery or risk consequence that makes the decision potentially material; any expected effect remains a hypothesis until measured.
2. Decision and authority: the action that would change, the function that should answer the question and whether responsibility is confirmed, supplier-reported or unknown.
3. Existing system coverage: known application functions, events, records and interfaces, explicitly separating the documented implementation from the rest of the client’s system estate.
4. Evidence requirement: the missing fact, data granularity or operating rule needed to evaluate the candidate.
5. Prerequisite: whether an acceptance rule, event-capture process, accountable owner or operating definition needs to be agreed before design.
6. Stop condition: evidence that would make the proposed technical work unnecessary or inappropriate.

A candidate can lead to an integration investigation, new operational record, changed workflow, a manual control or no development. It becomes a commercial opportunity only after the end client confirms a need and the supplier establishes an appropriate project.

What can be established without entering the client’s systems?

Public information and the supplier’s implementation materials can establish the business model at a useful level, identify delivered scope and generate well-founded questions. They normally cannot establish internal decision rights, the quality of live operational records, the magnitude of financial effects or whether a process is genuinely unmanaged.

I therefore separate evidenced fact, supplier-reported condition, analyst inference and not established. An unknown operating owner is an important validation question when the associated decision matters; it is not a diagnosis of weak management.

Related methods: classify the system gap, define the handover rule and analyse account expansion without starting from your services list. The illustrative account assessment shows how the questions become Intervention Candidates.

Methodological analysis by Yulia Fomina. Examples are hypothetical and do not report client findings, financial results or verified implementation defects.