How to Check Linked Sub-Tenders Are Ready for Publication

1. Confirm that the linked structure still fits the procurement

Before chasing missing documents, confirm that the chosen structure remains suitable. The iSpec manual states that linked sub-tenders follow the main tender's publication dates and share its currency, additional currencies, evaluation system, RFx settings and approvals. A package needing a genuinely different procurement timetable or evaluation arrangement needs a deliberate structure review, not an assumption that its linked settings can be changed independently.

Do not confuse procurement publication dates with delivery milestones. Packages can have different delivery obligations while participating in a coordinated enquiry. The project team must still check whether the planned delivery sequence is achievable; linking the tenders does not establish that sequence automatically.

2. Separate common information from package-specific obligations

The manual states that adding a vendor to a sub-tender also adds that vendor to the main tender. It therefore advises placing information that applies to all sub-tenders in the main tender and keeping package-specific information within the relevant sub-tender.

Review common instructions, contract information and the overall milestone schedule against that principle. Then check that each package contains its own scope, technical requirements, deliverables and pricing instructions. Avoid contradictory copies of the same requirement in different places.

Supplier access deserves an explicit check. Do not treat the main tender as a private workspace for a package's sensitive material merely because the supplier was originally selected for that package. Confirm the intended access and document arrangement before publication.

3. Test the scope boundaries with adjacent package owners

A package can look complete in isolation while leaving an installation activity, control signal or acceptance test unassigned. Ask the owners on both sides of each important boundary to check the same assumptions, drawings and responsibility records.

For an illustrative brewery upgrade, the packaging-line supplier may define the equipment connection requirements while a separate utilities package supplies services to agreed connection points. Before issue, check who supplies connection data, who makes the final connections, and who demonstrates performance. This is an example of a recommended interface check, not a statement about a particular customer's project.

The same discipline applies to equipment and electrical interfaces in a port, specialist packages in an EPC project, or equipment and enabling-service interfaces in infrastructure. An exclusion is acceptable only when the needed activity has an identified owner elsewhere. Unresolved boundaries require a decision before release, not a hopeful note saying 'by others'.

4. Check that suppliers can understand what to submit

Review the enquiry from the supplier's perspective. Is it clear which information is common, which sub-tenders a supplier may bid for, and which documents and responses are required for its chosen scope? Make package identifiers and document references consistent across the instructions.

The iSpec vendor manual describes selecting the sub-tenders to bid for, completing the main and selected sub-tender submission information, and including the chosen sub-tenders when submitting through the main tender. It also says that a vendor must resubmit its bid whenever it makes changes. Clear instructions should support that documented workflow rather than imply that a changed response is automatically a completed submission.

Check the intended vendor list for each package and the corresponding main-tender membership. The review should confirm access and participation instructions, not disclose one supplier's responses to another or promise that every invited vendor must bid for every package.

5. Distinguish completed documents from completed decisions

The iSpec sub-tender manual describes To-Do widgets listing outstanding preparation items and requires the main tender and sub-tenders to be complete, with approvals completed, before publication. Use those controls as part of the release review, but do not mistake an application status for proof that every technical or commercial assumption is sound.

A practical check should establish who accepted the scope, interfaces, commercial instructions and shared settings. Record unresolved issues with an owner and a release decision. Where an unresolved requirement would prevent comparable responses, address it before proceeding rather than relying on later clarifications to repair the enquiry.

6. Hold one release review across the linked enquiry

Bring the main-tender owner and package owners together for a short, evidence-based go/no-go review. Check the complete set of linked packages rather than accepting separate assurances that were made against different document versions.

Use a simple release record containing the main-tender identifier, included sub-tenders, document revisions, planned publication date, approval status, unresolved exceptions and the accountable release decision. This is a suggested governance record; the manual does not establish a dedicated automatic cross-package readiness report.

If a package is not ready, decide what happens to the coordinated enquiry. Any decision to revise the package grouping or use a separate tender should be checked against the documented workflow and the organisation's procurement controls. Do not assume an in-progress change to the linked structure is available or harmless.

7. Distinguish publication from the enquiry actually opening

The publication manual explains that a tender can have a published status while awaiting its selected publication date, during which vendors cannot yet access it. Approving or preparing publication early does not by itself mean the enquiry is open to suppliers.

After the publication action, check the intended date, status and supplier-access arrangements before telling stakeholders that the enquiry is live. This closes the gap between an internal release decision and the point at which vendors can actually work on their responses.

8. Preserve the release basis when questions arrive

Supplier questions often reveal assumptions that were not visible during preparation. Keep the approved release basis available so the team can distinguish an explanation of the existing requirement from a change affecting other packages.

The iSpec correspondence manual documents messages associated with document headings and retained message history, subject to permissions and the relevant vendor-document context. Use that context to keep questions connected to the requirement being discussed. A message in one package is not evidence that every affected package or supplier has received the same information.

The responsible team should assess cross-package effects and distribute any authorised clarification or change to the appropriate recipients under its procurement rules. Linked sub-tenders help organise the enquiry; people still need to decide what a change affects and whether the release basis remains consistent.