| | |
|---|
Employees with non BC Gov emails joining the program | There are emails that do not have @gov.bc.ca emails that are wanting to join the program (i.e., Auditor General). These non-bc gov emails typically means they do not have an IDIR. IDIR is an important aspect of being a member as it provides access to BC Gov systems. For example, some of the volunteers in logistics in EMCR need to use WebEOC and the CORE Team application, both IDIR activated. Similarly, some of the volunteers in BCWS need to use their own systems like Resource Manager, also IDIR activated. What do we do in situations where a CORE Team member used to be from a ministry, then they moved to Auditor General, does it mean that they are no longer a member? Simultaneously, there is an overarching vision from senior leaders to have every public servant join the program. | The program/policy will need to be clarified first before any tech solution can be delivered. What we need to figure out: Program/Policy: Are we allowing folks that do not have BC Gov emails/IDIR to volunteer? Program/Policy: Are there different compensation models that exist for non-bc gov employees that we need to investigate? Program/Policy: Are there different work safety policies that apply for non-bc gov employees that we need to consider? Tech: Are all non-bc gov emails cannot use our systems? Is there a way to request IDIRs for these folks (PSA + OCIO?)?
|
Phase 1 of the User Journey: Awareness | During our research with potential members and current members, there is a need to expand our content to entice public servants to volunteer and to provide clarity on what is expected throughout the different phases of the journey as a volunteer. | Content revamped: For potential members: Create videos of CORE volunteers that are not necessarily from BCWS or MCR. We heard from potential members that they would like to hear from someone who is from a “non-emergency” response ministry that they can relate to. For example, hearing from a member from the Ministry of Finance who is a Financial Analyst who is volunteering as a Planning Officer. Providing more info on what’s in it for them to become a member: what do they gain as a volunteer for the program. Potential members have indicated having clear “job descriptions” for each of the roles can guide them on which roles they would want to volunteer for. Hold AMA sessions with seasoned volunteer vs. new to share experiences and learn about what happens during deployments.
For people leaders: Provide more information on what’s in it for supervisors to approve their staff to be part of the program and for deployment. What is the benefit of them approving? Make the compensation process clearer for them; so they understand how their employees are being paid and who is paying for which portion (i.e. OT).
|
Phase 2 of the User Journey: Intake | Pending Applications: There are still manual processes involved when Coordinators approve pending applicants in the system. For example, members still have to send emails for their supervisor approval to the Coordinators and other required materials (i.e. ParQ in BCWS). Additionally, not having a solid set of requirements + transparency for when a pending applicant becomes an active member creates confusion. We want to make our intake process user friendly as much as possible so we can attract new members to join. | Solidifying program requirements: The criteria and prerequisites to become a CORE Team member is clearer. For example, identifying all the trainings that need to be completed before a pending applicant can be a member. Also, being more transparent around behind the scenes processes such as conducting reference checks (EMCR only). We found in our research that potential members did not appreciate this and felt like applying for a job rather than volunteering. We also learned from the Coordinators that there are other ways of figuring out for “fit” than doing reference checks. Having too many criteria before one can become a member may create barriers for people to join. It doesn’t fit the vision and messaging of senior executives to public servants that everybody can join the program. Making those prerequisites visible so that (i.e., intranet), a potential member can decide whether they want to volunteer or not.
Once we have more clarity on the program side for the prerequisites to become a member we can focus more on streamlining the intake process: All the required trainings to become a new member is integrated into the application that we can then use as a confirmation for pending applicants in the system for completed trainings. Additionally, if any of these trainings can be made available in the PSA’s Learning Management, we can make that easily accessible with our integration with their training data. The supervisor approval to become a new member is automated.
|
Phase 3 of the User Journey: Onboarding & Training | New Members: A pending applicant becomes a new member, there are some meetings held to welcome them, provide info on the program, etc. However, we’ve heard from members that they don’t hear anything back about future trainings and/or deployment opportunities. We heard from Coordinators that there are certainly roles that would be a good fit for new members and that training and/or job shadowing need to be delivered to help with onboarding. Current Active Members: We heard from active members, some have been volunteers for more than 5 years that they want and need more training to build their skills set whether in a particular role to gain more “seniority” or trying different roles. They also need more clarity on how to move from a “beginner” volunteer to a more “advanced” position. Coordinators also felt that there are currently no set guidelines for what constitutes as an experienced volunteer vs. chief level experience. For instance, was someone being deployed once for 3 days constitutes as an experienced member? or does it have to be multiple deployments with specific set of days/times that makes someone experienced or a specific function or role? | It would be good to find out how many active members and how long they have been a member that have never been contacted for deployment. Then, we can start investigating why they are not being called for deployment. Perhaps we may find some of them need more training, or that they selected a role they want to volunteer in that may not be a great fit for their skills set. We can use the training data, detailed job descriptions and employee history for training matchmaking. New Members: Getting clearer on what trainings we can provide to onboard and prepare new members for deployment that can be easily accessible and available. In-person training is highly valuable and creating opportunities for this during the “slower” months; so that new members can start familiarizing themselves in there volunteer role in an emergency management context. Revamping our content to set expectations on how deployment decisions are made and making that available to new members.
Current Active Members: Creating clearer criteria for what constitutes as Experienced vs. Chief level experience. Map out an evaluation framework for different levels of experiences skills, and training. For example, if a member has been deployed 3 times for a duration of 14 days, they are considered Experienced vs. someone who have been deployed 1 time for a duration of 3 days.
Tech enhancements: |
Phase 4 of the User Journey: Deployment | Deployment Opportunities: We’ve learned from the Coordinators that as much as they want to deploy new members, it is hard for them to know which ones to deploy for a particular role. This is typically a conversation that happens between the Coordinator and the new member. Coordinators are wishing for a more streamline process for how to do this while ensuring equity of deployment opportunities.
Deployment Opportunities + History: Expanding the notification feature for updating members' availability: Supervisors: They are feeling that they are pressured to approve their employees to be deployed. For example, their employees want to participate and they also get messaging from their executives to support the program. However, there are still pressures to deliver the work in their area and allowing an employee to be deployed can significantly hinder delivery of priorities in their program area.
| Talent Matchmaking: We can use the training data, detailed job descriptions and employee history for talent matchmaking. For example, a new member showing in their training data that they have done trainings in project management. Imagine further that we have a detailed job description for a Planning role with “skills & training requirements”, and then, in their employee history, we can see that their previous jobs included roles as an Operations Planner. We can then use these data sets to determine what volunteer role they can be best suited for. Imagine where we can prompt the members and coordinators to show them “suggested roles” according to our experience, skills, and training. Tech can help with automating this if we have defined these data sets well.
Deployment Opportunities + History: We can expand the application to be able to do this. We can show deployment opportunities and history in the member profile. We can expand the application to enable Coordinates with seeing the data. For example, how many deployment opportunities from January to March.
Expanding the notification feature for updating members' availability: Supervisors: They want more information on what to expect during deployment: duration, what supports are there for mental and health wellbeing for their employees. They want more support in ensuring that they can be supported to scope their deliverables if the expectation is to allow employees to be deployed.
|
Phase 5 of the User Journey: Post-Deployment | Surveys/Evaluation: Coordinators and members alike want to be able to provide feedback. Coordinators want to be able to evaluate a member’s performance. Members also want to provide feedback on how it went for them. Although there are some processes in place like exit interviews, these are not applied consistently due to workload and time constraints.
Payment/Compensation: Supervisors need more clarity on what are the different compensation models and what are being paid by EMCR/BCWS vs. their ministry. We also learned that processing JVs for EMCR/BCWS and for the ministry can be cumbersome. Hence, creating churn in the system that delays compensation.
| Post-Deployment Evaluation: Payment/Compensation: Creating a clearer information on how compensation are allocated and making this accessible to supervisors. We can build out a payment system in the CORE Team application to allow for: members confirming their volunteer timesheet, sending that BCWS/EMCR and their supervisors, and allowing for automation of those approvals in the system. While also connecting to our pay systems to enable quicker turnaround for payment.
|
One program/one platform | Now that we’ve established EMCR as the owner of the program and the product, what would it look like for BCWS in the future and other ministries that have emergency management related functions like Transportation, Infrastructure, Health, Agriculture and Food, etc? Some of these ministries are needing access to CORE Team and instead of making their own programs, we should leverage what we already have by making it accessible to the whole BC Government. | Program: Find out what would be the future program administration + processes for having one program. Figure out the process for when ministries need volunteers: Sending a resource request? How do they get to decide which talent to deploy?
Once we clarify the program and policy elements, we can start building the mechanisms to streamline this process with technology. We can build out CORE to include another user group in the system. |
Data Reporting: Statistics | Coordinators and executives alike are needing more data and access to that data in an easy way to learn about how the program is doing but also to learn about opportunities for continuous improvement. Data is needed from all the phases of user journey. | We need to clarify the datasets that we need to collect. So that, we can start defining those in our application and we can start collecting those consistently. Build a dynamic dashboard that can show, examples: Measuring deployment by days and incidents Measuring deployment by roles and functions Measuring deployment by Fire Centre(s) and Region(s) Tracking of how many members are inactive and why
|