Overworked healthcare professionals, including doctors, spend enormous
amounts of time monthly to plan complex rosters, taking precious time away
from their core duties. This one-month long process is tedious and time
consuming for three reasons:
Roster planning is mostly done manually using Excel, taking at least 5
hours monthly to finally generate the roster.
In addition to creating the roster, roster planners gather leave and shift
requests from colleagues through various means such as emails, texts, or
verbal communication. These requests are manually compiled as constraints
in Excel during roster generation. Any last-minute amendments or requests
necessitate a manual regeneration of the roster, which can extend the time
required beyond the initial 5 hours.
Roster planners typically spend a minimum of 2 days adjusting system-generated
rosters due to existing system constraints, despite the availability of
Interviews with TTSH and SGH users of such commercial solutions like
Workforce Optimizer (WFO)
, revealed dissatisfaction with the system-generated rosters due to existing
system constraints (e.g. inability to change existing constraints, weightage
of existing constraints, accommodate colleagues’ requests). Majority of
the roster planners were not the contract owner. Deviation from the contractual
agreed constraints often require time-consuming change requests and budget
approvals, leading to delays of up to several months.
Roster planning demands mental agility as planners balance numerous constraints
to ensure fair shift allocation.
They must accommodate individual preferences while meeting mandatory shift
requirements, such as avoiding intense duties or weekend work. This entails
not only creating new rosters but also monitoring past shift allocations
to maintain fairness. Doing roster manually aggravates the complexity of
rostering in general.
Rostering is an essential task within the public sector.
Currently, we are starting off with the healthcare sector, targeting doctors
first. Doctors alone have wasted over 1,000* hours at least across all
public acute hospitals in Singapore. This excluded time spent by other
healthcare professionals such as nurses, medical social workers, pharmacists
and other allied healthcare partners. If we sum it all up, the healthcare
sector could have wasted over 4000 hours on manual rostering instead of
their core work – patient care.
* This calculation assumes an average of 53 departments based on 10 public acute hospitals as of 2022 (excluding nursing and allied health services) and 2 doctor rosters per department because there is usually more than 1 type of roster to be planned monthly.
Apart from the healthcare sector, there is also possibility to explore
the extent of the rostering issue in the following sectors:
Hospitals, clinics, and emergency medical services require rostering to
ensure round-the-clock coverage of medical staff.
Police, fire departments, and paramedics need rostering to maintain 24/7
emergency response capabilities.
Public transportation systems, including buses, trains, and subways, require
rostering to schedule drivers and operators for shifts.
Schools, colleges, and universities use rostering to schedule teachers,
professors, and other staff members.
Armed forces use rostering to schedule deployments, training exercises,
and operational duties.
Essential services like water treatment plants, power stations, and waste
management facilities rely on rostering to ensure continuous operation.
Roster Monster (RoMo) is a self-serve platform that allows roster planners
to generate their rosters automatically whenever needed, and set constraints
flexibly to meet their needs. We have validated the concept with users
through interviews with 10 doctors across 4 hospitals, and overall received
In our very first release of the Minimum Viable Product (MVP), we want
to address the key pain points highlighted by public acute hospital doctors
on rostering. This includes having to:
(For those using Excel) Manually re-generating rosters to accommodate
new requests or rules
(For those who are using commercial solutions apart from Excel) Inability
to change existing rules
Single view of all the blocked out dates and shift requests from all staff
Automatic roster generation
See all staff’s blocked out dates for scheduling and preferred shift slots
all in one view, during the entire roster period
Group staff members into any number of arbitrary groups that can then
be used during rule creation to make the rule target only specific staff
To access the prototype, click here.
As of 20 Feb 2024, we have received 70 sign-ups from interested partners
from H4PG and two email blasts.
81% of the sign-ups were in the healthcare sector from both public and
private acute hospitals e.g. Singapore General Hospital (SGH), Tan Tock
Seng Hospital (TTSH), and Nobel Medical Group while the remaining 19% were
from other sectors such as CPF Board, ICA Singapore and People Association
(PA) through organic sharing.
In particular, TTSH nursing and Sport Singapore have both reached out
to us beyond H4PG and expressed interest to discuss potential pilots within
their departments. An existing contact in the SGH Emergency Department
(ED) is also willing to run a pilot with us with minimal feature improvements.
The team has just sent out the MVP to all interested parties and is in
the process of scheduling user testing sessions with them.
During H4PG, our team comprised of four members:
[Sufyan] 1 Designer: Sufyan was the team’s anchor for
user research and design. The problems that Roster Monster are looking
to solve are deeply rooted in current work process and user behaviour.
Sufyan drove user interviews by diving deep and picking apart how rostering
works. He then translated that into an intuitive product for average roster
planners. Good design is particularly important in building an intuitive
rule-creation experience and bridging the gap between user and constraint
[Latasha & EnYi] 2 Engineers: Latasha was the engineer
in charge of the webapp. Her work included setting up the project infrastructure,
designing the database schema, as well as writing the core frontend components.
EnYi built out the constraint solver, translating commonly requested rules
into coded constraints. He designed the API contract between the webapp
and the solver by identifying opportunities to group constraints into categories.
Both engineers worked closely with Sufyan to design the rule-generation
[Limin - SNG] 1 ProdManagement/ProdOps: During H4PG, Limin
took on both product management and product operations roles. She was the
team’s main point of contact with external parties, and helped to secure
user interviews with doctors through her outreach efforts. She conducted
problem sizing exercises and identified opportunities for RoMo to tackle,
working closely with Sufyan to prioritise features for the prototype. She
also developed the main RoMo pitch for demo day, which the rest of the
team helped to execute.