Select Projects
Workforce Planning Forecasting Model (2022)
At Google, I had to forecast case volume for 3 different teams. Each team worked across 3 regions (US, Americas, EMEA, APAC), with a total of 25 different case types across the teams. The simple option of creating forecasts ini Google sheets was not feasible.
First, I explored different options used by enterprise grade workforce planning software. While these solutions would be sustainable long term, the team did not have the budget to implement a solution prior to the start of the business planning cycle.
Next, I explored open-source time-series forecast packages as we did not have the budget for enterprise grade software. After testing several options, I used Statsforecast as it allowed multiple models to be tested and allowed additional regressors to be included.
Finally, I built a Google co-lab that allowed a time-series data set to be uploaded from a Google sheet, forecast, and exported to the same Google sheet.
This process reduced the time taken to build a forecasting model for a new timeseries from a week to about an hour.
Salesforce Dashboard and Report Migration (2013)
At Accenture, a telecommunications, media, and entertainment client needed to consolidate two Salesforce.com instances to reduce their operational and licensing costs. My team's role was to migrate the 20,000 reports and dashboards from one instance to the other. At the time, there was no documented process from Salesforce to complete a migration, other than to recreate each report and dashboard manually.
First, I took inventory of the reports and dashboards to be migrated. We needed to ensure that we weren't migrating items that were no longer needed. I worked with the system administrator to identify report owners and contact them to confirm if the reports were required. This allowed us to reduce the number of reports from ~30,000 to 20,000.
Second, I developed a method to migrate the schema for each report and dashboard. I identified that the schema of each report and dashboard was accessible using the Force.com Integrated Development Environment (IDE). I created a proof of concept using the development environments from each instance, and migrated a report and dashboard succesfully. I documented the process and tested multiple times to ensure accuracy.
With both these items in place, we ran the reports and dashboard migration as part of the instance consolidation. The migration was succesful, with 100% of the reports and dashboards functional in the new environment at "go live"
What I learned from the experience is that it is important to reduce the size of the problem where possible. Second, a solution to a technical problem like this one requires iteration, but more importantly, clear documentation.
Release Planning Database (2011)
In my first project at Accenture, our 5 person team was responsible for remote operating system updates for a large pharmaceutical client. The client had 20,000 computers located across the Americas and EMEA. To maintain operations, certain computers (e.g., running lab equipment) could only be scheduled for an update at specific intervals. A client employee also needed to ensure the computer was switched on before the update started, so we needed to ensure that the employee was correctly matched to the computer, and was in the office.
The release team's role was to schedule the updates and provide support to client employees. To manage the process, we were provided spreadsheets of data that were updated daily from the deployment team. We then worked through these spreadsheets to determine which computers still needed the update, and contacted the relevant departments to schedule them. The challenge was that it was a very manual process to cross check spreadsheets and make changes to the schedule. Addtionally, there was little version control and no single source of truth.
To solve this problem, I created a Microsoft Access database which:
Ingested the daily spreadsheets and updated the details and status of the computer
Had a simple Pivot table to filter computers by region, status, and schedule - which we could all access simultaneously (this was before Microsoft OneDrive / Google Cloud)
This allowed our team to reduce time spent on cross-checking spreadsheets, allowing us to provide better customer service to employees that were having trouble with their updates. I learned that it's important to break down a problem into its component parts and that not all the problems need to be solved to increase a team's productivity.