Blog Post

In software development and digital transformation, one of the most common mistakes doesn’t happen at the implementation stage. It happens much earlier: when an organization arrives looking for a tool, but hasn’t yet achieved sufficient clarity about the problem it actually needs to solve.

It happens frequently. A client arrives saying: “we need a CRM,” “we want a campaign platform,” “we’re looking for a helpdesk solution,” or “we want to automate customer service.” But when we dig deeper, we discover that what exists isn’t a well-defined requirement — it’s a general intention, a diffuse need, or an expectation about a technology. And that distinction completely changes the risk profile of the project.

That nuance matters more than most organizations realize. Harvard Business Review has consistently argued that digital transformation doesn’t fail because of a lack of technology, but because organizations approach transformation as if it were a tooling problem. MIT Sloan, for its part, has observed that many companies remain dazzled by digital capabilities, yet are less prepared to manage the real transformation: culture, communication, priorities, and decision-making.

When the Client Brings a Brand, Not a Problem

In our experience, many organizations begin their search with the product name rather than the process definition. They arrive with a technology preference before having answered foundational questions: What do they want to improve? What decision needs better information? What operational friction do they want to eliminate? What indicators do they expect to move? Who are the actors involved? What exceptions exist? What real constraints does the business face?

This is precisely why we have incorporated, even as a commercial practice, initial advisory sessions designed to bring clarity to the problem. In some cases, we provide a short initial orientation to help the client build a basic requirements matrix. But we have also learned that for complex processes, that matrix alone is often insufficient. There are moments where the responsible approach is not to rush toward a quote, but to recommend formal hours of discovery, analysis, and structuring — even if that delays the sale.

There is a very concrete reason behind that stance. PMI found that 47% of unsuccessful projects fail to meet their objectives due to poor requirements management. It also reported that when organizations identify poor communication as the primary cause of failure, three out of four say that problem negatively affects requirements management. Moreover, only 49% say they have the necessary resources to do this work well, and barely 46% use a formal process to ensure unbiased requirements capture.

This confirms something visible in daily operations: requirements gathering is not a documentary formality. It is early-stage risk management.

The House, the Architect, and the Builder

When explaining this to clients, we often use a straightforward analogy: building a house.

If a person dreams of building their home, they typically shouldn’t go directly to a builder with vague ideas like “I want something spacious, beautiful, and modern.” The reasonable path involves a definition stage first: how many floors, where the garage goes, how spaces connect, whether there will be future expansions, what loads the foundation must bear, how people will move through the space, and what trade-offs exist between aesthetics, cost, and functionality.

That upfront work doesn’t build the house — but it makes it possible to build it well.

In software, the same logic applies exactly. When an organization commissions development with ambiguous, abstract, or overly general requirements, the risk doesn’t disappear: it simply moves downstream. And when validation time arrives, familiar phrases emerge: “I didn’t picture it that way,” “that flow isn’t right,” “that approval step was missing,” “that data should have been persisted,” “that integration wasn’t considered,” “that role shouldn’t see this.”

In a house, correcting late means knocking down walls. In software, correcting late can mean redesigning workflows, redoing integrations, reworking permissions, rewriting business rules, modifying data models, or rebuilding entire components. Change is possible — but the cost of change escalates significantly the further downstream ambiguity is carried.

A Requirements Matrix Helps, But Doesn’t Always Solve Everything

A requirements matrix is useful. It organizes ideas, delimits scope, enables better conversations, and helps reduce ambiguity. But in more complex projects — those involving multiple actors, operational exceptions, approval workflows, integrations, auditability, reporting, or compliance requirements — it often isn’t enough on its own.

That’s where more robust artifacts become necessary: user stories, acceptance criteria, process maps, clickable prototypes, role definitions, alternative scenarios, business rules, and impact analysis.

