What Should We Actually Be Recording?

What We Should Be Recording: The Hard Question Nobody Is Asking

There is a question that almost nobody on a construction project ever asks about their documentation practices: why are we doing this? Not “what is this for?” in the broad, liability-aware sense but specifically, when this document is complete, who will use it, for what purpose, and what would go differently if it did not exist? When that question gets asked honestly, the answer for a significant portion of construction’s documentation workload is uncomfortable. Most of it will never be referenced again. Most of the detail nobody will ever extract. And the people producing it are spending time they could use to build the project right instead building a record of how things went wrong.

That is not an argument against documentation. It is an argument for being ruthlessly intentional about which documentation is genuinely necessary and what it takes to produce it in the simplest, most frictionless form possible. The standard of “we’ve always done it this way” is not a justification. It is a habit dressed up as a reason. And there is nothing so useless as doing well what should not be done at all.

The Documentation Landscape Is Full of Waste

Let’s be clear about what Lean thinking says about documentation that processes information without adding value to the installed product. RFIs are waste. Not because design clarifications are not sometimes necessary, they occasionally are but because the RFI exists primarily because the design was not complete enough when it was issued for construction, or because the information management process that should have allowed a simple documented clarification instead requires a formal multi-step approval cycle with wait times, batching, and administrative overhead that have nothing to do with getting the answer to the field. If the design were properly complete and packaged by zone and work package, most RFIs would never need to be written. If the documentation process were frictionless, the ones that remained could be resolved and posted in a fraction of the current time.

Submittals are waste for similar reasons. Submittals exist because the contract documents are not detailed enough and not packaged properly. If the specifications and drawings clearly communicated the installation requirements at the work package level, the submittal process would be dramatically simplified or in many cases unnecessary. Instead, entire administrative operations exist to manage the circulation, review, and approval of documents that are compensating for design gaps that should have been closed in preconstruction.

Monthly narratives, extensive daily reporting beyond the essential record, layers of documentation produced for “later” all of it follows the same logic. The documentation exists not because someone defined what it would be used for and confirmed that use was real, but because the industry has accumulated documentation requirements that nobody has critically examined.

The Scheduling System Story

Here is a specific example of how documentation appetite distorts decisions. A client was being challenged to move to a proper scheduling application, one that would produce a real production plan visible to the trades and oriented toward flow. The response was resistance: “We’re not going to use that because we want to track all the details. We want to document what people are doing down to the minute.”

That desire for minute-level documentation of individual activity is the documentation instinct at its most counterproductive. The purpose of a schedule is to manage production, to show where the project is relative to where it should be, to identify where the constraint is, to confirm that the trades are in the right zones at the right time, and to give the superintendent and PM the information they need to support the field. A schedule that produces that information in a clean, visible, actionable form is serving its purpose. A schedule that is instead designed to record granular detail about past activity, so that something can be blamed later, is serving a legal protection function at the cost of a production management function. And the legal protection function, it turns out, is far less reliable in practice than most teams assume.

Major general contractors have reviewed their daily reporting archives and asked the hard question: when was this information actually used? When was the granular documentation of individual worker activity in a specific zone on a specific afternoon ever extracted and applied in a way that changed an outcome? The honest answer, in case after case, is rarely. Not because documentation is never useful in disputes, it can be, but because the level of detail that gets captured at tremendous daily cost rarely produces the specific information that matters when a dispute actually arises.

What Documentation Is Actually For

None of this means construction should have no documentation. Some things are genuinely necessary, and the minimum for those is not zero, it is exactly what it needs to be. Daily reports should function, at minimum, as a clear record of what was done and not done on a given day, with enough specificity to support a factual account if a claim arises. Notifications and formal notices need to be in writing because legal and contractual requirements demand it. Contracts need to exist because they define the working relationship. Payment records need to be accurate and accessible because trade partners depend on them.

The test for any specific documentation requirement is whether you can articulate exactly what it will be used for and who will use it. If the answer is “we might need it someday” or “legal says to have it,” the follow-up questions are: has legal ever used this specific type of documentation in a case, and what was the outcome? If nobody can answer those questions with specifics, the documentation requirement is probably habit.

