You are here
Project.net has two kinds of leaf tasks – manual and automatic. Automatic tasks (also called calculated tasks) are automatically scheduled. They should be used when you want the project.net workplan scheduler to automatically set the start and finish dates of a task, based upon its work and duration, its constraints, and its dependencies on other tasks. In this article, we're going to talk about how automatic tasks are scheduled by the scheduler.
NOTE: This article is only going to discuss tasks that
- Do not have assignments; we'll talk about scheduling tasks with assignments in another article
- Are leaf tasks; we'll discuss summary tasks is another article
In New/View/Edit Task, the Dates section shows Calculated Scheduling if the workplan properties allow automatic tasks. If that' the case, then tasks in that workplan are automatic, unless the user checks the checkbox to force it to be manually scheduled.
1. Scheduling a Workplan
At its simplest, the job of the workplan scheduler is to schedule each automatic task in a project workplan, giving each task a scheduled start date and a scheduled finish date so that the workplan finishes as soon as possible, and so that each task
- Is scheduled for a period appropriate to its work and duration, taking holidays and such into account
- Starts no earlier than the workplan's start date. That's either the Start Scheduling On date (set in Workplan Properties > Workplan Details), or if that's not set, then the project's Start Date (set in Project Dashboard > Edit Properties), or if that's not set, then the current date
- Satisfies its constraints, and those of its parent summary tasks (if they don't conflict with its own constraints), if any. A task constraint requires that the task must start and/or finish no earlier than, no later than, or on a specific date. However, a constraint will not be satisfied if it would force a task to start earlier than the workplan start date. More information about constraints can be found in the article on Task Constraints.
- Satisfies all of its dependencies, and those of its parent summary tasks, if any. Each dependency requires that a task must not start or finish until some other task starts or finishes, with an optionally specified lag. However, a dependency is not satisfied if it would force a task to violate its constraints.
- Is not unduly stretched out by being scheduled during a period of company or project-wide holidays or shorter-than-usual work days.
- Starts as soon as possible, after taking into account all the considerations above. Note: In the future, we also expect to allow individual tasks to start as late as possible, after taking into account all the other considerations above.
There will be additional requirements for tasks which have assignments, especially, in the future, when we add support for leveling.
As the user makes changes to the work and duration of tasks, or to dependencies or constraints, the schedule may no longer make sense. For example, suppose that task B was dependent on task A and was scheduled to start immediately after A finished. However, if the work and duration of A increased, then B would need to start later as well. This is not done automatically; the user must choose Reschedule to explicitly reschedule the workplan. Explicit rather than automatic rescheduling allows us to support very large workplans efficiently.
Note: In the future, we are likely to support automatic incremental rescheduling -- after every change, or small set of changes, the scheduler will, as an option, automatically change the schedule, similar to what Micosoft Project supports.
2. Duration and Scheduled Duration
Each task in Project.net may have
- a duration – which we also call a specified duration, or an expected duration – the amount of time the task is expected to take. For automatic tasks, this is set by the user in conjunction with the task's work, and is discussed in more detail in the article on Work, Duration and Calculation Type.
- a scheduled duration -- the # of project working days between the scheduled start and finish dates. For automatic tasks, the scheduled start and finish dates are generally set by the workplan scheduler.
Project working days are specified in the project's
- Work Week calendar, which specifies which days of the week are working days, and its
- Individual Dates calendar, which specifies project/company-wide holidays, and dates where the working day is specified to be longer or shorter than usual.
Both are accessible through the project workplan's Workplan Properties.
The Project.net workplan scheduler generally schedules an automatic task so its scheduled duration is the same as its specified duration. However, when a duration is specified, there are two cases where the specified duration and the scheduled duration may not be the same:
- Constraints may force a task to be scheduled in fewer working days than its specified duration.
- A fixed-work or fixed-units task is scheduled to take as long as necessary for the task's work to be completed. In some cases (e.g. if there are specific days when the company works an unusual schedule), this can cause the scheduled duration to be longer or shorter than the duration specified.
We'll explain these cases in more detail below, but it means that for automatic tasks, the task's duration is best thought of as an expected duration, not a guaranteed duration.
If a task without assignments has a specified duration, and if its constraints do not force it to take less time than expected, then its scheduled duration is guaranteed to match its specified duration when either
- The task is fixed-duration
- The task has a duration, but no work has been specified
- The duration has been explicitly set so that it is shorter or longer than would usually be expected for the specified work
3. Task Constraints and Scheduled Duration
Constraints may force a task to be scheduled in fewer working days than its specified duration.
Tasks in Project.net may have separate start and finish constraints. Not all combinations of these are legal, but, for example, we do allow a task to be required to start no earlier than a particular date, and to finish no later than another date, which can potentially cause tasks to take fewer days than expected. This is discussed in more detail in the article on Task Constraints.
For example, if a 24 hr work / 3 day duration task is required to start no earlier than Monday and finish no later than Tuesday, then its scheduled duration will be 2 days instead of 3 days. Note: This means that 12 hrs of work will need to be done each day, which might suggest that two people need to be assigned to it, or that the constraints need to be re-examined.
4. Work and Duration
In a fixed-work task, changing work changes duration, but changing duration does not change work. If we initially set a fixed-work task without assignments to take 40 hrs, its duration will generally be set to 5 days, by default. This is based on the average # of hours expected to be done on the project every day, which by default, is 8 hrs/day. This is specified in Workplan Properties > Work Week.
After setting work, the user might
- Explicitly change the task's duration, for example,
- to 10 days, so the ratio of the work to duration will be 40 hrs / 10 days, or 4 hrs/day, which is shorter than the usual average of 8 hrs/day.
- to 4 days, so the ratio of the work to duration will be 40 hrs / 4 days, or 10 hrs/day, which is longer than the usual average of 8 hrs/day.
In either case, the workplan scheduler will schedule the task within the specified duration (10 days in the first case, 4 days in the second case). This can force the task to be scheduled (for example, in the second case) during a period where fewer hours are available than the number of hours of work required for the task.
- Leave the task's duration unchanged, so that the ratio of the work to the duration – e.g. 40 hrs / 5 days, or 8 hrs/day – matches the usual average of 8 hrs/day
In this case, the workplan scheduler will schedule the task to take as long as necessary for that work to be completed. In general, this should the same as the duration. However, during periods where the company or project has shorter (or longer) days than usual, a fixed-work (or fixed-units) task may take more (or less) time than its specified duration.
Suppose a 24 hour work / 3 day duration task is ready to start on Monday. However, the project's Individual Dates calendar has Tuesday and Wednesday as company or project-wide 4-hour half days. Consequently, work on the task will take 8 hrs on Monday, 4 hrs each on Tuesday and Wednesday, and then 8 hrs on Thursday, so the scheduled duration will be 4 days instead of 3 days.
5. Scheduling Tasks without Duration
An automatic task that does not have either a duration or work is still scheduled. This ensures that its constraints and dependencies are enforced, which will affect the tasks which depend on it, and therefore the overall schedule. Automatic tasks without durations are scheduled as follows:
- If a task is specified to be a milestone, then its work and duration are assumed to be zero.
- Otherwise, the scheduler will use an assumed scheduled work value for the task's work. The assumed scheduled work value for a project can be set in Workplan Properties > Workplan Details. It is initially zero, but can be changed, for example, to 8 hours, which is common in some other project management systems.
Project.net will then calculate a value to use for the task's duration by dividing the assumed scheduled work by the average hrs per day from Workplan Properties > Work Week. For example, 8 hours (the assumed scheduled work) divided by 8 hrs/day (the average hrs per day) would generate a duration of 1 day. The scheduler will then schedule the task based on this work and duration, as described in the previous sections.
Note that the assumed scheduled work value and calculated duration are ONLY used by the scheduler to schedule tasks which are not milestones, and which have no duration specified. They are NEVER used to change the value of work or duration in the task itself, which remain unset.
6. Delaying Tasks
Ordinarily, tasks will be scheduled as soon as possible, taking workplan start, constraints and dependencies into account. However, the scheduler will consider delaying tasks without assignments in two cases:
- In cases where the scheduled duration is guaranteed to be the same as the task's specified duration (as described above), the scheduler will consider delaying the task if the work to be done exceeds the hours available within the specified duration, at the time when it is ready to be scheduled.
Suppose a 16 hour work / 2 day duration fixed-duration task is ready to start on a Monday. However, the project's Individual Dates calendar specifies Monday to be a company or project-wide 4-hour half day. If the task is scheduled on Monday and Tuesday, then only 12 hours are available, instead of the 16 needed. So the scheduler will consider delaying the task so it instead starts on Tuesday.
- The scheduler will consider delaying a task if the number of calendar days it takes is large relative to its expected duration – generally, if it is more than 2 times as large. Note: in the future, we may allow a user to change this ratio
Suppose a 16 hour work / 2 day duration task is ready to start on a Friday. The following week is specified to be a company or project-wide holiday, so if the task starts on the Friday before the vacation, it won't be done until the Monday after the vacation, resulting in a calendar duration of 9 days. This is too long relative to the expected duration of 2 days, so the scheduler will consider delaying the task so it start on the Monday right after the vacation.
The scheduler is somewhat more lenient for a short task, so if
- the expected duration is < ½ day, it can take up to a day
- the expected duration is between ½ day and a day, it can take up to 2 calendar days
- the expected duration is between 1 day and 2 days, it can take up to 4 calendar days, which allows it to straddle a weekend
A task can only be delayed within limits:
- Delaying a task may push out the project's finish date, depending on the task's slack. In particular, if a task on the critical path is delayed n project working days, it will push out the workplan finish date by n project working days.
The cumulative delay to the finish date may not exceed 10% of the workplan's length, relative to its length when no delays are allowed. So, some tasks may be delayed, while others may not, because doing so would make the project too long.
- Tasks that have a lot of slack could potentially be delayed for a significant period of time without affecting the project finish date at all. However, the scheduler will never delay a task for more than 4 weeks
Ellis S Cohen
(last revised) Mar 2015