Task Linking

In the realm of large scale construction it is standard to maintain a full project lifecycle schedule usually spanning several years. Relatively speaking, optimal output from Fuzor requires Micro Scheduling, a more detailed and specific scheduling of tasks.

To make a realistic schedule with Fuzor, tasks must be broken down into individual operations. When this is done properly it allows for a holistic and approach to project planning. IDD Teams can perform a detailed and visual audit of the construction simulation before the project begins. This is an opportunity to avoid scheduling issues, safety hazards and modeling errors.

A holistic approach to schedule integrations allows for faster and more accurate turn around time for a ensuing construction simulation audit. After loading new schedule data, each detailed step in a procedure can be reviewed with the revision to the schedule.

Because schedule updates are so integral to Fuzor Project management it is important for a Fuzor user to know the best practices to ensure schedule updates run smoothly.

A Macrotask is a task imported into Fuzor from another software. A psuedo Macrotask can also be created in Fuzor unders specific conditions

A Microtask can only be created in Fuzor.

When a microtask is created it is created as the child of the selected task.

Creating a WBS relationship is easy. Microtasks should be added as children of the Macrotask. In the example below 'Microtask 1', 'Microtask 2', and 'Microtask 3' are children of ‘Macrotask'. If multiple tasks need to be updated it is best to link them together with Predecessor relationships.

For more information about predecessors and successor see LINKLINKLINK. for more information about editing WBS structure see LINKLINLLINK.

When a schedule update is made to ‘Macrotask’ that changes the start date ‘Microtask 1’, ‘Microtask 2’ and ‘Microtask 3’ will all have their start dates adjusted by the same amount.

There are two methods to create or set a task as a child

Creates a set number of children under the currently selected task.

Indents a task. This will set the selected task as a child of task that is directly above it in the gantt chant

A Logic Relationship utilizes scheduling logic that is present in other software as well as Fuzor and will be familiar for those acquainted with scheduling. Both Constraints and Logic Links (Predecessor -Successor Relationships) are used in a Logic Relationship. In the Example Below ‘Microtask’ one and ‘Microtask 3' are both successors to ‘Macrotask’. However, They have different kinds of relationships. Additionally all Microtasks associated with this Macrotask are in a Predecessor Chain.

• ‘Microtask 1’ is a Start - Start Successor to ‘Macrotask’

• ‘Microtask 2’ Is a Start - Finish Successor to ‘Microtask 1’

• ‘Microtask 3’ Is a Start -Finish Successor to ‘Microtask 2’ and it is a Finish - Finish Successor to ‘Macrotask’.

Additionally Each Microtask in the Example has an ASAP Constraint set as its constraint type.

For more infromationabout predecessors and successor see LINKLINKLINK. for more information about Changing Constraint Types see LINKLINLLINK.

When a schedule update is made to ‘Macrotask’ that changes the start date ‘Microtask 1’, ‘Microtask 2’ and ‘Microtask 3’ will all have their start dates adjusted by the same amount.

Schedule Updates come in many forms. Depending on the difference in data a specific Task Link Method and Update workflow may be required to have the expected result. In order to manage a project which requires schedule updates you should be familiar with the two Linking Methods discussed earlier in this chapter, and the Two Update Methods:

• The Column Mapping Update Workflow. For more information see.

• XML update workflow. For more information see.

Base Update Case : To understand the other cases of schedule updates. We first need to understand what the most simple update case is:

• Microtasks and Macrotasks exist in the Fuzor Project.

• Tasks In both the original and the Update XML have the same ID, Unique ID if using Microsoft Project.

• Manually schedule tasks is unchecked in the Fuzor Construction Settings.

• Autofill duration is checked in the Fuzor Construction Settings.

• Changes to durations Macrotasks are not expected to reflected in Linked Microtasks.

• New Calendars, Baselines, and Activity Codes are not needed or unchanged in the update.

• The data date is not changed.

