Real Project Example
Task and Incident Forecasting Project Example
Our goal is to present an example project that addresses the challenges of task duration forecasting as well as identifying patterns of incidents. This case study showcases steps we can take to address your specific needs in this area, presenting a project vision, identifying challenges, and initial analysis.
Outline of Project Vision
We were presented with a large-scale construction project with numerous interconnected tasks. After receiving the project concept and conducting initial discussions, we developed an outline of the project vision and shared it with the client.
First of all, we presented our understanding of the project’s current state, objectives as currently perceived, an initial phase task list, and any questions we have at this stage.
During the initial phase, our primary goal was to assess the feasibility of achieving the project goals. To optimize resource allocation, we strived to make this phase as short as possible.
To ensure our vision was accurately reflected and the proposed plan would get approved, we iterated through several stages to finalize the document step by step.
In the scope of this project, we are given two main challenges:
To forecast the duration of tasks
To identify patterns of incidents
Forecasting Duration of Tasks
Challenges and Goals
Forecasting the duration of tasks manually by experts or subcontractors can lead to poor quality estimations. Our goal is to develop software that predicts task duration more accurately based on existing historical data.
The Analysis Phase
We have a task that can be represented as a hierarchical structure of numeric and categorical data. For each task, we have the recorded time to completion. Our objective is to build a function that takes this same structure as input and returns the expected time to completion as output. This can be achieved through either ML techniques or classical mathematical approaches.
Firstly, we need to ensure that achieving our goal is feasible. To do so, we need to verify if we might face any of the significant problems listed below. If no significant problems are identified, we can proceed with the project.
Most important risks:
Some critical factors that affect the result are not documented in the existing system.
We can have insufficient data.
Old data could become irrelevant or outdated and may not provide meaningful insights for new projects.
Less important risks:
It is better to replace some categorical parameters (e.g., equipment manufacturer) with a set of numerical characteristics, so different equipment will be comparable. However, it is not always possible to do so.
Some characteristics of new projects could be completely new (having never appeared in the past). For example, we could start using entirely new equipment in an entirely new location. This affects prediction quality.
We could have problems with noisy data.
Preliminary plan
Learn how much data is available.
Find and document the structure of a task (all its characteristics and related objects).
Classify tasks: We need to divide tasks into independent classes, as tasks of different types may not be related to one another. Data related to one class should not be used to predict the duration of a task in another class.
Try to convert categorical characteristics to numeric values where possible.
Talk to experts and learn what characteristics they consider important when estimating the tasks manually. Ask them what they think are the main reasons for the estimation inaccuracy.
Verify if our data includes both the estimated and actual completion times of tasks (if available, this information could be valuable).
Explore ways to obtain data from the company.
Develop multiple rapid prototypes and employ classical approaches to address the initial risk: ensuring that the data correlates task characteristics with their durations effectively.
If the data proves beneficial and the prediction accuracy meets our standards, we can proceed.
Identifying the Patterns of Incidents
Challenges and Goals
An incident (or an issue) is a documented problem that can cause delays, issues, or deviations from expected outcomes. For example in a construction project, it could be an equipment failure or any other non-desired event.
Incidents are registered in the client’s software system. It can be challenging to identify what reasons are most often causing problems.
Our goal is to use the collected data to identify the most frequently repeated patterns of incident causes, enabling management to mitigate these issues in the future. These patterns could be as simple as 'Equipment X is of poor quality, as it failed 20 times out of 34 cases,' or more complex, such as 'Equipment X should not be used together with Equipment Y,' or even 'Equipment X should not be used under specific conditions,' etc."
The Analysis Phase:
Determining the Incident's Patterns
Description
From a technical point of view, the task is to determine and list independent classes of incidents.
For each class, we will need to include not only the incidents themself but also all the similar cases where no incidents happened. The cases with incidents are named “positive cases”. The cases without incidents - “negative cases”
For each class, it's essential to gather all positive and negative cases. For example, if we perform an action 1000 times within different projects, we have 1000 cases. If we had 3 incidents for these cases, we have 3 positive cases and 997 negative cases
For each class, our task is to determine the subset of factors that affect the result—whether we have an incident or not and the values for those factors that correlate with the positive cases.
Risks to mitigate
The data could lack some critical factors, so the data we have may not correlate with the incidents.
We might face a scenario where we have numerous incident classes but insufficient data for each.
We could lack data for negative cases (where no incidents happened). If we only have positive cases, it will not be enough to solve this kind of problem.
Even if we find a correlation between the data and the result for some incident classes, it still does not warrant the same for other classes.
Preliminary plan
Determine all the incident classes.
Check if we have data for negative cases (when no incidents happen).
Select 1-3 most important incident classes to test.
Determine a set of all characteristics for the selected classes.
Obtain all the required data.
Try different methods to determine important factors (the factors that affect the result) and their values correlating with the positive cases.
Following this step, we will determine the feasibility of the solution and then proceed to go on with the rest of the project.
To learn more, please visit our custom forecasting software development page
Read more
Transform Your Business Today –
Get Your Free Consultation
Connect with us and the first consultation will be provided free of charge.
