Most failed software projects were set on that course in discovery, the weeks before engineering starts. The usual causes are requirements nobody tested, rules nobody questioned and risky assumptions nobody checked. Adding engineers later seldom repairs any of the three.
Surveys of Indian technology leaders point the same way. In its India Enterprise Technology Report 2026, Bain reported that three out of four leaders cited a lack of alignment between business unit and IT goals (Bain, India Enterprise Technology Report 2026). Discovery is where that mismatch gets resolved, or gets built into the system.
Four questions that decide the outcome
Teams skip these because each one makes the plan look longer before it makes it safer.
Who performs the work, and how do they cope when a rule fails?
The manager who describes a process at kickoff often does not do the work. The difference between that account and the operator's is where the real requirements are. Someone from the build team should watch the work and not only interview about it, because people stop noticing their own workarounds.
Which requirements are law and which are habit?
Rules from a regulator, a contract or an auditor stay. Habits go on a list for a decision. Teams often find that a supposed system limit is only a convention from before a rule changed. Sorting them removes scope, which a priority workshop only postpones.
What happens at year-end, audit or peak season?
Teams specify against an average month, and the system then strains in an unusual one. Year-end closing, a statutory audit, the yearly price revision and festival peaks are the days on which users judge it.
How are exceptions handled today?
Any process at volume throws up exceptions, and staff knowledge lives in how they are resolved. Write down each one with the person who resolves it. A design for the normal path covers only part of the work.
Write requirements you can test
A wish cannot be built or tested. A requirement can. Try this on each line: if two engineers read it apart, would they build the same thing, and could a third person check the live system against it?
| Wish | Requirement |
|---|---|
| Approvals should be quick | A requisition below the department's approval limit goes to one approver, and moves up a level if untouched for 2 working days |
| The system should be secure | Each search and report applies the access rules of the source record, checked for the logged-in user at the time of the request |
| Reports should be accurate | Each day, stock on hand is compared with the ledger, and any gap beyond an agreed tolerance raises an alert before month-end |
| Handle returns well | When goods come back against a part-paid invoice, the system raises a credit note and posts the adjustment on the same day |
Each right-hand line names an actor, a trigger, a result and a limit. Those four parts are what make it testable.
Check the risky assumptions early
Every plan carries two or three assumptions that can sink it. They are usually the same three.
- The legacy interface. It exists on paper. A short test tells you whether it returns the field you need, at your volume, with no nightly downtime.
- The state of the data. The work of moving data follows its quality and not its size. Take a real extract and count the duplicates, mixed units and gaps in history. See ERP data migration: what goes wrong.
- Accuracy on your own documents, if any part uses AI or automation. A benchmark score says little about your scanned invoices.
Test each in a short, throwaway build in the first weeks. A one-week test that finds a blocker costs a fraction of the same discovery in month eight.
What a discovery phase should hand over
A slide deck does not close discovery. Ask for these documents.
- Process maps showing the work as people really do it, including the exceptions and the spreadsheets kept beside the systems.
- A written problem definition that states what changes if the project works, in terms a person outside IT can verify.
- Requirements as testable statements, sorted into legal duties and business preferences.
- Test results for the riskiest assumptions, with evidence.
- A target design and phased plan with a cost per phase, written so that any capable firm could build from it.
The last point is the test of a real blueprint. A plan that only its author can follow ties you to that author. Also check who owns the documents: you should, whether or not you continue with the firm that wrote them.
What the extra weeks buy
It does add time at the start. In return, you avoid rebuilding a module against a misread requirement, or learning in user acceptance testing that nobody designed the exception path. Discovery is the stage where a change of direction costs a meeting. For how rollout order affects risk after that, see big-bang versus phased rollout, and for the full delivery sequence, the custom ERP implementation guide.
Questions buyers ask
Why do enterprise software projects fail?
Mostly because requirements were vague, assumptions went untested and discovery was skipped. Weak code is seldom the first cause.
What makes a line a requirement and not a wish?
A requirement can be tested: it names who acts, what triggers it, what result follows and what limit applies.
Which assumptions should be tested first?
The legacy interface, the data and any AI accuracy on your documents.
What should discovery hand over?
Process maps, a problem definition, testable requirements, evidence on the risky assumptions and a phased plan with costs.
Where Brihat Infotech fits
Brihat Infotech runs discovery as a separate, paid phase whose process maps and problem definition you own, in its product discovery work. Start a conversation.