MIT Sloan has reinforced this perspective from two angles. On the design side, it highlights that the cycle of prototyping, testing, and gathering feedback is critical to ensure a solution actually works for the client, is feasible to build, and can be supported operationally. On the agile side, it underscores that iterations with prototypes, tests, and feedback allow users to clarify what they actually need earlier — rather than discovering too late that the final solution doesn’t match their expectation.

PMI reaches a compatible conclusion: a requirements baseline helps define how product success will be measured, and sound requirements management is the best defense against scope creep. For us, discovery is not bureaucracy. It is an investment in reducing uncertainty before committing budget, time, and reputation.

The False Dilemma Between Waterfall and Scrum

Another frequent mistake is the belief that only two paths exist: either run the project entirely in waterfall, or do everything “agile” from day one.

Our experience suggests something different.

There are contexts where a highly iterative approach works very well: startups, new products, open budgets, teams with high business availability, tolerance for iteration, and a need to pivot quickly. In those cases, exploring, adjusting, and rebuilding is a natural part of the model.

But there are also organizations where that approach doesn’t apply in the same way. Companies with fixed budgets, slow validation cycles, dependencies on multiple departments, regulatory frameworks, restrictive calendars, or cultures less prepared for a pure agile dynamic don’t always achieve good results by improvising as they build.

In those contexts, a hybrid approach often makes more sense: gather and analyze requirements upfront, prototype, agree on key criteria, and then execute development and testing in short iterations. PMI documents precisely this kind of scenario — projects with aggressive timelines, diffuse scope, or strong constraints — where a hybrid scheme allows for upfront scope and requirements definition, while dividing development and testing into sprints with frequent validations. MIT Sloan also notes that agile works best in uncertain, customer-centric processes, while not every environment benefits equally from that model.

In other words: this is not about defending a methodology on ideological grounds. It’s about choosing a governance model that reduces risk and improves the probability of success given the client’s real context.

AI Accelerates a Lot — But Doesn’t Substitute Clarity

Today there is a new dimension to this conversation: artificial intelligence.

In our practice, AI has already changed how we approach requirements gathering, onboarding, analysis, prototyping, interface design, front-end and back-end acceleration, technical documentation, quality assurance, and DevOps support. It allows us to process more context, structure information better, generate artifacts faster, and reduce the time between idea, analysis, design, and execution.

McKinsey argues that AI can transform the entire software product development lifecycle, increasing speed and quality, and enabling better data sources and feedback loops to build more client-centric solutions.

But there is an important caveat: AI accelerates execution — it doesn’t magically correct strategic ambiguity.

If the original problem is poorly framed, AI can help produce output faster — in the wrong direction. It can draft user stories, suggest workflows, prototype interfaces, and generate code. But it doesn’t replace the critical conversation about objectives, priorities, constraints, dependencies, operational exceptions, and value definition.

The core point remains unchanged: clarity first, then speed.

Our Position

After many projects, our conclusion is simple: the healthiest implementations don’t begin when a client picks a tool. They begin when the client achieves sufficient clarity about their problem.

That’s why we defend a practice that is sometimes less commercially convenient in the short term, but far more responsible over time: dedicating real time to requirements gathering, analysis, prototyping, and structuring before committing to a definitive scope. This protects the client — but it also protects the implementer.

When requirements are vague, the quote inevitably carries more uncertainty, more assumptions, and more estimation deviation. When the problem is better understood, estimates improve, conversations shift, and the project becomes far more governable.

In a market obsessed with speed, it’s worth remembering: moving forward without clarity isn’t always moving faster. Most of the time, it’s just arriving sooner at rework.

Supporting Sources

• Harvard Business Review — Digital transformation as a challenge that must not be treated solely as a technology problem.
• MIT Sloan Management Review — Why organizations are dazzled by technology, the importance of focusing on business value, communication, and iterative prototyping with feedback.
• Project Management Institute (PMI) — Impact of poor requirements management, scope creep, communication failures, and the value of hybrid project approaches.
• McKinsey & Company — The role of AI in accelerating the full software development lifecycle.