Digital Lock On

Appearance

Decision: Project and Worksite Activation ​

Quick Summary ​

Should we allow and/or enforce assignment of RPOs to projects and Site Protectors to worksites at creation time, or allow flexible activation by any qualified person?

Context ​

Currently, projects and worksites are created in the admin portal with optional assignments (rpoId and protectorId can be null). This allows flexibility but may create coordination issues and responsibility confusion.

Current State:

  • Projects can be created without an assigned RPO (rpoId: null)
  • Projects can be created with an assigned RPO
    • Currently, if this is done, there is a "bug" which disallows activation of the project (naively checks for an assigned RPO as the proxy for the project being activated)
  • Worksites are created without an assigned Site Protector (protectorId: null)
  • Site Protector cannot be assigned at project creation
  • Any RPO can activate any unassigned project (system sets rpoId to activating user)
  • Any Site Protector can activate any unassigned worksite
  • If wrong person activates, only recourse is deactivate/reactivate by correct person

Business Context:

  • Assignments often known at creation time, but last-minute changes are common (sick leave, staffing changes)
  • Admin portal users (admins) don't always know final assignments at creation time
  • Project managers and head of protection determine protector rosters
  • No regulatory safety requirements for specific assignment accountability
  • Current TS90 paper process allows any qualified protector to start worksites

Decision Required ​

How should we handle project and worksite assignments to balance operational flexibility with responsibility clarity and coordination?

Success Criteria ​

What does a good decision look like?

  • [ ] Minimises administrative friction during project/worksite creation
  • [ ] Reduces coordination issues and responsibility confusion
  • [ ] Maintains operational flexibility for last-minute staffing changes
  • [ ] Provides clear audit trail of who is responsible for what
  • [ ] Aligns with current business processes and safety practices

Options ​

Option 1: Enforce Assignment at Creation Time ​

Description: Require RPOs to be assigned to projects and Site Protectors to be assigned to worksites at creation time in the admin portal. Only the assigned person can activate their project/worksite.

Analysis

Pros:

  • Clear responsibility and accountability from the start
  • Eliminates wrong-person activation scenarios
  • Provides complete audit trail of planned vs actual assignments
  • Aligns with traditional project management practices
  • Reduces coordination confusion

Cons:

  • Creates significant administrative friction when assignments unknown at creation
  • Requires process changes in admin portal (assignments become mandatory)
  • Inflexible for last-minute staffing changes (requires admin portal updates)
  • May block project/worksite creation when qualified people available but not assigned
  • Doesn't match current flexible TS90 paper process

Risks:

  • Projects delayed due to assignment bureaucracy - Mitigation: Allow assignment updates in admin portal
  • Emergency situations blocked by assignment constraints - Mitigation: Emergency override mechanism
  • Increased admin workload for assignment management - Mitigation: Streamlined assignment update process

Implementation Effort: 2-3 weeks (admin portal changes, validation logic, assignment UI) Maintenance Overhead: Medium (ongoing assignment management processes)

Option 2a: Disallow Assignment at Creation Time ​

Description: Do not allow assignment at creation time, and any qualified RPO/Site Protectort can activate.

Analysis

Pros:

  • Flexibly allows for activation
  • Closest to "anyone can create a TS90" state

Cons:

  • Doesn't allow for admin control on assignment

Risks:

  • Incorrect RPO or Site Protector may activate Project/Worksite

Implementation Effort: Minimal (simple form validation in admin site) Maintenance Overhead: Low (no additional processes needed)

Option 2b: Flexible Unassigned Activation ​

Description: Projects/worksites can be created without assignments, and any qualified RPO/Site Protector can activate them. System records who actually activated for audit purposes. If RPO is assigned at creation, then only that RPO can activate.

Analysis

Pros:

  • Maximum operational flexibility for staffing changes
  • No administrative friction at creation time
  • Matches current TS90 paper process workflow
  • Handles emergency and last-minute scenarios gracefully
  • Simple to understand and implement
  • No process changes required for existing workflows

Cons:

  • Potential for wrong-person activation (though easily corrected)
  • Less clear accountability until activation occurs
  • Coordination requires external communication
  • May cause brief confusion about who's responsible for what

Risks:

  • Wrong person activates critical project - Mitigation: Deactivate/reactivate process already exists
  • Coordination issues between teams - Mitigation: Existing communication processes

Implementation Effort: 0 hours (already implemented) Maintenance Overhead: Low (no additional processes needed)

Option 3: Hybrid - Flexible Projects, Assigned Worksites ​

Description: Projects remain unassigned (any RPO can activate), but worksites must have assigned Site Protectors who are the only ones allowed to activate. RPOs gain capability to assign protectors to worksites.

