[Table of contents]Show table of contents
IT projects do not die during implementation. They die at the definition stage — you just do not see it immediately, because the death is slow. For the first few months everyone is proud of the demo, the team burns through story points, and the KPI dashboard glows green. The problem surfaces in month six, when the system touches a real business process and turns out to solve the wrong problem. Or the right problem the wrong way. Discovery is the antidote. Provided it is done well.
Over the past eight years we have run dozens of discovery processes for companies between 20 and 500 employees. The patterns repeat with mathematical regularity. This piece is a distillation of those patterns into an executable form — not textbook theory, but a framework that produces business decisions in 10 working days.
Why projects die at the definition stage
An FMCG client (dried-fruit producer, ~180 employees, 90M PLN turnover) came to us with a brief for a new CRM, because “a competitor rolled out Salesforce and we need the same.” The brief was 14 pages of requirements copy-pasted one-to-one from the vendor’s webinar. The first question at kick-off: “which KPI is this CRM supposed to move?” The answer: silence, then “well… digitalization.” That is the archetype of the first cause — a brief copy-pasted from a competitor. You copy the solution without understanding the problem it solves. The result is a system that looks like the competitor’s but does not produce the same value, because it was never tailored to your reality.
The second cause is less visible from the boardroom: the brief is built exclusively from manager conversations. The department head describes how the process “should work.” The employee running that process eight hours a day knows how it actually works — with the workarounds, the shadow-IT spreadsheets, the tribal knowledge nobody has written down. Systems designed purely from manager interviews always describe fiction. Implementation collides with reality in month four, when end users start UAT and say “this is not how we work.”
The third cause: the business goal eclipsed by a feature list. The brief carries 87 requirements, but not a single sentence describes why the system is being built in P&L terms. A feature is a means, not an end. When discovery does not ask “by how many percent should margin grow, cost fall, cycle time shorten?”, the implementation team has no prioritization criterion. Every feature becomes equally important, the project blows its budget, and the board cannot judge whether it got what it wanted — because it never defined what it wanted.
Our definition of discovery — what it is NOT
Discovery is not a post-it workshop. Two days in a room with a flipchart generate team empathy but do not produce a business decision. A business decision requires data — interviews with 12-18 people, an as-is process map with time and cost metrics, a comparison of three architectural scenarios. A post-it does not replace a TCO analysis.
Discovery is not a technical audit. A technology audit examines what already exists — code quality, technical debt, the scalability of the current architecture. Discovery examines what is to be built and whether it should be built at all. The audit answers “how is it?” Discovery answers “what are we building, why, at what cost, and with what return?” Two different processes, frequently confused in client briefs.
Discovery is not a requirements list. An 87-item functional requirements document is an output of the implementation phase, not the definition phase. Discovery produces something harder: a go / no-go / pivot decision with a forecast of business value, a TCO cost model, and an analysis of alternatives. The requirements list follows from that decision — it is not its input.
Discovery is a diagnosis whose job is to produce one thing: a business decision with unambiguous reasoning. Everything else — process maps, architecture, estimates — is evidence, not the deliverable.
DoMoreSoft Discovery Framework — 5 phases explained
We named the framework not because we enjoy naming things, but because a named process is replicable. An unnamed process dies with the one person who “knows how to do it.” Five phases, ten working days, two seniors on the Do More Soft side (systems architect plus process consultant), defined deliverables at the end of each phase.
Phase 1 (Days 1-2): Stakeholder map and problem articulation
The first two days go into mapping the battlefield. The stakeholder map answers four questions: who pays for the decision, who uses it, who is its victim, who holds veto rights. These roles almost never collapse into one person, and ignoring any of them is the single most common cause of project failure.
From that observation comes a concrete operational decision: in parallel we sit with the board on problem articulation and force an answer to “how will we recognize that the project was a success?” in P&L metric terms, not a feature list. If there is no answer to that question within 48 hours, further phases make no sense — discovery stops and goes back to the board for a decision.
Phase 1 output: stakeholder map with highlighted interest conflicts, a one-paragraph problem statement, and success metrics with target values signed off by the project sponsor.
Phase 2 (Days 3-5): User interviews — 12-18 people across at least 3 roles
Three days of one-on-one interviews. Not group. Group interviews produce consensus, and consensus hides the truth. At least three roles: end user (the person who works with the system every day), manager (the person who reports based on the system), and external stakeholder (customer, partner, regulator). Each interview runs 45-60 minutes, follows a structured script, and produces a transcript tagged for pain points, workarounds, and hidden processes.
Phase 2 output: a base of 12-18 transcripts with a taxonomy of problems, a top-10 list of pain points ranked by frequency, and a map of shadow IT (spreadsheets, private macros, WhatsApp groups substituting for processes).
Phase 3 (Days 6-7): Process mapping and bottleneck identification
Based on the interviews we build an as-is process map with metrics — number of steps, time per step, manual data-rekeying points, decision points, transfers between systems. On this project the as-is map had 47 steps, the to-be map had 12. The delta between as-is and to-be is the business value of the project, expressed in labor hours and operating cost. In parallel we apply our bottleneck identification methodology — 5 types of bottlenecks, from manual rekeying to over-reporting.
Phase 3 output: an as-is process diagram with metrics, a to-be map with identified bottlenecks, and a bottleneck register with estimated annual cost for each.
Phase 4 (Days 8-9): Architecture sketch and cost model
Two days on business and technical architecture plus the TCO model. The architect prepares three scenarios: build (custom development), buy (off-the-shelf product with configuration), and hybrid (off-the-shelf core plus custom modules). Each scenario carries a three-year TCO model — implementation cost, maintenance cost, the cost of technical debt, and a scalability forecast. These are not back-of-the-napkin guesses. They are models benchmarked against our prior projects in the same class.
Phase 4 output: three architectural scenarios with component diagrams, a three-year TCO model per scenario, and a risk analysis with mitigation plans.
Phase 5 (Day 10): Decision report with three scenarios
The final day is consolidation and board presentation. The decision report follows a fixed structure: problem statement, diagnosis (as-is map, bottlenecks), three scenarios with a recommendation, a three-year ROI/TCO model, and roadmaps for 90 days and 12 months. The presentation runs 90 minutes — 30 minutes of report, 60 minutes of discussion and board questions. The session ends with a decision: go, no-go, or pivot. If go — we start the scoping and implementation planning phase, whose methodology we share in MVP in 8 weeks.
Phase 5 output: decision report (30-50 page PDF), executive-summary presentation, and a documented, signed-off board decision.
What the client receives at the end of 10 days
The deliverable list is always the same, because we consolidated it after running several dozen discoveries:
- As-is and to-be process maps with time and cost metrics per step.
- Bottleneck register with an annual-cost estimate for each.
- Three solution scenarios (build / buy / hybrid) with a three-year TCO model.
- Technical-debt assessment of the existing system, where one exists.
- Team and skills gap analysis — who is missing to maintain the new solution.
- A recommended roadmap: 90-day plan (quarterly milestones) and 12-month plan (strategic annual goals).
- A decision report with an unambiguous go / no-go / pivot recommendation.
Case: how 10 days of discovery saved 6 months of development
An FMCG client — a producer and distributor of dried fruits and nuts — came to us with the brief “we need a new CRM, the current one is holding us back.” The brief was 14 pages of functional requirements. Instead of estimating immediately, we proposed 10 days of discovery. Interviews with sales reps, warehouse staff, and logistics revealed something the brief did not show: the real problem was not the CRM but the order-flow process between sales, warehouse, and logistics. The CRM worked — but every order passed through 4 manual data transfers between systems, generating delays and errors.
Recommendation after discovery: pivot. Instead of building a new CRM over six months for 300k EUR, we proposed an integration layer — a synchronization module between existing systems — for 85k EUR over 8 weeks. The rollout is described in the Terra case study and in the narrative article “Terra — from spreadsheets to a system”. Ten days of discovery shifted the project from building the wrong thing to solving the right problem. Savings: six months of team time and 215k EUR net.
Why two weeks, and not two months
Discovery can take arbitrarily long — we know companies that run it for six months. In practice the marginal value of each additional day falls exponentially after day ten. In the first 10 days we uncover 80% of the problem. The next 10 days? Another 15%. That is not opinion — it is a pattern from 50+ discoveries we have run across domains from FMCG through automotive to SaaS.
The second reason is cultural: Parkinson’s law says work expands to fill the time allotted. Discussions stretched over months produce analysis paralysis, not decisions. A hard 10-day frame forces prioritization discipline — if something does not fit into 10 days, it will not fit ever, because it is less important than it appeared. Teams given two months for discovery produce 300-page reports nobody reads. Teams given 10 days produce a 40-page decision report the board reads in 45 minutes and acts on.
Skipping discovery is like skipping diagnosis before surgery. The client wants to go under the knife fast. A week later you are operating on the wrong disease. Discovery is not a phase you skip because “there’s no budget for it” — it is the phase with the highest ROI leverage in the entire project, an order of magnitude greater than any implementation optimization.
ROI of discovery — the concrete math
Discovery cost under the DoMoreSoft model: 15-25k EUR for 10 days of two seniors. The cost of a wrong six-month implementation: 200-400k EUR in rollout budget, plus opportunity cost — the six months the business team spent sponsoring the wrong project instead of a different initiative.
The break-even arithmetic is trivial. On an implementation project with a 300k EUR budget, a discovery costing 20k EUR pays back if it avoids 6.7% of wrong scope. In practice, discovery cuts scope by 15-30% (features that looked critical turn out to be unnecessary after user interviews) and reduces the risk of full failure by orders of magnitude. Discovery always has positive ROI. The math is against every alternative.
The numbers above can be verified against our own projects and case studies. Terra’s discovery saved 215k EUR. Discoveries on dealer-group projects saved between 120k and 380k EUR per rollout. We do not know of a single discovery that did not ultimately return ten or more times its cost.
When discovery is unnecessary
We advocate discovery, but we are not fanatics. There are three situations where discovery wastes client money:
First: you already have a working prototype with real users and a validated problem. If your prototype has 200 active users paying for the product, the problem has been market-validated. The next phase is scoping and scaling, not discovery. Running discovery after a prototype phase is expensive and redundant.
Second: the project scope is one service on an existing platform. Adding a reporting module to a system we already know does not require discovery. It requires a 2-3 day scoping and estimation session. Discovery is a tool for complex problems, not for every ticket.
Third: you are building something you have already built twice in the same domain. If as Do More Soft we have rolled out three CRMs for automotive, we will roll out the fourth without discovery — we have the process patterns, the architectural patterns, and the integration patterns. Discovery has value in exploration. When the exploration is already done, further discovery is theater.
In every other case — especially when you are changing a fundamental business process, entering a new domain, or integrating systems that have lived independently — discovery pays off. Always.
We do it ourselves — our own products went through discovery
It is easy to preach water and drink wine. So when building our own products under the Venture Builder model, each one went through internal discovery before we wrote a line of code. MoreSales — our CRM/ERP for e-commerce — came out of a three-week discovery with ten e-commerce companies wrestling with the same problem. MyCarApp — our automotive platform — came out of six weeks of interviews with dealers, factory logistics, and end customers.
Each of our 12 products is proof that discovery works on our own P&L too. If we had skipped discovery, today we would have four products, not twelve — because the rest would have died within six months of launch, failing to find a market. This is not the hypocrisy of “preaching water while drinking wine.” This is skin in the game — we use the same methodology we teach clients, and we show it works on us.
Discovery as the highest-ROI lever
If you are a CTO or founder planning a project worth 200k EUR or more, the question is not “should we do discovery?” but “when?” The answer: at the very beginning, before the first line of code is written, before the architect starts drawing diagrams, before the PM starts laying out the backlog. Discovery is 5-8% of the project budget protecting the remaining 92-95% from misallocation.
Not sure whether your project needs discovery? Write to office@domoresoft.com with the subject “Discovery check” — 30 minutes of conversation is enough for us to jointly decide whether discovery pays off, or whether this is one of the three cases where it can be skipped. If you prefer a structured format, use our configurator — four minutes. Both paths lead to the same conversation, in which we settle whether there is sense in going further. It is the first decision worth making consciously, because every subsequent one depends on it.
FAQ — discovery in a nutshell
What does the discovery process mean in software development?
A structured phase preceding implementation whose purpose is not to write down requirements but to make a business decision: go, no-go, or pivot. Under the DoMoreSoft model it runs 10 working days, covers 12-18 stakeholder interviews, as-is/to-be process mapping, three architectural scenarios, and a three-year TCO model.
How much does discovery cost compared to the whole project?
5-8% of the implementation budget. On a 300k EUR project, discovery costs 15-25k EUR and pays back if it avoids 6.7% of wrong scope. In practice it cuts scope by 15-30%.
Why do 90% of IT projects die without discovery?
Because without discovery the implementation team works on the wrong problem, or on the right problem in the wrong way. Three archetypes: a brief copy-pasted from a competitor, interviews only with managers, the business goal replaced by a feature list.
How does discovery differ from a technical audit?
A technical audit answers “how is it?” inside an existing system. Discovery answers “what are we building, why, at what cost, and with what return?” On a project that needs both, the audit is one input into phase 3 of discovery — not a substitute for it.