• We are expecting dates and durations of the Microtasks to be offset by the change in dates and durations of macrotask it is linked too.

If the schedule update meets the above parameters any Update workflow and Linking method is appropriate and Microtasks will update as expected with their associated relationship.

Deleted Macrotasks : Sometimes tasks are deleted when a schedule update is made. This means that there are Macrotasks in Fuzor that do not exist in the updated XML. Depending on whether these tasks are linked to microtasks or have objects assigned, there are a few different things that we may be expecting to happen. Below are some potential expectations and the best workflow associated with that result.

The best workflow to ensure these tasks are deleted is an XML update. When Using Merge By ID there is an option to delete tasks with assigned objects. Macrotasks that have no objects assigned will always be deleted if not included in the XML update. the Logic Relationship the best linking method when there are many deleted tasks in the XML as Children are always deleted with their parents.

The best workflow to retain animations when there is a potential for deleted macrotasks with objects assigned or linked microtasks is Column Mapping. Column Mapping never deletes tasks in your project. Either Task Linking Method will retain the start and end date of the microtask when its macrotask is deleted

Replaced Macrotasks and Identifier changes : When using an XML Fuzor uses a specific Identifier depending on source of the XML. When Column Mapping the User needs to select an Identifier using the tool. The Indentifier needs to be unique and consistent for the same task in order to conduct a schedule update properly.

It is possible but unlikely that a schedule update will have new Identifiers for all tasks in schedule. Normally the reason behind an ID change is because a task was deleted in the authoring software and then recreated, with a new ID. In order to identify changes to IDs it is important to know which software uses what ID as a unique Identifier.

• Microsoft Project : Unique ID

• Primavera P6 : ID

• Asta Powerproject : Task ID

Using Column Mapping it is possible to select a different Identifier that may be consistent, and even use it to update the Identifier that is needed to do an XML update if this is necessary for other reasons. If tasks are mapped properly either Task Linking Method is effective to update microtasks accordingly.

For Example WBS naming conventions for Primavera P6 use the project ID for the WBS IDs which means that these may change when a new project is created. Using column mapping and the Task Name as an identifier you can update the WBS IDs so that data can be synced with an XML update.

Changes to Calendars the Data Date and Resources: Both Calendars and the Data Date can effect dates and durations of tasks in the project. If these are not imported or updated during a schedule update it is possible that the dates in your Fuzor Project are inconsistent with that of your authoring software.

Resources may effect cost calculations. If these are not imported or updated during a schedule update it is possible that the costs in your Fuzor project are inconsistent with that of your authoring software.

An XML update is needed to update or import new Calendars and Resources, Update the Data Date, or change resource and calendar task assignments and allocation. However, Column Mapping can be used to update incorrect costs directly and handle them as edited total costs.

Changes to Activity Codes : blash balsh XMLS are needed for the activty codes

Manually Schedule Tasks : If manually schedule tasks is enabled Fuzor does not respect any logic in the schedule. This means that neither Task Linking Method will update Microtasks that are linked to updated Macrotasks.

If substantial lag is introduced early in critical path the result would be an project where Microtasks are occuring far before Macrotasks that they are linked too.

There are a few common reasons why a user might enable Manually Schedule Tasks

• Manually schedule tasks was enabled for a specific task in the authoring software and the setting is needed in the Fuzor Project to ensure that the date matches for the task. This can be resolved by ensuring that the authoring software has proper logic. with respect to DCMA guidelines? CHECK THAT ONE

• Schedule data was exported from the authoring software before conducting a proper schedule update and there is invalid data in the schedule. This can be resolved by running a schedule update before exporting the XML.

• The user prefers having Manually Schedule Tasks enabled when scheduling in Fuzor. This can be resolved by learning to use Fuzor without Manually Schedule Tasks enabled.

Fuzor does not support schedule updates for Microtasks when Manually Schedule Tasks is checked. The above issues need to be resolved in order for a Task Linking Method to be effective.