Cost Tracking

Relations to Other Scenarios

Cost Tracking → inspect over-cost tasks → Scheduling

Summary🔗

This scenario looks into how to track the expenditures against the planned costs.

Definitions🔗

performance history🔗

The performance history define a category of expenditures based on the life cycle phase.

It is an IfcPerfromanceHistory and lives in bim_extended (from evolving_plan).

Expenditure is an IfcCostItem living in bim_extended (from evolving_plan) together with its relations. In particular, to distinguish it from estimated costs, expenditures are explicitly linked to a performance history through IfcRelAssignsToControl (where the performance history is the control and the expenditure the related object).

It can be linked to task shadows (from scheduling) through GUIDs and IfcRelAssignsToControl (where the task shadows is the related object). See buildingsmart IFC lexicon on control assingment of IfcCostItem on an example how cost items can be assigned to tasks (and other objects such as elements).

The cost items can be composed, see [buildingsmart IFC lexicon on IfcCostItem].

cost🔗

Cost is an IfcCostItem living in bim_extended (from evolving_plan) representing an estimated cost.

The cost items can be composed, see buildingsmart IFC lexicon on nesting of IfcCostItem.

over-cost task🔗

An over-cost task is a task (from scheduling) whose sum of related expenditures are greater than the sum of the related estimated costs.

Scenario🔗

The preceding aspect sections intentionally left empty.

Cost🔗

Capturing estimating costs is out-of-scope of the BIMProve project. We rely on third-party platforms to provide us with the data which we shadow in our system as costs. The external data is imported continuously based on a common format.

Analogously, we rely on a (possibly different) platform for tracking project expenditures. The expenditure data is continuously imported and shadowed in our system as expenditures.

The relations from both the estimated costs and expenditures to task shadows (from scheduling) need to be encoded in the import data format.

We link both the costs and expenditures to actual building elements over task shadows (from scheduling).

(At this moment, we still have not decided on the third-party platform for cost planning and expenditures, so the import details have to be specified later.)

We explicitly do not use a more complex structure involving IfcWorkPlan and IfcCostSchedule as these seem too complex to be easily imported from the third-party platforms, while they bring insufficient additional benefit.

Analytics🔗

The user should be able to see the over-cost tasks. The table should be color coded (e.g., showing over-cost tasks which are <10%, 10-20%, 20-50% and >50% over budget).

(At this point, we do not know how the costs will be actually attributed. It is possible that there are costs and expenditures which are not related to a single task or related to multiple tasks. We have to decide later how we aggregate them appropriately.)

The remaining aspect sections intentionally left empty.

Test Cases🔗

We still lack comprehensive information on this scenario so the test cases are left out at the moment.

Acceptance Criteria🔗

We still lack comprehensive information on this scenario so the acceptance criteria are left out at the moment.

Table of Contents