A laboratory test can be executed perfectly and still create a problem for the project.
Why?
Because the test may have been run under the wrong conditions.
Geotechnical laboratory test conditions can be critical. Confining pressure, consolidation stress, loading direction, drainage conditions, stress path, cyclic loading parameters and other requirements can directly affect whether the result is relevant to the engineering question being asked.
The issue is not necessarily whether the laboratory performed the test correctly. A test can be technically executed in accordance with the instruction it received and still produce a result that is unsuitable for the intended engineering application if the wrong conditions were specified.
This distinction matters.
The question is not only:
Was the test performed correctly?
It is also:
Was the correct test instruction approved, communicated and followed?
Yet on many site investigation projects, the process for setting and approving those conditions is surprisingly informal.
A consultant calculates or defines the conditions and sends them by email. The client comments on a PDF. A revised table is attached to another email. Someone in the laboratory receives an earlier version. A discussion takes place during a meeting.
Weeks later, when a result looks unexpected, the project team starts asking:
- Who set these conditions?
- Who approved them?
- Which version was actually used?
- And when did the laboratory receive the final instructions?
Sometimes there is an answer.
Sometimes the answer is buried somewhere in an email chain.
And sometimes there is no reliable record at all.
The problem starts before the test reaches the laboratory
The difficulty is not simply document control.
It is a workflow problem.
Different people are responsible for different parts of the process. The consultant may be expected to draft the test conditions. The client may need to review and approve them. The laboratory needs the final conditions early enough to plan and execute the test.
But unless those responsibilities and actions are visible, each party may be waiting for someone else.
The consultant may not realize that conditions are waiting to be prepared.
Meanwhile, the client may not know that a set of conditions are waiting for approval.
At the same time,The laboratory may know that a test has been assigned but not know when the final conditions will arrive.
The result is a test that sits in a queue without anyone having a clear view of what is actually blocking it.
This becomes especially difficult on large programmes involving hundreds or thousands of samples, several laboratories and multiple test types — or when a laboratory is managing multiple projects, each with several tests requiring project-specific conditions.
At that scale, a missing approval is no longer just an email that has not been answered.
It becomes a project constraint.
Late conditions have real operational consequences
For the laboratory, test conditions are not simply an administrative detail.
They affect planning.
Consider a triaxial or advanced laboratory test requiring equipment to be reserved for several days.
The laboratory may know that the test is coming and keep equipment available for it.
But the approved conditions do not arrive.
The laboratory now has a choice: continue waiting or use that equipment for another test.
If it waits, equipment may remain idle and productive capacity can be lost.
If it reallocates the equipment, the original test may then be delayed once the conditions finally arrive.
The problem becomes more significant when tests involve long durations or specialist equipment. Some geotechnical tests can require substantial laboratory time, meaning that uncertainty around the start condition can affect the sequence of other work.
Multiply this across several tests and several projects, and what initially looked like a minor approval delay becomes a laboratory scheduling problem.
The consequences ultimately reach the project as well:
– delayed results – disrupted testing sequences – inefficient equipment utilization – additional coordination – uncertainty around programme completion
And in some cases, the issue can become technical rather than purely operational.
“I thought that had already been approved”
Another common problem is the difference between discussed, agreed, and formally approved.
Conditions may be discussed during a Teams meeting.
Someone may write, “Looks fine to me” in an email.
A revised spreadsheet may then circulate.
But which of these represents the final instruction to the laboratory?
This distinction becomes particularly important when a test condition changes after technical review.
A revised condition may be perfectly legitimate. The problem is not that conditions change.
The problem is when the project cannot reliably establish:
What changed, who changed it, why it changed, who approved the change, and which version the laboratory actually followed.
When several versions of the same condition table exist, the laboratory technician may have no practical way of knowing whether the file in front of them is the latest approved version.
This can lead to something much more serious than a scheduling delay: a test being performed using superseded conditions.
By the time the issue is discovered, the sample may already have been disturbed or consumed. Equipment time has already been spent. Repeating the test may be expensive, delayed, or in some cases, impossible.
The question then becomes much harder:
Which instruction was actually authorized for execution?
When the result looks wrong, the history suddenly matters
Test-condition traceability often seems unimportant until something goes wrong.
Imagine that a test result is unexpectedly high or low.
The technical discussion begins.
Were the correct stresses applied?
Was the condition based on the correct depth?
Was the latest interpretation of the ground model used?
Did the consultant revise the conditions after receiving additional information?
Did the laboratory receive that revision?
Who approved it?
And most importantly:
Which approved version was actually used to perform the test?
Without a structured record, engineers may spend hours reconstructing decisions from email chains, meeting minutes, marked-up PDFs, and old spreadsheets.
Even then, there may be disagreement about which instruction was final.
This creates unnecessary technical uncertainty around a result that may ultimately influence design decisions.
The laboratory may have followed the instructions it received correctly. Meanwhile, The consultant may have issued a revision correctly. The client may also have approved the revised condition correctly.
But if the project cannot establish the sequence of those events, it becomes difficult to demonstrate exactly what happened.
That is a traceability problem.
Small changes can easily disappear
Not every problem involves completely different conditions.
Sometimes the difference is small.
A confining pressure changes.
The target stress is adjusted.
A test depth is corrected.
In some cases, a loading stage may also be added.
A sample is reassigned after another sample is found unsuitable.
These changes can look minor in an email thread. But they may have a significant effect on the test or on the interpretation of its results.
This is why version control matters even when the change appears insignificant.
The important question is therefore not simply whether the latest condition table exists.
It is whether the project can reliably establish:
What changed, who changed it, why it changed, who approved the change and which version the laboratory actually followed.
A robust workflow should make these questions easy to answer without reconstructing an entire email history.
Test-condition approval should be a workflow, not an email trail
Test-condition approval should be treated as part of the laboratory workflow itself.
The objective is not to eliminate communication or technical review.
It is to make those activities visible, controlled and traceable.
A test can have conditions associated directly with it. The relevant user can prepare those conditions, submit them for review and move them through the required approval process.
The status is visible to the stakeholders who need to see it.
Rather than wondering whether someone has prepared the conditions, the project team can see that they are still outstanding.
The laboratory can also see when the conditions have been finalized instead of waiting for an email.
Instead of searching through old attachments months later, the project can retain the history of changes and approvals against the test itself.
A clear workflow can therefore follow a simple chain:
Test assigned → conditions prepared → conditions reviewed → conditions approved → approved instruction released to laboratory → laboratory proceeds
The process becomes visible rather than assumed.
And when conditions change, the workflow should preserve that change rather than allowing the new instruction to disappear into another email thread.
Better visibility benefits every party
The asset developer or client gains confidence that laboratory testing is being conducted under controlled and approved conditions.
The consultant receives a clear record of the conditions issued and the decisions made during review.
Meanwhile, the site investigation contractor gains visibility of another potential constraint on laboratory progress before it becomes a programme problem.
And for the laboratory, it provides something particularly valuable:
certainty.
The laboratory can see which tests are ready to proceed and which are still waiting for technical input or approval.
That makes it easier to plan equipment, technicians and testing sequences.
The laboratory technician carrying out the test also has access to the approved instruction rather than relying on an attachment forwarded through several people.
The value is not simply that information exists.
It is that the right instruction is connected to the right test, with a visible history of how that instruction reached execution.
The objective is not more administration
A formal approval process can sound like additional bureaucracy.
It should be the opposite.
When the workflow is built into the same platform used to manage samples and tests, approval becomes part of normal project delivery.
There is less need to send reminder emails.
There is less need to ask whether conditions have been approved.
The team faces less ambiguity over which version is final.
Less time spent looking for attachments.
And much less effort reconstructing the decision months later.
Most importantly, everyone works from the same approved instruction.
The objective is not to create another administrative layer.
It is to remove uncertainty from an existing process.
From “who approved this?” to a clear answer
Laboratory testing is too important, too expensive and often too time-sensitive for critical test conditions to live across disconnected email threads and PDF attachments.
A well-controlled workflow should allow the project to answer, immediately:
Who prepared the conditions? Which person reviewed them? Who was responsible for changing them?
Why were they changed? Who approved them? When were they approved? Which version was approved? And what exactly was released to the laboratory?
With LabHarmony, those answers become part of the test record rather than something the team has to reconstruct afterwards.
The result is not simply better document management.
It is a more transparent connection between test assignment, technical conditions, approval and laboratory execution.
Clear conditions, controlled approvals, and full accountability.
If your laboratory programme still manages test conditions through spreadsheets, PDFs and email chains, see how LabHarmony can bring the complete test-condition approval workflow into one shared environment.
Request a free LabHarmony demo.
Frequently Asked Questions About Geotechnical Laboratory Test Conditions
Why can a correctly performed lab test still cause problems for a project?
Because a test can be technically executed exactly as instructed and still be unsuitable for the engineering application if the wrong conditions — confining pressure, consolidation stress, loading direction, drainage conditions, stress path, cyclic loading parameters, etc. — were specified in the first place.
How are test conditions typically set and approved on SI projects today?
Informally — a consultant calculates conditions and sends them by email, the client comments on a PDF, a revised table circulates by email, and discussions happen in meetings, often leaving no reliable record of which version was actually approved and used.
What operational problems arise when approved conditions arrive late?
Laboratories may keep equipment reserved while waiting, risking idle capacity, or reallocate it and delay the original test once conditions do arrive — leading to delayed results, disrupted testing sequences, inefficient equipment use, and uncertainty around programme completion.
What’s the risk when several versions of the same condition table exist?
A laboratory technician may have no way of knowing whether the file in front of them is the latest approved version, which can lead to a test being performed using superseded conditions — and by the time this is discovered, the sample may already be disturbed or consumed.
Why does test-condition traceability matter when a result looks unexpected?
Without a structured record, engineers may spend hours reconstructing decisions from email chains, meeting minutes, and old spreadsheets to determine which approved version was actually used, creating unnecessary technical uncertainty around results that influence design decisions.
What does a well-controlled test-condition approval workflow look like?
A clear chain: test assigned → conditions prepared → conditions reviewed → conditions approved → approved instruction released to laboratory → laboratory proceeds, with status visible to all stakeholders and the full history of changes and approvals retained against the test itself.
How does LabHarmony address this problem?
LabHarmony brings the complete test-condition approval workflow into one shared environment, making preparation, review, and approval visible and traceable, so answers about who approved what, when, and which version was released become part of the test record rather than something reconstructed after the fact.
Who benefits from better visibility into test-condition approvals?
Clients gain confidence that testing is conducted under controlled conditions, consultants get a clear record of issued conditions and review decisions, contractors see potential laboratory constraints before they become programme problems, and laboratories gain certainty about which tests are ready to proceed.
Request a free LabHarmony demo.