The Requirements Iceberg: Why Your “Simple” Solution Needs a Detailed Blueprint

September 30, 2025

You’re a busy EHS leader, and you’ve just handled a near-miss incident. The team identifies a corrective action: install a new safety guard. To ensure it works, you want to add a simple effectiveness check to your process: assign the task, start a one-month verification period, and have someone close it out.

Simple, right?

You present this idea, and in return, you get a multi-page specification document. You’re left wondering, “Why can’t they just build what I asked for?”

This isn’t bureaucracy; it’s a necessary translation. You’re experiencing the difference between the visible tip of an iceberg and the massive, unseen part below the water. This is the Requirements Iceberg.

Your request is the tip—the small, visible part. To make it work, I map the submerged mass: the data flows and system logic that the software team needs to build. This hidden structure is what ensures the solution is reliable, works across all your sites, and actually solves the problem you started with.

Here’s what’s hiding beneath the surface.

The User: Who Does What?

The first submerged layer is about translating the human element into system logic. Your request makes perfect sense to a person, but a software system can’t assume anything. That’s why we must begin by explicitly defining who can do what, and why.

Who is “someone”?

The most dangerous assumption would be assigning the verification to the person who completed the original task. This creates a fundamental conflict of interest. An effective check requires an objective, independent party to be credible. Therefore, the system must be configured to prevent an assignee from verifying their own work. This immediately raises the next question: who is the right verifier? A reliable system defines these assignment rules based on factors like organization hierarchy, the risk level of the action, or site-specific EHS roles. It must also be flexible enough to handle transfers or leaves during the monitoring period, ensuring the task always lands with the correct, impartial person.

Who needs to know?

Beyond who does the work, we must define who sees it. Who needs to see the status of this check? Probably the EHS leader, the department head, and maybe a compliance officer. The system needs to ensure the right people have visibility without cluttering the dashboards of those who don’t.

The Workflow: How Does It Actually Work?

A simple request usually describes the “happy path”—the ideal scenario where everything works. A reliable system, however, must be built for the messy reality of the plant floor to ensure it achieves its core purpose: eliminating risk and preventing recurrence.

Your idea of a “one-month monitoring period” seems straightforward, but its implementation is full of branching paths and dependencies.

What’s the official trigger to start the monitoring period?

What officially starts the timer? Is it the moment the corrective action is marked “complete”? What if the completion date is changed? The effectiveness check workflow must be dynamically linked to the status of the parent action.

What essential information does the verifier need to see?

To perform a meaningful effectiveness check, the verifier needs a context. A truly integrated system doesn’t just assign them a task called “Verify Fix”. It provides a direct, clickable link to the entire history: the original incident report, the root cause analysis, and photos. Forcing a verifier to hunt for this information is a classic recipe for a low-quality, “check-the-box” verification.

How long do we really need to monitor this?

A fixed one-month monitoring period doesn’t reflect the reality of EHS work. A simple procedural change, like updating a warning label, might only need a one-week check. However, a fix designed to change operator behavior or verify a control on equipment that only runs periodically might need a 90-day or even a 6-month verification window. The duration must be configurable based on the type of check and the risk profile of the action. If it’s inflexible, your team will be forced to use sticky notes or calendar reminders to manage the real deadline, meaning your system no longer reflects what is actually happening on site.

How will the verifier prove the fix was effective?

This is about proving the original problem is gone, and a simple comment isn’t enough. The system must prompt for specific evidence, and an effective platform helps the user gather it. For instance, to confirm the absence of incident data, the system can automatically display a real-time feed on the verification screen: “System Check: Confirmed zero new near-miss reports linked to ‘Hazard: unguarded machine’ have been logged in the past 30 days.” To link observation data, it can provide a button to “Link Supporting Observations,” instantly attaching formal records. Finally, to capture qualitative feedback, it can connect to your Management of Change (MOC) process and automatically pull in operator sign-offs confirming their training and acceptance of the new control.

What happens if the fix is not effective?

What happens if the problem still exists? The system needs a clear, auditable path. Does a failure trigger a new, more thorough non-conformity, or does the original action simply reopen? (The latter is often the wrong choice.) If this logic is unclear, users will close the action anyway and send an email-hiding the dangerous fact that a serious risk is still present.

What other safety programs need to be updated with the result?

