Stop "Gathering" IT Requirements

Why the Traditional “Gathering” Approach Fails

In the past, every IT project kickoff featured a “requirements gathering” meeting. The idea was simple: business users hand over a list of wants and the technical team builds the solution. Yet, despite the clean structure, this phase is often the one most ignored, and it remains one of the main reasons projects fall short. When a project reaches the launch stage, more than three‑quarters of teams discover that what they built doesn’t match what the business needs.

The problem starts with the word “gather.” It conjures images of harvesting ripe fruit or collecting shells: items that already exist in a finished state, ready to be picked up. But business needs rarely appear that way. Users usually hold vague, incomplete ideas, sometimes conflicting with one another. They may think in terms of how the system should feel rather than what it should do. When you ask a stakeholder to hand you a list of features, you are asking them to present something that has already been fully shaped – a request that rarely materializes. The result is a list that looks polished on paper but feels hollow in practice.

Even if a user claims to know exactly what they want, the underlying business environment is constantly shifting. Market changes, regulatory updates, and internal policy tweaks can alter priorities between the moment a requirement is documented and the time the software is delivered. In these situations, a static “gathered” list becomes a relic. Teams that cling to it often find themselves delivering a solution that solves a problem that no longer exists.

Another issue is the passive role that the term implies. When a technical team is told to “gather” requirements, it sets a tone of compliance rather than collaboration. Think of it as a waiter taking a customer’s order without asking for clarification. The waiter’s role is to serve, but if the waiter never asks if a dish is spicy or if a sauce should be omitted, the meal will likely disappoint. Similarly, when developers simply collect what users say, they miss opportunities to refine, challenge, and align expectations.

Because the process feels ceremonial, many teams treat it as a tick‑box exercise. They schedule a 30‑minute session, fill out a template, and move on. Stakeholders often feel rushed, and their feedback ends up being a mix of “I need X,” “That would be nice,” and “We’ve seen it in other systems.” The resulting document contains more jargon than clarity, and when developers start coding, the gaps become obvious.

Project managers also tend to treat the requirement phase as a “done” state. Once the documentation is signed, the project moves into design and development. The reality is that requirements evolve. If the team does not maintain an active dialogue, the solution can drift away from business reality. The risk is compounded when the organization adopts an “agile” label but keeps the old linear approach to requirements. The mismatch between methodology and practice creates friction and confusion.

Finally, the cultural mindset that “requirements are already out there” ignores the fact that businesses often do not know what they need until they see it. Innovation thrives when ideas are tested, challenged, and iterated. By forcing stakeholders to commit to a fixed set of features early on, the organization squanders the chance to surface hidden needs or to simplify complex processes. The result is a costly over‑engineered product that solves a problem that users never asked for.

In short, the notion of “gathering” requirements treats a dynamic, collaborative effort as a static collection exercise. It sets teams up for failure by encouraging passivity, stifling conversation, and overlooking the evolving nature of business problems. To move beyond this pitfall, a new mindset is required - one that sees the early project phase as an active negotiation rather than a harvesting task.

Turning the Process into Negotiation

Replacing the “gather” mindset with a negotiation mindset turns the early phase into a collaborative workshop where all parties share ownership. Instead of asking users to hand over a list, the team invites them to discuss what they want, why they want it, and how it aligns with broader objectives. This conversation turns the requirement list into a living document that can evolve as the project moves forward.

Think of the end result as a treaty between different nations: each stakeholder brings a set of interests, constraints, and priorities. The goal is to find common ground, acknowledge trade‑offs, and agree on a realistic, mutually beneficial outcome. The process is intentionally dynamic; the parties negotiate terms, propose alternatives, and revise their positions based on new information.

To make this work, teams need to adopt a facilitation role rather than a collection role. The facilitator - often the business analyst or project manager - sets the agenda, frames questions, and keeps the discussion focused. The facilitator also monitors the flow of information, ensures that every voice is heard, and guides participants toward compromise when interests clash. This proactive stance eliminates the feeling that the technical team is merely serving an order; instead, they become partners in shaping the solution.

Another advantage of negotiation is that it naturally incorporates stakeholder priorities. Early on, the group discusses which features are essential, which are nice‑to‑have, and which can be deferred. This prioritization surfaces during the discussion, not after a checklist is completed. As a result, the final set of requirements reflects the true business value rather than a list of user requests that may later be ignored due to resource constraints.

Negotiation also addresses the issue of changing needs. Because the requirements are part of an ongoing conversation, the team can revisit them whenever new information emerges. Instead of locking into a fixed document, stakeholders and developers hold a shared understanding that can adapt. If a market shift demands a new feature, the group can add it to the next iteration, ensuring the project remains relevant.

From a technical perspective, the negotiation process encourages early validation. Developers ask questions like, “What data must the system capture?” or “How will you measure success?” These inquiries reveal hidden dependencies and integration points that would otherwise be discovered late, causing costly rework. By surfacing technical constraints early, the team can design architecture that supports the agreed‑upon functionality.

Negotiation also fosters accountability. When stakeholders participate in shaping the requirements, they are more likely to advocate for the solution once it is built. The sense of ownership reduces the risk of “scope creep” because each party has already agreed on the core features. If a change request comes in later, the team can refer back to the negotiation record to assess its impact on the agreed‑upon objectives.

In practice, the negotiation process often takes the form of workshops, storytelling sessions, or design sprints. The team might start with a problem statement, then map user journeys, and finally identify constraints. Throughout, the facilitator keeps the conversation grounded in business goals, ensuring that every feature contributes to measurable outcomes.

Ultimately, switching from a “gathering” to a “negotiating” mindset transforms the early project phase from a passive exercise into an active partnership. It ensures that the final requirements are realistic, prioritized, and aligned with business strategy. By treating requirements as a negotiated treaty rather than a harvested list, organizations dramatically improve their chances of delivering solutions that truly meet user needs and drive value.

Paul Glen, IT management consultant and author of “Leading Geeks: How to Manage and Lead People Who Deliver Technology,” emphasizes the importance of this collaborative approach in his work. For more insights, visit Murdok