The most expensive chaos happens before coding
Delivery problems rarely come from technology alone. More often nobody has authority to decide, departments use different names, data lives in several spreadsheets and requirements are ideas without priorities. Engineers can move quickly and still build the wrong system.
Preparation does not mean writing a complete specification without the delivery team. It means bringing people, processes and decisions into a form that lets everyone discover the right scope.
One person must own decisions
The company needs a product owner who understands the goal, has time to answer and resolves conflicts. A committee may advise, but it cannot postpone every decision. Without ownership, small questions wait for a week and the team builds assumptions.
Describe a working day, not imagined buttons
The best analysis input is a concrete flow: where a case arrives, who checks it, which data is added, when its status changes and what happens during an exception. Screen sketches help later; too early, they can preserve a broken process.
- three common work scenarios
- two difficult exceptions currently handled by phone or spreadsheet
- the owner of every stage
- inputs, outcome and expected time
Define the first version through an outcome
An MVP is not an unfinished system. It is the smallest safe version that completes one valuable process end to end. A feature belongs in the first release if the outcome, an obligation or evidence for the next decision cannot exist without it.
A “must have” list containing everything is not prioritisation. Separate launch essentials, post-launch needs and ideas to validate. Record the expected effect beside every feature.
Data is usually harder than the interface
Identify data sources, owners, quality and deletion rules early. Duplicate customers, missing identifiers and three date formats will not repair themselves during import. Run a trial migration while it can still change the plan.
An integration needs owners on both sides
“Connect to ERP” is not a requirement. The team needs API documentation, a sandbox, limits, authentication, contacts and expected behaviour during an outage. Retries, monitoring and reconciliation belong in the design.
Security and access before launch
- roles and permitted operations
- individual accounts rather than shared credentials
- access granting and removal procedure
- encryption and retention needs
- alert ownership, backups and restoration plan
Acceptance starts before the last day
Key users should see working increments regularly. Acceptance means completing realistic scenarios on representative data, not clicking through menus. Each stage ends with a decision: accept, correct or deliberately move outside scope.
What to bring to the first workshop
- one measurable delivery goal
- a product owner and key users
- the current process including exceptions
- a non-sensitive sample of data
- integrations and technical contacts
- time, budget and regulatory constraints
Preparation gives control rather than freezing the project
Nobody needs to know every screen or predict three years. The company needs a clear problem, decision ownership and a measure of improvement. DominPress modules and custom code can then match actual work instead of turning disorganised expectations into an expensive feature list.