Deliver a rostering and resource allocation solution to coordinate and deploy the field contractor workforce. Ensure the system could scale up to meet operational demand. Use the solution to analyse workforce data and provide regular business intelligence reporting for the organisation.
Year: 2010 (14 Days) Type: Government State Owned Entity Region: Christchurch, New Zealand Industry: Insurance, Disaster Response
A large-scale natural disaster (earthquake) caused extensive damage to people’s homes, land, and contents. The damage resulted in a large and rapidly growing number of insurance claims lodged with my client.
The volume of claims inundated the organisation, quickly overwhelming existing systems, processes, strategies, and plans. The Chief Operating Officer (COO) said, “we need continuity of people”, and he asked me to “make it happen”.
My focus was field operations. I undertook this project to investigate the root cause of the problems and develop solutions to improve the logistics of workforce planning, rostering, and resource allocation for the organisation’s disaster response.
I recruited a Data Analyst, and we carried out this project in collaboration with the client, designing the solution to meet the specific needs and requirements of the organisation.
This Case Study describes the development of a Minimum Viable Product (MVP) implemented and operational within 14 days.
Following the success of this project, the client appointed me to the newly created role of Workforce Planning Manager. For the next 18 months, I served on multiple project teams as an analyst solving problems and delivering solutions for this client.
We did this at the beginning as a brainstorming exercise on a whiteboard and flip paper. First, we started with a hypothesis of the problem. Next, we worked out where we could obtain information and data that helped us prove or disprove our hypothesis, eventually ending up with a proven theory (defined problem). That was the basic logic of our investigation and analysis approach.
We developed an Information Investigation Plan (IIP) to structure our approach, and document the data collection process, sources, schedule, and data analysis methods. The IIP helped to ensure that the information obtained was accurate, relevant, and sufficient for the project. The IIP included the following:
For the project’s duration, we continued to add to the IIP. It’s a necessary foundation document for all business investigation and analysis projects.
Our second step was researching and analysing the organisation and the industry and interviewing stakeholders to identify and define the problem.
The continuation of damaging earthquakes and aftershocks compounded the problem, making forecasting the number of insurance claims nearly impossible. In addition, calculating the number of field contractors (assessors and estimators) needed and the resources they would require to assess the claims was also impossible.
Additionally, there were inefficiencies in the rostering and resourcing process, which led to a longer time to assess claims. This resulted in longer wait times for claimants, higher costs for the organisation and lower operational efficiency.
We conducted document analysis and interviews to better understand the problem, including reviewing previous reports, studies, and data on the organisation’s response to natural disasters. We used this information to develop a problem and vision statement.
The problem statement was: “The organisation’s response to natural disaster insurance claims is hindered by inefficiencies in the logistics of workforce planning, rostering, and resourcing, leading to longer wait times for claimants, higher costs for the organisation, and lower operational efficiency.”
The vision statement was: “To develop a solution that improves the logistics of workforce planning, rostering and resourcing for the organisation’s response to natural disaster insurance claims, resulting in shorter wait times for claimants, lower costs for the organisation and higher operational efficiency.”
At the end of this step, we clearly understood the problem and its root causes. We developed objectives for the project, which helped to guide the development of the solution.
The next step in the project was to develop a clear understanding of what the solution would include and its limitations. This included defining the objectives and expected outcomes of the solution.
Due to the continuous damaging aftershocks and a seemingly endless number of insurance claims, the standard workforce planning metrics were not applicable. So instead, we focused on ensuring the solution could scale to any number of claims and field contractors.
The proposed solution used Microsoft Excel (2010) to implement a workforce planning and business intelligence reporting system. Excel would also help us predict the number of claims a team (assessor and estimator) could assess and allocate resources accordingly.
Additionally, an efficient rostering and resourcing process would be implemented to ensure that the right resources were allocated to the right field office at the right time.
We designed the solution to improve workforce planning, rostering, and resource allocation logistics. The expected results were shorter wait times for claimants, lower costs for the organisation, staff availability to meet operational demand, and higher operational efficiency.
In addition, the contractors received a work schedule that gave them a three-month view.
The product scope for this project included the following:
We developed a Project Charter, which included project scope, objectives, deliverables, timelines, and resource allocation. The Project Charter helped ensure the project stayed on track and stakeholders were aware of the goals and expectations of the project.
We validated the proposed solution by ensuring it aligned with the organisation’s goals and objectives and that its time and cost investment was financially justified.
We compared the solution to the organisation’s overall strategy and goals for responding to natural disasters. We found that the proposed solution would improve workforce planning, rostering and resourcing logistics. In addition, the proposed solution aligned with the organisation’s goal of reducing the wait time for claimants, lowering costs and increasing operational efficiency.
To confirm financial justification, we conducted a cost-benefit analysis to compare the costs of the solution with the expected benefits.
The analysis showed that the solution’s benefits would greatly outweigh the costs. Additionally, a return on investment (ROI) analysis was conducted, which determined that the organisation would see a positive ROI within 30 days.
The field contractors (assessor and estimator) worked in two-person teams. However, during our investigation, we found a mismatch between estimators’ and assessors’ start and end days. As a result, contractors waited up to 3 days for a partner so they could go into the field and assess claims.
We calculated this as the: Number of contractors X amount of wait time (hours) X average hourly rate ($). We quantified the result of the calculation in dollars, lost productivity, and the number of claims not assessed. I’m not disclosing the results except to say it was enough to get the Government to change its policy and the organisation to adopt our solution.
We presented all the above analyses to the COO and relevant stakeholders for review and approval. Finally, we aligned the proposed solution with the organisation’s goals and provided financial justification and technical feasibility.
Completing the above four steps was marked Checkpoint Alpha, and the COO decided we should continue the following three steps to Checkpoint Bravo.
We used the information collected during the previous steps to model the problem domain. The Problem Domain Model (PDM) helped us to understand the big picture and identify underlying issues that our solution needed to address. In addition, it helped us establish a Current State Baseline (CSB) for the problem domain.
The baseline included the following:
The problem domain model provided a visual representation of the problem domain, including the inputs, processes, outputs, and feedback loops. The model highlighted the critical areas of inefficiency in the logistics of workforce planning, rostering and resourcing.
We identified Key Performance Indicators (KPIs) to measure the solution’s success in addressing the problem. These included:
We circulated the CSB, PDM, and KPIs with relevant stakeholders for review and approval. We provided the stakeholders with a clear understanding of the problem domain and that the proposed solution would address the correct problem.
With the PDM, we could see all the parts of the organisation impacted by the problem and its solution. However, we failed to foresee how stakeholders (internal & external) would come to rely on the data and reports produced by the solution.
The solution became the single source of truth for everything from signing leases on new offices to purchasing equipment to booking hotel rooms to reconciling contractor invoices.
We developed the following solution to address the issues identified in the previous steps:
Elements of the solution included the following:
We designed the solutions to provide the necessary tools and information to improve the efficiency and effectiveness of the organisation’s disaster response. It also offered better tracking and managing resources, including personnel and equipment.
The solution was complex to conceive but elegant and simple in its execution. Moreover, it could scale infinitely, with the main limitation being computer processing power to run equations in the Excel database. We fried two new laptops when running Rotation Reports!
We established a Rotation System (three weeks on, one week off). One rotation per month. We assigned Pods to a Rotation. We had four Rotations (A, B, C, D). When individuals couldn’t make a rotation for whatever reason, we slotted them into the next Rotation in a new Pod and Team.
The solution scaled up, to just under 1600 contractors in the database, with around 1200 active in rotation. We produced Rotation Reports that orchestrated the movement (rotation) of 300 Contractors out on a Saturday and 300 in on a Sunday. In addition, the Rotation Report facilitated allocating resources, including phones, iPads, equipment, vehicles, and accommodation.
Internal processes relied on the Rotation report, such as booking and managing accommodation, contractor invoice reconciliation, performance management, and operational processes.
We prepared detailed documentation outlining the solution, including the design and implementation, technical specifications, and testing plan. We designed this documentation to provide clear instructions on implementing and maintaining the solution.
The following documents were developed and included in the solution documentation:
We circulated solution documentation with relevant stakeholders and the COO for review and approval. Their feedback helped us to ensure that we aligned with the organisation’s goals and objectives and that the investment in the solution was financially justified.
Completing the above three steps was marked Checkpoint Bravo, and the COO decided we should continue the following three steps to Checkpoint Charlie.
We implemented the solution according to the plan and monitored its performance to ensure it was working as intended.
My Data Analyst and I implemented the solution. I was responsible and accountable for installing and configuring the solution and providing training and support to end users.
Once we had fully implemented the solution, we monitored its performance to ensure that it met the project’s goals and objectives. This included:
We continuously monitored the solution and fine-tuned it to ensure that it was meeting the needs of the organisation and the end users.
The solution:
Our solution’s data and business intelligence reporting became the single truth source for all workforce metrics. In addition, it was used externally by other interested stakeholders.
We verified that the solution had solved the problems of inefficient workforce planning, rostering and resourcing logistics and that the solution had met the goals and objectives of the project.
We undertook the following activities to confirm the solution had solved the problems:
Based on these activities’ results, we could confirm that the solution had effectively addressed the problems. In addition, the solution improved the organisation’s disaster response capability by optimising the rostering and resourcing logistics, which resulted in increased efficiency and reduced costs. Furthermore, external stakeholders reviewed our solution and provided highly positive feedback.
We prepared a Transition Plan addressing organisational changes, process changes, and Standard Operating Procedure (SOP) changes needed to implement the solution fully.
We undertook the following activities to manage the transition and change:
We implemented the solution in a phased approach, with the MPV being the first phase. We used the MVP to test the solution and gather feedback from end users and stakeholders. This approach helped ensure a smooth transition, with issues identified and addressed early on.
We solved a big complex problem as quickly as possible using the currently available tools. The solution’s success meant that all departments within the organisation relied on its data and business intelligence for their needs. It became the single source of truth for all workforce metrics.
Completing the above three steps was marked Checkpoint Charlie and the end of this project phase. As we operated the solution, we updated all documentation and spoke to many stakeholders to obtain input and Lessons Learned. As a result, we received many feature requests and requests for bespoke reports.
After approximately six months, the solution outgrew its technical and business intelligence capabilities. The main limitations were bespoke reporting and the solution being offline. At that stage, we designed a new solution that involved developing new workforce planning software.
This project led to me designing the Architecture for some Workforce Planning Software and then designing a solution for Performance Management. I served on both of those projects as an analyst.
When we talk, we can discuss your business and work out the best place to start. Every business needs different things, so we can mix and match elements of the systems to suit your business. Installing the systems follows the three stages below.
There are Ten Steps in the Business Investigation and Analysts System and Three Checkpoints when a decision is made to stop at that Step or continue onto the next Checkpoint.
Prepare an information-investigation plan to determine the solution. First, we identify the information needed to define the problem and solution. Then, where can we find the information? Next, how can we obtain the information? Finally, what order to get the information?
Output: Document Analysis. Information Investigation Plan (IIP).
In this step, we define the problem owner, prepare an information-gathering plan to determine the problem, and elicit information about the problem. We then analyse the information, determine the real problem to be solved, and confirm that with the problem owner.
Output: Root Case Analysis. Problem Statement. Vision Statement.
We develop a vision of the solution and acceptance criteria with the problem owner and determine stakeholders. Then, conduct risk analysis and justification for solving the problem. Finally, we identify solution constraints, functional goals, and business objectives.
Output: Decision Documents (product scope, business case, project charter).
We review organisational vision, mission statements, strategic and business plans, and policy to ensure the solution or product aligns and supports achieving goals and objectives. In addition, we provide financial justification for solving the problem.
This step if Checkpoint Alpha, a decision is made stop here or continue to Checkpoint Bravo.
Output: ROI Analysis. Cost/Benefit Analysis. Risk Analysis. Feasibility Study.
Obtain information to describe and diagram the problem domain. First, we understand completely why the problem exists and what conditions cause the problem. Then, we determine the functional areas impacted by the problem and its solution. Finally, we identify neighbouring constituencies, intersecting processes, and ancillary benefits.
Output: Current State Baseline of the Problem Domain. Problem Domain Diagram or Model.
Analyse the information to determine potential solutions for the problem. First, we analyse and model the solution. Then, we create the necessary models and diagrams. Finally, we confirm our analysis with the affected product stakeholders that the part of the solution that affects them will work and is acceptable.
Output: Entity Relationship Diagram. Data Flow Diagram. Activity Diagram. Use Cases.
Confirm with the stakeholders that the solution completely and accurately solves the problem. First, we get parts of the solution confirmed as they are defined. Then, we check the technical and project feasibility and validate requirements with the solution team and stakeholders. Finally, we get the solution document approved by the executive decision-maker.
This is Checkpoint Bravo, a decision is made here to stop here or continue to Checkpoint Charlie.
Output: Solution Diagram, Data, Process & Behaviour Models. Requirements Documents. Business Rules. Event Analysis. Gap Analysis. User Stories.
Turn the solution definition into an operational system or process. First, we work with the solution team throughout product implementation. Then, we make sure the solution document matches the solution, and document, evaluate and review any changes. Then, we prepare user test cases and ensure the solution successfully transitions into the business environment.
Output: Requirements Changes. Acceptance Testing.
Prove that the product has achieved an acceptable level of confidence that it will behave as expected under all circumstances of interest. First, we establish the basic criteria against which quality assurance judges the quality of the product. Then, we confirm that the final definition of correct behaviour (the solution document) matches the delivered product. Finally, we make sure the product solves the original problem and proves the solution is effective and stays effective by measuring the results.
Output: Unit, Integration, System, and Acceptance test results. Bug/Defect Report.
Prepare the business for a successful transition to the new process. First, we create a sense of urgency for change, create a guiding coalition, and develop a vision of the changed environment. Then, we communicate the change vision and empower action to affect change. Finally, we generate short-term wins, consolidate gains, produce more change, and anchor new cultural approaches.
This is Checkpoint Charlie, it marks the end of the project. At this stage Lessons Learned regarding the Business Investigation and Analysis Project should be conducted.
Output: Change Management Plan. Change Impact Diagram. Training Plan. User Manuals. Help-desk. Updated Baseline Requirements Document. Lessons Learned.
Give me a call on +64 20 4165 4856 or use the form to send me an email. I normally reply within 48 hours. I look forward to talking with you soon.
