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
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
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
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
Our second step was researching and analysing the organisation
and the industry and interviewing stakeholders to identify and define the
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
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
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
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
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
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
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
We continuously monitored the solution and fine-tuned it to
ensure that it was meeting the needs of the organisation and the end users.
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
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
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.