SS ISO 19650:2-2024: A Singapore Information Management Checklist
SS ISO 19650:2-2024 gives Singapore project teams a delivery-phase framework for managing information with BIM. Buying a common data environment or adopting a file name does not create conformance. The project still needs defined requirements, responsibilities, states, reviews and acceptance.
Use this checklist to find the gaps before mobilisation.
What should an SS ISO 19650:2-2024 project checklist cover?
Cover information requirements, appointment responsibilities, delivery plans, common data environment states, container identification, review and approval, model coordination, issue management, security, information exchange and final handover. Record the project's agreed convention rather than assuming software defaults are the standard.
Singapore's Building and Construction Authority describes SS ISO 19650:2-2024 as the standard for managing information with BIM during the delivery phase of built assets. BCA also provides a file naming converter, model content requirements and site data resources.
The standard itself must be consulted for formal requirements. This article is an operational review list, not a substitute.
Singapore information management checklist from requirements and appointments through CDE review and handover.
Requirements and appointments
| Check | Evidence | Owner |
|---|---|---|
| Information purpose is stated | Exchange information requirements | Appointing party |
| Deliverables are defined | Information schedule and acceptance criteria | Appointing party and lead appointed party |
| Responsibilities are assigned | Responsibility matrix and appointments | Project leadership |
| Capability is assessed | Method, capacity and resource response | Each appointed party |
| Delivery is planned | Master and task information delivery plans | Lead and task teams |
Do not use “BIM model” as a deliverable description. State the information, level, format, purpose, date and acceptance rule.
Configure the CDE around states
The common data environment should make information state visible. A project may configure terms and permissions to suit its process, but users must be able to distinguish work in progress, shared information, published or authorised information and archive records.
Check:
- status and suitability codes are defined;
- transitions require the correct review;
- revisions remain traceable;
- permissions match responsibilities;
- rejected information returns with a reason;
- notifications reach the right team; and
- archive behaviour cannot be confused with deletion.
The software should support the process. The project should not rewrite governance around a convenient button.
Define container identification
BCA's page includes an SS ISO 19650:2-2024 file naming converter. Use it as an implementation aid after the project naming convention is agreed.
A good naming protocol defines each field, permitted values, examples, ownership and what happens when a field is not applicable. Test it against models, drawings, reports, schedules and site records. Do not rely on users to remember free-text abbreviations.
Make review and acceptance distinct
Coordination review, technical review, information standard check and contractual acceptance are not the same decision. State which role performs each one and what evidence is recorded.
A practical gate asks:
- Is the container complete for its stated purpose?
- Does it meet naming and metadata rules?
- Has discipline review occurred?
- Have coordination issues been resolved or accepted?
- Does it meet exchange format and content requirements?
- Is the correct person authorising release?
Connect issues to information
An issue should carry a location, related container or element, owner, due date, status and closure evidence. Screenshots without identifiers become difficult to reconcile after a model changes.
Agree whether the CDE, coordination tool or another system is the source of truth for issues. If tools are integrated, test what happens when a record is edited or closed in either system.
Plan handover early
Final handover is not a bulk download of everything ever shared. Define the required asset information, formats, identifiers, validation and archive before design teams create data.
Use BCA's model content and site data resources to inform the project-specific requirement. Confirm with the asset owner which information will actually be maintained after completion.
Monthly assurance check
- Delivery plans match the current programme.
- Naming and metadata errors are trending down.
- Reviews occur within agreed time.
- Shared information has a clear suitability.
- Overdue issues have an owner.
- Permissions reflect current appointments.
- Required exchange formats open and validate.
- Handover fields are being populated.
- Departed users are removed.
- Exceptions are recorded, not hidden.
Our guide to BIM handover content covers the owner-facing evidence. The construction sector page shows how digital delivery capability can be explained publicly.
Creatif Work structures construction content and tools around real information states and responsibilities. If the CDE stores files but the team still asks which one is approved, start with the problem.
Test one exchange end to end
Select a planned information exchange and follow it from requirement to acceptance. Confirm the required containers, metadata, formats, review roles, issue closure and receiving system. Use real sample information rather than an empty template.
Record how long each step takes and where users leave the agreed workflow. An email approval or locally renamed file is a process signal, even when the final exchange succeeds. Decide whether the CDE configuration, training or requirement needs correction.
Then test the receiving side. Can the appointing party open, validate and use the information for its stated purpose? A technically valid file may still fail because identifiers, coordinates, classifications or asset fields do not match the requirement.
Keep the test evidence with the delivery plan and repeat it before major stage exchanges. Update onboarding examples when the convention changes. This gives new contributors a working reference and prevents each task team from learning the process through rejection. The strongest assurance is a completed exchange with a visible decision trail, not a declaration that the project follows the standard.