Duration, task dependencies, constraints, and slack can all affect the way Microsoft Project schedules.

Duration

A task's duration is the total period of working time it takes to complete the task, which can be entered in minutes, hours, days, weeks, or months. Estimating and entering accurate durations is one of the most important things you can do to create a useful schedule. A task's duration is used to calculate start and finish dates for the task and, after you assign resources, the amount of work on the task.

When you enter a task without a duration, Microsoft Project calculates the duration based on start and finish dates of the task and flags the duration as estimated, indicated by a question mark after the duration. Estimated durations are not calculated differently than normal durations. They merely alert you to durations calculated from other information about a task. All durations are marked as estimated until you enter a number for the duration. For example, Microsoft Project displays 2d? if you enter a start date of September 1 and a finish date of September 2. But if you enter 3d for the duration, the question mark disappears. You can also signify an estimated duration by typing a question mark after a duration you enter. You can eventually change a task's estimated duration to another number or remove the question mark as you receive more accurate information.

Two types of durations are used in Microsoft Project; they are calculated differently:

• Durations   The amount of working time it takes to complete a task. By default, durations are represented in days, but you can enter durations as minutes (min), hours (hr), weeks (wk), or months (mo), as well. When you enter a duration in days, Microsoft Project schedules the task based on the default number of working hours per day, eight hours. Along with other task information, such as calendars and resource assignments, the duration determines the task's start and finish dates.

Microsoft Project starts the task at 8:00 A.M., the default start time indicated on the Standard project calendar, and then counts the number of hours in the task's duration to arrive at the finish date and time for the task. Microsoft Project calculates the duration of tasks by counting the amount of working time between the task's scheduled start and finish dates, not counting time between splits on a task. For example, a task begins on Friday, September 2, and has a two-day duration. A two-day duration equals 16 hours. Using the default settings on the Standard project calendar (eight working hours per day), weekends are nonworking time and each working day is eight hours long. The finish date of the task is calculated as Monday, September 5 at 5:00 P.M.

• Elapsed durations   These affect a task's start and finish dates and times differently than durations or estimated durations. Elapsed durations ignore working time and nonworking time in all calendars and resource assignments. They schedule tasks 24 hours a day, seven days a week until they are finished. Elapsed durations also ignore the schedule settings in the Options dialog box when determining duration, calculating each day of elapsed duration as 24 hours instead.

Elapsed durations are useful for processes that can't stop once started, such as the period of time it takes cement to cure after it is poured. You designate an elapsed duration by entering an "e" before the duration unit, for example, 4ed for four elapsed days. Summary tasks don't display elapsed durations because they summarize the total span of working time from the start of the earliest subtask to the end of the latest subtask.

You can also split a task into portions with different durations if it can't be completed without an interruption. The task's duration is still the value for the whole task, but each piece of the split task is scheduled incrementally. There are two situations where duration is affected by splitting the task:

• If you split a task with an elapsed duration, the duration is recalculated covering the elapsed duration from the start of the first part of the task to the finish of the last part of the task.
• If you split a task with a fixed duration, the duration is recalculated based on the start of the first part of the task to the finish of the last part of the task, not counting any nonworking time or the period of time between the split portions of the task.

Task dependencies

A task dependency is the relationship or link between two tasks in which the start or finish of the successor task depends on the predecessor task's start or finish. When you create a link between two tasks, Microsoft Project calculates the successor's start and finish dates (based on the predecessor's start or finish), the dependency type, the successor's duration, and any resource assignments.

In Microsoft Project, you can link predecessors and successors with four types of task dependencies. The nature of the dependency between the predecessor and successor determines the dependency type to use. You can also create task dependencies between tasks in different projects.

Task dependency	Example	Description
Finish-to-start (FS)		Task (B) cannot start until task (A) finishes. For example, if you have two tasks "Construct fence" and "Paint fence," "Paint fence" can't start until "Construct fence" finishes. This is the most common type of dependency.
Start-to-start (SS)		Task (B) cannot start until task (A) starts. You have two tasks "Pour foundation" and "Level concrete." "Level concrete" can't begin until "Pour foundation" begins.
Finish-to-finish (FF)		Task (B) cannot finish until task (A) finishes. For example, if you have two tasks, "Add wiring" and "Inspect electrical," "Inspect electrical" can't finish until "Add wiring" finishes.
Start-to-finish (SF)		Task (B) cannot finish until task (A) starts. This dependency type can be used for just-in-time scheduling up to a milestone or the project finish date, to minimize the risk of a task finishing late if its dependent tasks slip. If a related task needs to finish before the milestone or project finish date, but it doesn't matter exactly when (and you don't want a late finish to affect the "just in time" task), you can create a SF dependency between the task you want scheduled just in time (the predecessor) and its related task (the successor). Then, if you update progress on the successor task, it won't affect the scheduled dates of the predecessor task.

Constraints

When you need to control the start or finish date of a task, you can add a constraint to the task. Flexible constraints work with task dependencies to make a task occur as soon or as late as the task dependency will allow. For example, a task with an ASAP constraint and a FS dependency will begin as soon as the predecessor task finishes.

Constraints with moderate scheduling flexibility will restrict a task from starting or finishing before or after a date you choose. For example, a task with a Start No Later Than (SNLT) constraint for June 15 and a FS dependency to another task, can begin any time its predecessor is finished (up until June 15), but it can't be scheduled after June 15.

Inflexible constraints override any task dependencies and restrict a task to a date you choose. For example, a task with a Must Start On (MSO) constraint for September 30 and a FS dependency to another task will always be scheduled for September 30, no matter whether its predecessor finishes early or late.

If a task constrained to a date has a predecessor that finishes too late for the successor to begin on the date specified in the constraint, negative slack can occur. To specify that constrained tasks with negative slack are scheduled according to their task dependencies, rather than the constraint dates, on the Tools menu, click Options, and then click the Schedule tab. Clear the Tasks will always honor their constraint dates check box.

Slack

Critical tasks have no slack and noncritical tasks do have slack, meaning they have buffer time available, so their start or finish may be delayed without affecting the start of any successor tasks. Free slack is the amount of time a task can slip before it delays another task. Total slack is the amount of time a task can slip before it delays the project finish date. When the total slack is negative, the task duration is too long for its successor to begin on the date required by a constraint, or a successor has actual start and finish dates, or actual durations, entered which conflict with the constraint date.

If a noncritical task consumes its slack time, it usually causes its successor to use some or all of its total slack time. The task becomes a critical task and causes its successor tasks to become critical as well, once the successor's total slack equals zero.

Total slack is calculated by comparing the minimum of the difference between the late start date and early start date and the difference between the late finish date and early finish date. The smaller of the two differences is the total slack.

You can adjust the criteria that define a critical task by specifying how little slack it can have before being considered critical. You can set this value in the Tasks are critical if slack is less than or equal to box on the Calculation tab of the Options dialog box (Tools menu).

Note  When you display multiple critical paths, Microsoft Project changes the calculation of the critical path so that any task without a successor will have its late finish date set to its early finish date, which gives the task zero slack and thus makes it critical. In contrast, for a single critical path, Microsoft Project sets the late finish date of a task without a successor to the project's finish date, thus giving the task slack and making it noncritical.