From Business Problem to Software Project: Where to Start

A software project begins well when its purpose can be explained as a business problem. An owner may request a customer portal, a scheduling application, or a reporting dashboard. Those requests describe possible solutions. Before committing resources, the more useful question is what presently prevents the business from delivering good service, controlling costs, or making informed decisions.

Describe the failure in everyday terms

Choose one recurring situation and describe what happens from beginning to end. For a hypothetical maintenance company, the issue might be that approved visits remain unassigned because requests arrive through several channels. Customers telephone for updates, coordinators search messages, and technicians receive incomplete instructions. The problem is broader than the absence of an application: there is no dependable path from approval to assignment.

Record the trigger, the people involved, the information they need, and the point where progress stops. Use examples from recent work, removing sensitive details where appropriate. A statement such as “coordinators must check three places before confirming tomorrow's visits” gives a delivery team much more useful direction than “we need digital transformation.”

The UK Government Digital Service recommends understanding the problem before committing to a service in its discovery guidance. Although written for public services, this is a useful discipline for a commercial project: establish the need before choosing the tool.

Establish who bears the consequences

The person requesting software is not always the person who experiences the difficulty most directly. Ask employees who perform the work, managers who resolve exceptions, and customers who receive the outcome. Each may describe a different consequence of the same failure. An owner sees delayed revenue; a coordinator sees interruptions; a customer sees uncertainty about an appointment.

These perspectives help distinguish inconvenience from a material operational problem. Collect a small baseline: how often the situation occurs, how much time a typical case requires, and what happens when it is missed. Avoid inventing precision. A consistently recorded sample of recent cases is more valuable than a confident estimate that nobody can explain.

Also identify who has authority to change the process. Software cannot resolve conflicting approval rules if managers have not agreed which rule applies. Decisions about responsibility should precede decisions about screens.

Define a result that can be observed

A useful outcome describes a change in operations. In the maintenance example, it could be that every approved request has an accountable coordinator, a visible assignment status, and a recorded next action. This can be checked against actual requests. “An easy-to-use system” is a reasonable aspiration, but it does not explain whether the underlying problem has been solved.

Set boundaries around the result. Decide which services, offices, customer types, or stages belong in the first version. Document exceptions that require human review, such as urgent requests or missing customer information. A narrow, complete workflow is often easier to assess than a broad collection of partially connected functions.

Choose a review period and an owner for the measurement. If nobody will compare the new process with the baseline, the business may confuse successful delivery of software with successful improvement of operations.

Consider whether software is the appropriate intervention

Some problems need clearer instructions, fewer approval steps, or a better existing product configuration. A dedicated system is more compelling when work repeats frequently, several people require the same reliable information, and current tools cannot enforce agreed rules without continual checking.

Compare the likely intervention with its operational burden. Someone must maintain records, answer questions, and decide what happens when requirements change. For a hypothetical distributor, a shared order-status system may be justified by repeated coordination work. A rarely used management report might be addressed more economically by improving the existing reporting process.

The purpose of this comparison is to make the investment deliberate. Document why simpler alternatives fall short and which remaining assumptions should be tested before committing to a larger project.

Turn the problem into a manageable engagement

Prepare a short brief containing the current situation, affected people, baseline, desired result, important exceptions, and first-version boundaries. Add representative examples and nominate a business decision-maker. This allows a delivery partner to propose an approach around evidence instead of interpreting a list of preferred features.

Holism combines experienced developers, AI-assisted implementation and research, and reusable business capabilities through Software Product Line architecture. For an owner, that model offers a way to develop a focused operational solution while retaining responsibility for goals and priorities, without first establishing an engineering department. Its value is strongest when the business problem is clear enough to guide technical decisions and subsequent iterations.

A monthly retainer can support continued prioritization as the business learns from use. Agree how progress, review decisions, and operational results will be assessed. The sound starting point is a documented problem, a measurable desired outcome, and a clear decision about whether software is justified. Those foundations make subsequent investment easier to evaluate.