The operating problem
Operational software projects become expensive when the requested solution grows faster than understanding of the process. Stakeholders add dashboards, mobile apps, integrations, notifications, document generation and artificial intelligence before the team has agreed what the primary record is or who owns the next action. The opposite failure is a visual prototype too narrow to prove operational value.
Engineering judgement tied to operating evidence.
Founder and software/electronics engineer at INESSOFT. Reviewed against current INESSOFT delivery practice and operating evidence.
Published 01 Jul 2026 · Last reviewed 01 Jul 2026Start with a recent failure example
Abstract requirements encourage generic solutions. A recent delayed job, incorrect report, lost reading or rejected import reveals actual users, records, hand-offs and consequences. Trace that example from start to finish before discussing architecture.
- Bring the source files, messages, screenshots and records involved.
- Identify where uncertainty first entered the process.
- Quantify the business consequence rather than describing only inconvenience.
Name the primary record
Every focused system should own a clear business object: request, job, visit, asset, test, item, event, order or certificate. The primary record anchors identity, status, permissions, evidence and reporting. Projects become vague when several records compete for ownership.
- Choose a stable identifier and lifecycle.
- List related records without merging their responsibilities.
- Define which existing system remains authoritative for external masters.
Define the operating loop
A useful scope explains how input becomes action and evidence. Who creates the record? What validates it? Who owns each state? What output marks completion? What happens when the normal path fails? This operating loop matters more than a page inventory.
- Model normal and exceptional paths.
- Include management visibility and support recovery.
- State which actions remain manual in phase one.
Separate discovery, prototype and production
Discovery reduces uncertainty through process and technical investigation. A prototype tests a risky assumption with limited supportability. A production phase commits to reliability, permissions, diagnostics, deployment and handover. Mixing these expectations causes conflict.
- Define the decision each phase must unlock.
- Label prototype shortcuts explicitly.
- Do not estimate production scale from a demo-only build.
Integrations should earn their place
Every integration adds external dependency, failure states and reconciliation work. Include it in phase one when the operating loop cannot be completed credibly without it. Otherwise use controlled imports, exports or manual boundaries until value is proven.
- Name the source and destination owner.
- Define failure, retry and unknown outcomes.
- Use sample data and documentation during discovery.
Make exclusions visible
A scope is credible when it states what is not included: native apps, offline mode, plant write-back, ERP replacement, historical cleanup, automated migration or support for undocumented devices. Exclusions prevent assumptions from becoming surprise obligations.
- Link exclusions to risk or evidence needed.
- Separate later opportunities from current commitments.
- Review exclusions with operational users, not only sponsors.
Choose success measures before building
Measures should compare the new operating loop with the current baseline: turnaround, manual handling, error recovery, reporting time, exception age or data completeness. Vague goals such as efficiency and visibility are useful themes but poor acceptance criteria.
- Record current effort and failure frequency.
- Measure adoption and exception closure, not only screen delivery.
- Allow a phase to disprove the larger investment if evidence is weak.
Use the operating signal to choose the next action.
The same symptom can justify a custom system, a smaller integration, a stabilisation phase or no build at all. The decision should follow evidence rather than enthusiasm for a particular technology.
The problem is clear but technical feasibility is uncertain.
A focused prototype may be appropriate.
Test the highest-risk integration or device assumption.
The process itself is disputed or poorly understood.
Building would automate ambiguity.
Run discovery and process mapping before implementation.
One end-to-end workflow is understood and painful.
A production first phase can be bounded.
Control that loop with records, states, exceptions and output.
Stakeholders request many adjacent modules before first use.
Scope is expanding without evidence.
Move non-essential capabilities into explicit later phases.
Evidence that the current approach is becoming risky.
- The requirements document is a list of screens without a process model.
- The first phase includes every integration because they may be useful later.
- A prototype is described as production-ready without diagnostics or support.
- Exclusions are implied rather than written.
- Success is defined as launch instead of operational change.
What to clarify before commissioning work.
- Bring one real failure example and current artefacts.
- Identify the primary record and responsible users.
- Map the complete normal and exception operating loop.
- Choose discovery, prototype or production expectations explicitly.
- Include only necessary integrations and document ownership.
- Write exclusions, success measures and next-phase evidence.
Case studies behind the lesson.
These links provide system context, architecture, workflows and engineering decisions connected to the article.
Questions that usually appear during scoping.
How long should discovery take?
It depends on process complexity and access to systems, but discovery should be bounded around specific decisions and deliverables rather than becoming indefinite analysis.
Is an MVP always a production system?
No. Some MVPs are market experiments; others are narrow production systems. The supportability, data and reliability expectations must be stated clearly.
Should every future module be designed up front?
The architecture should leave sensible seams, but detailed design should follow evidence. Prematurely modelling every future possibility increases cost and complexity.
Can phase one still integrate with existing systems?
Yes, when integration is necessary to complete the operating loop or test a critical assumption. It should not be included merely for architectural completeness.