The result of the check must trigger actions in other safety programs, truly closing the loop on the process. If the fix is deemed effective, the system should prompt the user to formally update the central Risk Register, Job Hazard Analysis (JHA), or relevant SOPs to lock in the improvement. Conversely, if the fix fails, the system must flag this as a failed control and trigger a linkage to the MOC process or a new Root Cause Analysis (RCA), ensuring a more rigorous investigation follows.

The Communication: Keeping Everyone Informed

Even the most thorough workflow is useless if people don’t know what they need to do. A silent system is an ineffective one, making notifications the nervous system of your EHS platform.

Who needs to be kept in the loop, and when?

Upon initial assignment, for example, the verifier needs a clear email and in-app notification stating exactly what to do, the context, and the due date. Likewise, when the check is completed, status updates must automatically be sent to the original creator to confirm the loop is closed. But a truly effective communication strategy must also plan for reality, which brings us to our next critical question.

What happens if the verifier forgets?

This is the most common failure in any action-tracking system. Your system must automate accountability, escalating from gentle reminders to manager notifications. This isn’t nagging; it’s about creating a transparent, auditable safety net to ensure a critical verification never falls through the cracks.

The Data: Measure Impact, Not Just Tasks

While notifications create an immediate safety net for individual tasks, the true value merges when we look at the bigger picture. Your new verification step doesn’t exist in a vacuum; it becomes a way for your whole team to learn from what works, unless the information gets stuck in a dead-end folder. Your dashboards shouldn’t just show “open” or “closed” actions; that’s task management, not risk management. The system should answer strategic questions, such as: What is our Verification Success Rate? Which departments or sites are best at developing effective, long-term solutions? Are there recurring failure patterns in our corrective actions? Failure to integrate this data correctly doesn’t just skew a dashboard; you lose the chance to see why some fixes stick and others fail.

The Experience: Making It Usable

Ultimately, the quality of the data we collect and the success of the entire workflow depend on the final submerged layer: the user’s experience. A powerful feature that is confusing or hard to use won’t be adopted. The process of completing the work must be seamless. Where do users go to see their assigned checks? The form for completing the check — the User Interface (UI) — needs to be easy to follow at a glance. The number of clicks it takes to complete the task - the User Experience (UX) - should be minimal. For example, the notification email could contain a direct link that takes the user straight to the task. We aim for the path of least resistance.

Standard Templates vs. Site Reality

You might be using a modern EHS platform that comes with a "best practice" template for effectiveness checks. These tools often handle the basics—blocking self-verification or sending automated reminders—out of the box. But the Requirements Iceberg still exists; it just moves from the "build" phase to the "configuration" phase.

A template is a standardized guess at how you work. Mapping the iceberg is how you perform a gap analysis between that guess and your reality. If your system allows a 30-day monitoring period but your field trial for a new PPE type requires 90 days of shift-level data, the template becomes a cage, not a shortcut. You still need to blueprint your specific hierarchy and evidence requirements before you toggle the "on" switch in your software.

From “Simple” to Successful

When you see the full iceberg, it’s clear that the “simple” request is just the starting point. The detailed specification isn’t about adding unnecessary complexity; it’s about anticipating challenges and building a solution that is thorough, reliable, and grows with your needs. This is the most effective way to remove the ambiguity that leads to project delays and budget overruns. Skipping this step is expensive: I have seen teams spend months re-auditing hundreds of actions because their "simple" system lacked the basic logic to prevent people from checking their own work, making the final data useless for compliance.

This detailed specification is a shared document that ensures we are building the right solution, together. By defining these hidden requirements upfront, we ensure the feature doesn’t just get built—it gets adopted. It works correctly every time, provides the data you need for compliance and improvement, and ultimately makes your workplaces safer.

So, the next time you identify a need for your EHS system, start with the tip of the iceberg, but don’t stop there. Ask yourself: Who, besides the primary user, needs to be involved? What happens if this fails? How will we prove it’s working six months from now? Sketching out these hidden layers will not only clarify your vision. While AI can now help you draft these blueprints in seconds, it cannot replace the practitioner's eye for which edge cases actually happen on your specific plant floor. This rigorous mapping remains the only way to build a solution that lasts.

If you are ready to move from understanding the "why" of the Requirements Iceberg to mastering the "how" of building a resilient EHS system, my book, A Practical Guide to EHS Software Implementation, provides the structured roadmap to make it a reality.