How to review 100 comments on a spec without endless meetings

The Problem

Imagine this scenario. A client has contracted for the development of a new IT system. The implementer, as part of their obligation, creates a functional specification and submits it to the client for review. The client forms a Team of about ten people for this purpose, tasked with verifying that the document correctly and completely covers what was agreed upon. Each Team member submits their comments, the implementer responds to them, and after several weeks, the document sits on the table with dozens, perhaps over a hundred comments and replies.

All of this needs to be closed by a fixed contractual deadline, which does not move just because the review took longer than planned. On large implementations, one poorly managed meeting easily consumes dozens of hours of work from the people with the highest salaries on the project, and every week lost to disorganized debate often means project delays or an additional contract annex.

And then the Team schedules a meeting to “go through” it all. The first comment is a minor terminological ambiguity, resolved in two minutes. The second is a substantive issue that changes the architecture of the entire system, and it is debated for forty minutes because no one came prepared specifically for it. The third is something the implementer says is not part of the contract, but no one on site has the tender document to verify if that is true. An hour passes, fifteen out of a hundred comments have been processed, and the most important issues, those that truly carry risk, remain unaddressed.

The problem is not the number of comments. The problem is that every comment is treated the same way, as if they all carry the same type of decision and the same level of risk. There is a simple framework that solves this problem: comments are sorted into three columns, according to the type of decision they require, before anyone sits down at the table.

Who Writes the Specification and Who Reviews It

Creating the functional specification is primarily the implementer’s responsibility, but with the mandatory active participation of the client. In the IT industry, this division of responsibilities typically looks like this:

• Implementer (leads the process). Responsible for technical shaping, writing, and structuring the document. They translate the client’s business wishes into detailed functional requirements, thus defining how the system will work.
• Client (provides input data). Responsible for requirements analysis and defining business objectives, i.e., what the system must achieve. The client must provide access to key users and business analysts so the implementer can obtain accurate information.

The Team does not write the document, but their job is not passive waiting for a finished product either. The Team is the mechanism through which the client actively verifies whether the implementer has correctly translated their business requirements into technical language. This is a standard part of requirements management on every major IT implementation, especially in public procurement of IT systems, where every decision is additionally under formal and time pressure.

The Solution: Three Columns

Instead of processing comments in the order they arrived, sort them in advance, before the meeting, into three categories:

Accepted. The implementer has formally accepted the comment and incorporated the change into the document. The task here is not debate, but verification. Does the text that was actually added cover what was requested, or does it only sound like it covers it? This is the fastest column when acceptance is genuine, but also the place where formally accepted but substantively empty changes can most easily slip through.

Clarification needed. Neither side has a sufficiently clear picture to make a decision. This column works in both directions: sometimes the client’s comment is unclear and needs to be rephrased, and sometimes the implementer’s response is unclear and needs additional explanation or proof.

Rejected or not applicable. The implementer claims that something is not part of the obligation. This is not debated verbally; instead, it is checked against the original document. If a basis exists, the item is returned to the implementer with a specific citation as a formal change request if it alters the scope. If there is no basis, the item exits the process, does not remain “open,” and does not go further into the workshop.

In practice, it looks like this:

       100 comments
             │
             ▼
   ┌───────────────────┐
   │   Sorting          │
   └───────────────────┘
       │        │        │
       ▼        ▼        ▼
   Accepted  Clarification  Rejected
   (verify)   (deadline+person) (verify contract)

To illustrate the difference with numbers (illustrative example, not data from an actual project): on an implementation of this scale, 127 comments could be sorted roughly like this: 74 immediately accepted with a brief check of the wording, 31 requiring clarification with a clearly assigned person and deadline, and 22 requiring contract verification before being closed. Instead of four multi-hour meetings with no clear outcome, the work could realistically be completed in one morning.

One rule that has proven key: the document that defines WHAT is being built and the meeting that resolves HOW it is implemented must not be mixed. Only items for which the scope has already been confirmed should enter the workshop. If a question about whether something is even within the contract scope is introduced into the workshop, the workshop ceases to be a place for “how” and becomes a place where scope is informally shifted, without a written trail, outside the formal scope management that should accompany every such change.

Why This Happens in This Particular Form

The entire situation described above is characteristic of the Waterfall way of working, where one comprehensive document is locked before development begins. In an Agile/Scrum environment, the classic functional specification as a single file does not exist; instead, it is broken down into a dynamic Product Backlog that is built throughout development.

The difference is not merely formal. The Waterfall FSD is locked once, and every subsequent change becomes a formal change request. The Agile Product Backlog is consciously built as a living document. That is why the scenario of a hundred comments on a single locked document emerges as a problem at all: the entire burden of precision must be resolved in advance, before the first line of code. The three columns are a way to process that one-time burden reasonably, whenever your contract obliges you to a waterfall approach.

The Connection to Scrum

This problem is not specific to public procurement or IT contracts. It is the same problem the Product Owner solves every week. When stakeholders flood the backlog with ideas and comments, a bad Product Owner processes them in the order they arrive. A good Product Owner triages: some items are ready, that is, refinement in the sense of checking whether what is written matches what was intended. Some require clarification before they can even enter the prioritization discussion; that is the essence of the Definition of Ready. Some do not belong to the product at all, and they should be honestly rejected instead of rotting at the bottom of the backlog.

The boundary between the specification (WHAT) and the workshop (HOW) corresponds to the boundary between a Product Backlog item and the Sprint Backlog. The Product Owner decides what enters the scope, and the team decides how to implement it within the sprint. When these two decisions are mixed, you get the same chaos as when a technical workshop suddenly opens a scope question.

Instead of a Conclusion

People often think that large projects fail because of bad software. Much more often, they fail because important decisions get lost among unimportant comments. The three columns are not just a way to organize comments. They are a way to organize attention.