Project Execution and Task Management
Scheduling, Dependencies, and the Timeline
Core concepts
Dependencies use four predecessor types - Finish-Start (FS), Start-Start (SS), Finish-Finish (FF), Start-Finish (SF) - each with optional lag. Task constraints (As Soon As Possible, As Late As Possible, Start No Earlier Than, Start No Later Than, Finish No Earlier Than, Finish No Later Than, Must Start On, Must Finish On, Fixed Dates) override dependency logic. The project Schedule From setting plus each task's scheduling mode determines whether ASAP or ALAP logic applies.
Duration types - Simple, Effort Driven, Calculated Assignment, Calculated Work - decide what recalculates when you change duration, work, or the number of assignees. The project Update Type (Automatic, Manual, Change Only) decides whether the timeline recalculates immediately or waits for a manual recalculation.
The critical path is the longest path through the plan; slippage there moves the project completion date.
Traps
- Fixed Dates and Must-Start/Must-Finish constraints ignore predecessor changes.
- SF dependencies are rare but appear in questions; they mean the successor finishes before the predecessor starts.
- With Update Type set to Manual, dependency edits appear not to work until you recalculate the timeline.
- Changing a predecessor does not move a task constrained to Start No Earlier Than if the constraint still allows the old date.
Worked example
Task B has an SS predecessor to Task A with 2 days lag. A starts Monday. B cannot start before Wednesday (Monday + 2 days of lag), and B's own duration runs from there. If B also carries Start No Earlier Than Thursday, Thursday wins - constraints always beat dependency math.
Project Execution and Task Management
Core concepts
During execution the team works the plan: members update status, percent complete, actual hours, and comments from the task's Updates tab or My Work. The Work On It button assigns the task to the current user if unassigned and sets the status to In Progress.
Statuses map to an equated status (New, In Progress, Complete), which is what reporting and project roll-ups actually measure. Custom statuses you create in Setup display a label but equate to one of those three under the hood - a frequent exam distinction.
Execution also covers task approvals, issues raised on tasks, documents, subtasks, and predecessor completion, which releases successors to start. Project percent complete derives from duration, not from a count of closed tasks.
Traps
- Marking every task complete does not complete the project; someone must set the project status.
- Parent task percent complete is calculated from children and cannot be typed in.
- Changing a task's status to Complete does not automatically adjust planned hours or actual hours.
- Work On It only affects the person clicking it and does not change assignments on already-assigned tasks.
- Commit dates, planned completion dates, and projected completion dates are three different fields.
Rule of thumb
For any execution scenario, ask three questions: which object is being updated (task, issue, project), who owns the status change, and whether a calculated field will overwrite the manual value. Task percent complete on a parent, project percent complete, and project condition are all calculated or manually owned by different roles.