I once was on a project where a non-tech manager had the team spending half of every hour documenting what they just did so that someone with zero understanding of the tech would be able to understand the tech. Personally, I thought this was a huge waste, but there was no way to validate this was or was not waste.
Is there a light-weight means of validating need for documentation before committing to produce the documentation?
Example 1: Say the team is using an off-the-self software without customization. The test might be posting a job description on a monthly basis to access the likelihood that an expert in the software might be found at an acceptable cost level.
Example 2: Automatically pull variables, functions, etc from the code, and two weeks after the code is written, generating questions that automatically assess the developers own knowledge of their own code without access to the code. If the developer is unable to answer the questions, then they must explain the code to another developer, and that developer decides if documentation must be produced.
Example 3: Another way would be to take the likelihood that the code is used based on runtime analysis and cross reference it both with the volatility of input/output and historical likelihood of bugs/error being reported from that section of code and/or customer based requests to update the code.
Honestly, don't believe those are great examples, but are more of an attempt to give the general gist of what I'm after, and that the goal is the most generally useful bare-bones method for doing this.