Analysis

Pros:

  • Balances flexibility at project level with accountability at worksite level
  • RPOs can make assignment decisions closer to activation time
  • Reduces admin portal assignment burden (only projects need initial creation)
  • Site-level protection has clear responsibility

Cons:

  • Creates inconsistent assignment model (confusing UX)
  • RPOs may lack visibility into available Site Protectors for assignment decisions
  • Adds complexity to activation workflow
  • Requires new UI for RPO assignment capabilities
  • Still creates bottleneck if assigned protector unavailable

Risks:

  • RPO makes poor assignment decisions due to limited protector visibility - Mitigation: Provide protector availability information to RPOs
  • Complex activation workflows confuse users - Mitigation: Clear UI design and training
  • Assignment bottleneck at RPO level - Mitigation: Allow reassignment capabilities

Implementation Effort: 3-4 weeks (new assignment UI for RPOs, worksite assignment validation, permission updates) Maintenance Overhead: Medium-High (dual assignment models, more complex workflows)

Constraints & Requirements ​

Must Have ​

  • Support for last-minute staffing changes (people unavailable, reassignments)
  • Minimal disruption to current admin portal creation workflows
  • Clear audit trail of who activated what and when
  • Compatibility with existing deactivate/reactivate corrective process

Should Have ​

  • Reduction in coordination confusion and responsibility ambiguity
  • Alignment with current TS90 paper-based flexibility
  • Low implementation and maintenance overhead
  • Intuitive user experience that doesn't confuse operators

Must Not ​

  • Block project/worksite creation due to assignment bureaucracy
  • Create emergency response bottlenecks
  • Require significant retraining of current users
  • Introduce safety risks or regulatory compliance issues

Research & Evidence ​

Completed Research ​

  • [x] Current system analysis - Result: Projects/worksites support optional assignments, any qualified person can activate
  • [x] Business workflow investigation - Result: Last-minute changes common, assignments often unknown at creation
  • [x] Safety/regulatory requirements - Result: No specific regulatory requirements for assignment accountability
  • [x] Current corrective process - Result: Deactivate/reactivate process exists for wrong-person scenarios

Outstanding Research ​

  • [ ] Quantify frequency of wrong-person activation incidents
  • [ ] Survey admin portal users about assignment friction
  • [ ] Analyse audit requirements for assignment tracking

Evidence & Data ​

Stakeholders & RACI ​

RolePerson/TeamResponsibleAccountableConsultedInformed
Decision MakerProduct Owner✅
Technical LeadDevelopment Team✅
Admin Portal UsersAdmin Staff✅
End UsersRPOs & Site Protectors✅
Project ManagersPM & Head of Protection✅
Implementation TeamDevelopment Team✅

Impact Assessment ​

Blocked Items ​

  • No current requirements blocked by this decision
  • Future assignment-related requirements depend on this decision

Affected Components ​

  • Admin Portal - Impact: May require UI changes for mandatory assignments (Option 1) or RPO assignment capabilities (Option 3)
  • API Layer - Impact: Validation logic changes for assignment enforcement (Options 1 & 3)
  • Digital Lock On Platform - Impact: Minimal, current activation logic already handles assignments
  • Database Schema - Impact: No changes needed, nullable fields already support all options

Timeline Impact ​

  • If decided by deadline: Can proceed with current flexible approach or plan implementation for chosen option
  • If delayed by 1 week: Minimal impact, not blocking current development
  • If delayed by 1 month: May need to revisit if assignment issues become problematic

Decision Log ​

DateUpdateAuthor
2025-09-05Decision createdSimon
2025-09-05Options analysis completedSimon + Claude
2025-09-09Added details about bug preventing assigned RPO from activating the project and added option to disallow assignment at time of creationSimon

Next Actions ​

Immediate (Next 3 Days) ​

  • [ ] Review analysis with Product Owner
  • [ ] Validate assumptions with admin portal users

Short Term (Next 2 Weeks) ​

  • [ ] Consult with RPOs and Site Protectors on preferred approach
  • [ ] Gather data on wrong-person activation frequency
  • [ ] Make final decision

Decision Meeting ​

  • Scheduled: [To be scheduled]
  • Attendees: Product Owner, Technical Lead, Admin Staff Representative, RPO/Site Protector Representatives
  • Agenda: Review options, discuss business impact, make decision

Requirements ​

Specifications ​

  • No directly related pending decisions

Decision Outcome ​

To be filled when decision is made

Final Decision: [Decision made]
Rationale: [Why this decision was made]
Decision Date: [Date]

Internal use only