Almost every technology project starts with a concrete request: "we need to automate reconciliation", "we need a reporting module", "we need to integrate the CRM with billing". And almost no project ends up being exactly that. At EmasT, the distance between what a client asks for in the first meeting and what is finally built is not the exception, it is a trend, and it has an identifiable cause: discovery is not a procedure before the project, it is the first delivery of the project.
Why the initial request rarely describes the complete problem
The initial request almost always describes the most visible symptom, not the cause. An IT manager asking for an inventory dashboard is pointing out what they see every day, not necessarily the process that produces the unreliable data that feeds that dashboard. This is not a diagnostic failure of the requester: it is the reason why discovery exists. An external perspective, without the bias of living daily with the process, finds causes that are difficult to see from the inside.
What changes between the request and the delivery
In most projects where we have done discovery at EmasT, the final scope ends up touching at least one additional process than what was initially requested, almost always one that the client did not identify as part of the problem. A report that was requested turns out to be a symptom of an uncontrolled data capture process. A billing automation ends up including the prior approval flow, which was the real bottleneck. A systems integration reveals that the problem is not the lack of connection between platforms, but that both hold different versions of the same information. The request points to the effect, the discovery finds the cause.
Discovery as cross-functional consulting, not as requirements gathering.
In most project methodologies, discovery is understood as a gathering step: documenting what the client needs to then build it.At EmasT we treat it as something broader. During discovery, not only are requirements analyzed, but opportunities for improvement that the client had not put on the table are identified, and their current processes are contrasted with industry best practices. This additional perspective is, in practice, the concrete way in which EmasT anticipates as a working method that is applied from the first week of any project.
Anticipate to provide clarity, and to define what "finished" means.
Anticipating in discovery not only serves to give clarity to the client about what they really need. It also serves for something that many technology projects do not make clear from the beginning: the acceptance criteria. The result of a good discovery is the set of criteria that the client can use at the end of the project to objectively evaluate whether the delivered solution meets the need defined at the beginning. Without those criteria, the closing conversation of a project becomes subjective, depending on how well each party remembers what was agreed upon in the first meeting. With them, it becomes a verification, not a negotiation.
What does this mean for the IT leader?
This is not an uncontrolled scope expansion, it is diagnosis functioning as it should, with clear rules from the start. The difference between a well-managed scope adjustment and one that gets out of control is not whether the scope changes (it almost always changes), but whether there was, from the discovery, an objective criterion to evaluate that change. That’s why it’s worth structuring the conversation with any technology provider.assuming from the start that the discovery is not a preliminary step to the project, it is where it is defined what it means for the project to be finished.
If your team is about to start an automation, ERP, or custom development project,it’s worth starting there: not with the request, but with the diagnosis,and with the criteria that this diagnosis leaves defined to know, in the end, if the project was successful.
Let’s talk about the discovery of your next project.