Warning Signs That Documentation Waste Is Consuming the Project

Before the administrative burden compounds into a real productivity problem, watch for these signals that the documentation practices are costing more than they protect:

• PEs and PMs are spending significant portions of their day producing reports and narratives that nobody reads and nobody asks about until the end of the month when the schedule says they are due.
• Daily reports are capturing granular activity detail that requires significant daily effort to produce, and nobody on the leadership team can point to a specific instance where that detail was extracted and used.
• Trade partner coordination is being slowed by documentation cycles, RFI wait times, submittal review periods, approval chains that exist for administrative reasons rather than for quality assurance.
• Field engineers and PEs are being consumed by administrative tracking when their time would more directly protect the project by being in the field or coordinating with trades.
• The scheduling approach is oriented toward documenting what happened rather than managing what is happening.

Every one of those signals is documentation serving itself rather than serving the project. The project is paying the cost in the most scarce and non-renewable resource there is: the time of good people who could be doing something that adds real value.

The Better Question to Ask About Everything We Record

Here is the question that should precede every documentation requirement: what decision or protection does this record create that could not be created more efficiently? Not “is this legally required?” that is a separate question with its own answer. Not “has anyone asked for this?” requests accumulate without examination. The question is whether this specific document, produced at this level of detail, in this format, through this process, is the minimum necessary version of the protection or communication it is supposed to provide.

When that question gets asked honestly, several things tend to happen. Some documentation gets confirmed as genuinely necessary and stays. Some documentation gets streamlined, the same information captured in half the time because nobody has ever questioned the format. And some documentation gets removed entirely because the only honest answer to “what is this for?” is “we don’t know.”

The goal is the most frictionless, most Lean version of every documentation requirement that actually needs to exist. AI can already do significant portions of the daily reporting synthesis, meeting minutes consolidation, and narrative generation from structured inputs. The technology is not the barrier. The barrier is the willingness to ask which documentation requirements are real and which are habit.

We are building people who build things. The good people on every project deserve to spend their time on work that matters building cleanly, enabling trades, protecting quality, solving problems before they reach the field. They should not be spending their days producing documents that nobody will read for purposes that nobody can articulate. If your project needs superintendent coaching, project support, or leadership development, Elevate Construction can help your field teams stabilize, schedule, and flow including the documentation discipline that keeps administrative overhead from consuming the time and attention the field actually needs.

A Challenge for Builders

Pick three recurring documentation requirements on your current project this week, three reports, three tracking logs, three recurring deliverables. For each one, ask the question: who uses this, for what specific purpose, and what has happened in the last six months as a direct result of this document existing? If you cannot answer all three parts of the question with specifics, that documentation requirement deserves a harder look. Lean it out. Simplify the format. Reduce the frequency. Or eliminate it entirely. The time you save belongs to the project.

As Jason says, “It’s more important to build the job right than to document whose fault it was when we did it wrong.”

On we go.

Frequently Asked Questions

Are RFIs and submittals actually waste in a Lean construction system?

They are in their current form. RFIs exist primarily because design is incomplete or the information management process is batched and slow. Submittals exist because contract documents are not packaged at the work package level. Both processes could be dramatically streamlined and in a truly advanced production system, largely eliminated through better upstream design and information management.

What should daily reports actually capture at a minimum?

A clear record of what work was done and not done on a given day, with enough factual specificity to support an accurate account if a claim arises. Not granular minute-by-minute activity logs. Not extensive narrative that nobody reads. The minimum record that creates the protection or communication the project actually needs no more.

How do you decide which documentation requirements to keep and which to challenge?

Ask three questions: who uses this, for what specific purpose, and can you point to a recent instance where this document was extracted and made a real difference? Documentation that passes all three questions stays. Documentation that cannot be defended on those terms gets streamlined, reduced, or eliminated. The standard is not “might be useful someday.” It is provable, specific value.