Shane Ian Murphy: the water requirement that needs a time period

A water requirement expressed as one large number can seem clear until someone asks when the water is needed. An average daily figure, a peak operating requirement and a short commissioning need answer different questions. A project brief becomes more useful when the time basis is part of the description rather than an assumption left to the reader.

This company-origin editorial features Shane Ian Murphy, co-founder and partner of RougeN International Corp. It uses a hypothetical project exercise to discuss preparation and service requirements. It is not a technical design, a completed project report or an announcement of a mandate or funding commitment. Actual requirements must be assessed by the relevant specialists.

Describe the intended service

Imagine a proposed facility whose introduction states a daily water amount. Before discussing equipment, a reviewer asks what activities the figure covers. Does it relate to routine operation, a particular process or another defined use? The explanation should connect the number to the service the project is intended to deliver.

That question can reveal several different needs within a broad total. The preparation team does not need to resolve the technical design in its opening summary. It needs to identify the scope clearly enough for the appropriate assessment to begin, including which parts remain estimates and which have supporting information.

Make the period recognisable

An average can be useful for one purpose while being insufficient for another. A service that varies through the day needs an explanation of that variation. The relevant technical team can then assess the implications using the appropriate information rather than infer a pattern from a single total.

A hypothetical operating narrative can support the discussion. It follows the sequence of activities and identifies when each relevant demand arises. The narrative should be treated as an input for review, not as proof that the proposed arrangement can meet the requirement. Its value is in making assumptions visible.

Connect the source and destination

A water proposal should explain the intended route from source to use at the level appropriate to the brief. Availability at one point does not automatically answer questions about delivery to another. Responsibilities along the route need to be identified so the project team can recognise which participant is expected to provide which information.

The same principle applies to the intended users. Different uses may require different assessments or conditions. An introductory document should not collapse them into a single reassuring description simply because they share the word water. Clear scope helps the specialists identify the work that remains.

Include the operating responsibility

A service requirement is connected to people and processes. Someone will operate the system, respond to interruptions and maintain the relevant records. The project brief should identify the proposed responsibility and the assumptions on which that operating model depends.

If an outside service is being considered, its role should remain conditional until the appropriate arrangement exists. A preparation summary should not turn a possible provider into a confirmed participant. Keeping that distinction visible helps later readers understand the actual stage of the project.

Record uncertain inputs

An early project may contain incomplete information. The useful response is to identify the missing input, explain why it matters and assign the next action. A polished presentation that leaves uncertainty unmentioned does not make the underlying assessment more complete.

For a hypothetical water brief, an unresolved input might concern the operating pattern or a source assumption. The team can record the question without inventing an answer. When new information arrives, it can explain what changed and identify which part of the proposed requirement needs to be reviewed again.

Carry the basis into the next stage

The next team should receive the meaning behind the figure, not just the number itself. A clear handover preserves the intended service, measurement period, assumptions and unresolved questions. That gives the recipient an understandable starting point for its own assessment and avoids repeating the original information-gathering exercise unnecessarily.

RougeN's project-preparation perspective in this article is that a service requirement should be readable before it becomes a headline in a presentation. Shane Ian Murphy's company role provides the context for the discussion. More professional background is available at https://shanemurphy.co.uk/.

A time period may look like a small addition to a number, yet it can change the question the reader believes they are answering. Stating it clearly helps the project conversation remain connected to the intended operating reality rather than an attractive but incomplete summary.

Illustration: supplied promotional portrait of Shane Ian Murphy; not evidence of a water-project site visit.