As an alternative to manually entering task start and end dates and scheduling tasks in line with the project or based on lead time offsets, iBE.net now supports task constraint based scheduling. This covers both forward and backward scheduling of tasks within a project on the basis of following constraints to both planned start or finish date:

• Task must start on or must finish on a specific date
• Task must start no later than, or finish no later than a specific date
• Task must start no earlier than, or finish no earlier than a specific date
• Task must start after another task has finished, perhaps with a "lag". This is known as a "finish-start" dependency
• Task must start after another task has started, again with optional lag. This is know as a "start-start" dependency
• Task must finish after another task has started, with optional lag. This is a "start-finish" dependency
• Task must finish after another task has finished, with optional lag. This is a "finish-finish" dependency

The "lag" if positive represents the number of days gap between the two dependent tasks. For example if task #1 finishes November 25th 2015 and there is a two day lag on a finish-start dependency to task #2, then task #2 will start on November 30th. If the lag is negative this means task #2 starts some days prior to the finish of task #1.

With no lag and a finish-start dependency the successor task start is one day after the predecessor's finish date. A two day lag results in a start date of November 30th because November 28th, the result of adding 2 day lag to one day after November 25th, is a weekend / Saturday. November 30th is the first working day (Monday) after November 28th

Forward scheduling starts at the project start and schedules the earliest possible start date for each task based on either the project start, superior task start (see scheduling up/down below) or the latest constraint impacting the task's start date. Each task's earliest possible end date is normally its early start date plus duration, in work-time only. For example if a project starts November 2nd 2015, and there are no dependencies than task #1 will also start November 2nd, and finish November 6th if task #1 is 5 day duration. Task #2 if it has a finish-start dependency from task #1 will consequently be scheduled to start on November 9th (the Monday after a weekend).

A task's planned early start and finish dates represent the soonest possible that a task can be completed, meeting all constraints but not assuming any restrictions in available capacity of the resources utilized. If the project's scheduling method is set up to schedule forwards, then each task's early start and finish dates are adopted into the task planned dates for reporting purposes.

Backward scheduling on the other hand works backwards from the project planned finish date and schedules the latest possible end date for each task based on the project end, or based on subsequent or successor tasks coming after which have been scheduled. Each task's latest start date is normally its late finish date minus the task's duration in work-time only, also considering any constraints on that task's start date. For example if task #2's late finish date is November 26th and it is a two day task, then task #2's late start will be calculated as November 24th and task #1's late finish date as November 23rd, or the earliest constraint less one day.

A task's late planned start and finish dates simply indicates the latest possible time a task can be started and completed without impacting the overall project schedule. If the project scheduling method is set up to schedule background then each tasks late start and finish dates are used as planned dates for reporting purposes.

Any task where early start = late start and early finish = late finish (i.e. where the dates calculated from forward or backward schedule are the same) has no "float" and is considered to be part of the critical path of that project.

Scheduling down the project / task hierarchy means that sub-tasks within any task-list are automatically constrained to start on or after the superior task or task-list start and to finish on or before the superior task end date. In essence the higher level tasks or task-lists are scheduled first and then sub-tasks are scheduled within the boundaries of their superior task. This happens down through any number of project task "layers" in the hierarchy.

Scheduling up the project / task hierarchy means that superior tasks or task-lists automatically stretch in duration to accommodate the start and end dates of their sub-tasks. In essence the sub-tasks are scheduled first and superior task start and end dates are adjusted if required to accommodate the earliest/latest sub-task. This happens up through any number of project task "layers" and is pretty much how Microsoft Project works in practice also.

You can control whether you want to schedule your project using up vs. down scheduling the scheduling method linked to your project type.

A couple of additional scheduling concepts are currently supported by iBE.net's project and task scheduling engine, and a couple are planned for the future:

1. The scheduling method in iBE.net can be set up to not allow dates in the past. While this does not impact actual dates or planned start dates for tasks which have already started, if you do not wish to allow dates in the past then any tasks which has not yet started but which should have started in the past will be planned to start today, and any tasks which are scheduled to finish in the past will be adjusted to finish today (though this is unlikely given that finish date is calculated as start date plus task duration)
2. The scheduling method in iBE.net can be also be set up with a fixed planning horizon. This is an interval of time normally a few days when you do not want task dates to move around or to get rescheduled, perhaps because you have already locked down your resourcing and commitments to your staff on pending tasks. If you define a fixed planning horizon then any tasks which start during this short-term horizon will not get rescheduled even if their dates would have otherwise changed as a result of rescheduling

iBE.net can schedule a task's duration on the basis of either fixed effort or fixed utilization.

• Fixed effort scheduling means that the task duration and effort are both set and the resource utilization % is adjusted to accommodate the amount of remaining work over the course of the task's remaining duration.
• Fixed utilization means that the task duration and utilization are both set and the remaining work is automatically adjusted according to how much effort can be expended by the resource over the remaining task duration assuming they apply themselves to the task at the utilization specified %
• iBE.net also supports finite utilization which is essentially flexing or adjusting utilization and keeping effort fixed up to the maximum utilization permitted for that resource on the project and then flexing or adjusting the effort beyond that. This means the resource's utilization % does not go over the maximum.

iBE.net does not currently account for resource requirements on other tasks or projects or "level loading" during the scheduling calculation. We have a resource planning tool to assist planners in doing this however our scheduling engine assumes - once fixed effort or fixed utilization strategies mentioned above are considered - infinite available capacity across all projects.