The fewer meetings, the more agile? A dangerous fallacy. In this article, you will learn why starting too early actually wastes time and how you can arrive at a viable specification through realistic coordination, a targeted approach, and healthy pragmatism.
When the starting signal becomes a stumbling block
Monday morning, kick-off of a new IT project. The developers are ready, the project management team is expecting initial results, and someone says, half-jokingly: “Let’s just get started, we’ll specify later.”
A sentence that triggers a familiar feeling in many teams—and at the same time is the starting signal for later misunderstandings, rework, and unnecessary costs. Because as understandable as the desire for speed is, unclear or incomplete specifications usually end up costing significantly more time than they save.
Specification is not the same as waterfall
Many people associate specifications with cumbersome requirements documents and bureaucracy. But that is a misconception. Even in agile projects, a thorough examination of the requirements is crucial.
Eine Spezifikation heißt nicht, alles im Voraus wissen zu müssen – aber sie bedeutet, bewusst A specification does not mean having to know everything in advance—but it does mean consciously and collectively creating clarity. About the goal, the context, the requirements, restrictions, and critical factors.
It gives the project structure, promotes understanding between those involved, and prevents undesirable developments. And above all, it creates space for true agility—because the foundation is right.
A thorough specification of requirements is also crucial in agile projects.
The typical path to a viable specification
Based on our experience in numerous customer projects, a clear process has been established that has proven itself in many situations. This process leads step by step to a viable specification—while leaving room for iterations, new insights, and necessary adjustments:
- Initial requirements gathering: The client—often a product manager or stakeholder from the specialist department—formulates initial requirements and expectations. The focus is on the target vision, benefits, and framework conditions—not technical details.
- Discovery phase and queries: Architects, developers, or project managers delve deeper. They question assumptions, supplement information, and examine initial technical aspects. This often includes a small proof of concept (PoC) to validate feasibility—an aspect that is often underestimated but can be crucial. This creates a common understanding of the “what” and ‘why’—with a realistic view of the “how.”
- Structuring and initial documentation: The requirements are prepared – for example, in the form of user stories, process models, or rough concepts. If gaps or inconsistencies become apparent at this stage, further clarification is needed.
- Technical preparatory work and review: Interfaces, data flows, and feasibility are examined at an early stage. Initial sketches, mockups, or tests help to identify risks early on.
- Comparison and final coordination: In a final loop, all parties involved—from IT to the specialist department to management—coordinate once again. The aim is to clarify open issues, prioritize requirements, and establish a common understanding.
Depending on the complexity, this process can involve two, five, or more rounds. The decisive factor is not the number of meetings, but the quality of the dialogue—and the willingness to create clarity iteratively.
But how many meetings does that really require?
We have supported and evaluated numerous projects. Our experience shows that fewer than three structured coordination meetings rarely lead to viable specifications—unless the topic is very simple or has already been well prepared in advance.
In more complex IT projects, five to seven iterations are the norm. These do not necessarily take the form of traditional meetings, but are spread across workshops, written reviews, queries, or technical checks.
And the more participants with different perspectives are involved—IT, specialist departments, external service providers—the greater the need for communication. And thus also the coordination effort.
Weniger als drei strukturierte Abstimmungen führen selten zu tragfähigen Spezifikationen (Quelle: Adobe Stock –
Why these votes are crucial
Eine zu frühe oder oberflächliche Spezifikation führt regelmäßig zu teuren Nacharbeiten:
- If requirements are too vague, incorrect assumptions are made.
- If design specifications are not compatible with the technical framework, friction losses occur.
- And if expectations are not aligned, frustration, blame, and declining trust are likely to result.
A clear specification, on the other hand, provides the basis for reliable cost estimates, realistic project planning, and efficient implementation.
How to arrive at a viable specification with less friction
Plan the specification phase as a conscious work package—not as a side issue. Give everyone involved the space to contribute their perspectives.
Make sure that requirements are not confused with ready-made solutions. A clear description of the problem is often more helpful than a proposed solution.
Use written documentation not as a bureaucratic tool, but as a means of structuring and communicating. The more transparently the findings are recorded, the better the common orientation.
Iterate in a targeted manner – each round of coordination should yield insights and reduce open questions. And seek external support if necessary: for moderation, structuring, or technical translation between business and IT.
Starting faster ≠ finishing faster
The desire for speed is legitimate – but it must not come at the expense of clarity. Taking the time to draw up a well-founded specification saves time later on. Many project delays can be traced back to unclear, contradictory, or uncoordinated requirements. A good specification is therefore not an end in itself – but a lever for project success.
And no one has ever said, “We should have coordinated less.”
flowciety helps companies to efficiently design this path – with methodological depth, technical experience, and an eye for the relevant questions. So that ideas can become reliable solutions.
Get our Whitepaper on IT Architecture (in German) now—for better planning, stable systems, and sustainable project management.
Source header image: Adobe Stock – alfa27
We are IT partners
Our motto: Establish IT in everyday business as a solution, not as a source of problems.