Scheduling

Relations from Other Scenarios

Cost Tracking ← inspect over-cost tasks ← Scheduling

Relations to Other Scenarios

Scheduling → task shadows → Evolving Plan

Summary🔗

The schedulers do not want to use BIMprove system for scheduling and planning. This scenario therefore looks into how we integrate with the external solutions.

Models🔗

last_planner_data🔗

This is the model containing all the last planner tasks accessible through the external last planner system.

Definitions🔗

phase plan🔗

A legally binding coarse long-term plan.

last planner system🔗

The software solution for managing lean construction.

Note that the last planner system can also refer to a planning system. In this document, we use the term to refer to a software system, not a planning system.

task🔗

Piece of work that needs to be scheduled.

It is represented as last planner task in last_planner_data, and as a task shadow in bim_extended (from evolving_plan).

last planner task🔗

A task managed by a last planner system and living in last_planner_data.

task shadow🔗

Task shadow is an IfcTask living in the bim_extended (from evolving_plan) shadowing the last planner task.

Scenario🔗

The preceding aspect sections intentionally left empty.

Scheduling🔗

The schedulers do not want to use BIMprove system for scheduling and explicitly want to rely on external tools. This scenario therefore looks into how we integrate with the external solutions.

Notably, we do not aim to integrate with solutions for long-term coarse planning (a.k.a. phase plan). Such solutions include Synchro, Microsoft Project, Primavera and others. The phase plans are legally binding and change only very infrequently, if ever, during the project. As they are not updated frequently enough, we can not use them as a reliable source for the time dimension.

Instead of phase plans, we focus on the short-term plans managed by the last planner systems.

We focus only on a single last planner system, Visilean, but we can integrate with other solutions later (e.g., Synchro, Microsoft Project, Houly and TouchPlan).

As the scheduling is done outside of BIMprove, we explicitly do not provide re-scheduling functionality. It is a non-goal to develop a last planner system. In the same line, we do not develop analytics and obstacle and delay analysis for the tasks. This is part of the external last planner system.

Importing. We only help the progress monitoring and import the scheduling information from the external parties to link it with the elements in bim3d (from evolving_plan) and bim_extended (from evolving_plan).

In order to model the tasks, we have to create task shadows and their relationships, as well as map the references to actors and building elements from the last planner system to bim_extended (from evolving_plan).

The data in last_planner_data needs to be imported continuously into bim_extended (from evolving_plan) (via triggers, polling or manual export/import, depending on what is available).

The import workflow from last_planner_data to bim_extended (from evolving_plan) follows the steps:

Create/update the task shadows for all the last planner tasks
- Parse the last planner task either directly (if possible, depending on the export format) or using structured text in the body
Map the actors (from actor_management)
Map the references to building elements
Create/update the shadows for all the relationships between the tasks and actors (from actor_management)

Mind that the system should not completely overwrite the relevant data in bim_extended (from evolving_plan), but extend it. This means that we assume the guids (from evolving_plan) to be stable throughout the project. (It is also tricky to handle the deletions, which is left as an important implementation detail.)

If the last planner system does not provide a mechanism to explicitly link to building elements, actor (from actor_management) and the relationships, we extract this information from the structured text of the last planner task body (e.g., from the footer, similar to git trailers).

For example, we can use guid (from evolving_plan) and Related elements: to structure the references to the building elements:

Related elements:
f6b569e9-beb8-42e7-a44e-4213b92ffb22,
b5e9a2b8-687e-4f5e-a34f-c0fd42768672,
f0ee91a0-d423-4c65-8c01-0c5ba842f9a6

(Alternatively, we might use URLs, URIs etc. We leave the representation as an important implementation detail.)

We can also specify some of the properties of a task. For example, to specify the task type (PredefinedType), we can write in the body of the last planner task:

PredefinedType: CONSTRUCTION

Visualization. As the planning is done by the external last planner system, we do not aim for a sophisticated visualization.

The system should provide basic browsing experience so that other parts of the system can link to the task to show further details.

BIMprove system should be able to:

Show the list of the tasks,
Show the detail information about the task and its relationships to actors and elements, and
Display the timeline (nice-to-have)

For example, showing the detailed information is important so that the user can get the detailed information about a task coming from "Virtual Inspection".

Risks. We need to visualize the risks (from risk_management) (such as fall or fire risks) related to the tasks.

The user should be able to follow through to examine the risk in more detail in the specific application through a identifier (from unique_resource_identification).

Task to topic. The user should be provided the interface to translate a task shadow to a topic (from topic_management). Since the task shadows are read-only, the additional information (such as references to BIMprove-specific entities) about the task can only be included in the topic (from topic_management), but can not be fed back to the last planner system.

There are also more structured options available in the system. For example, a delivery task can be automatically converted to delivery (from logistics) as a topic (from topic_management) (see "Logistics").

Closing of tasks. Since we do not control the last planner tasks (we only import them), we can not close the tasks automatically.

The user or the system should be able to convert a last planner task into a topic (from topic_management) and keep track of its status using comments (from topic_management).

In many cases, if the system is tracking the status and not the user, we use structured comments (from topic_management). For example, the task corresponding to a delivery (from logistics) is converted to a topic (from topic_management). So when the delivery is terminated, we can close the topic (from topic_management) (which we control), but we can only notify the scheduler. The scheduler needs to close the corresponding last planner task in the last planner system manually.

We emphasize here that there is only a unidirectional data flow:

last planner task to
task shadow (via synchronization) to
delivery (from logistics) (via conversion) to
delivery closed (via delivery update (from logistics)) to
last planner task closed (manually via last planner system) to
task shadow closed (via synchronization).

Perhaps we can have special topics (from topic_management) which we can directly link to closing of the tasks and feed-back the closing to the last planner system, but this remains to be seen at the implementation.

The remaining aspect sections intentionally left empty.