Project Manager Terms & Definitions
SyncForce project & workflow manager is based on Stage-Gate principles. This article explains the terms used.
Stages
A Stage is a structured phase in a Stage-Gate project during which a defined set of Tasks is executed to deliver specific outcomes. Stage planning is based entirely on the planning of its underlying Tasks—meaning the start and end dates of the stage are automatically calculated from the earliest start and latest end of the tasks within it.
Stages represent the execution layer of the project and are always followed by a Gate, where progress is reviewed and a go/no-go decision is made for the next stage.
Tasks
A Task is a unit of work within a Stage of a Stage-Gate project. It defines a specific activity required to progress the project and contributes to achieving one or more Deliverables. Tasks are typically assigned to roles or individuals and are used to track progress, calculate critical paths, and assess gate readiness.
Each Task has the following parameters:
-
Workload: The estimated effort required to complete the task (in hours).
-
Planned Duration: The scheduled time span to complete the task (in calendar days).
-
Minimum Duration: The shortest achievable time to complete the task, based on historical data or best-case experience.
Best practice for Task naming:
-
Start each task name with a verb to clearly indicate the action required.
Examples: “Write Project Brief”, “Validate Label Design”, “Submit Regulatory Dossier”.
Task–Deliverable relationship in SyncForce:
-
Every Task must lead to at least one Deliverable.
-
One Deliverable may result from multiple Tasks.
Gates
A Gate is a formal decision point in a Stage-Gate project where progress is reviewed and approval is given to proceed to the next stage. Gates typically involve assessing the status of deliverables, risks, and overall readiness. Each gate has a defined timing and can be evaluated against multiple reference dates to track performance and scheduling accuracy.
Gate timings
Each gate can be evaluated using several reference points:
- Gate Target Date: The currently configured gate date, which can be:
- Stage-driven (based on planned end of the current stage)
- Fixed (manually entered)
- Aligned to a recurring gate meeting (e.g. monthly board review)
- Relative to a key milestone (e.g. “16 weeks before first shipment”)
- Gate Baseline Date: The planned gate date at the moment the Baseline Gate was passed (often Gate 1 or 2). These dates are frozen and used to assess whether the project is tracking against the original plan.
- Gate Commited Date : The planned gate date at the moment the last gate was passed. For example, when Gate 3 is passed, the committed dates for Gates 4, 5, and 6 are frozen. These dates are updated and re-frozen at each subsequent gate passing.
- Gate Forecast Date: The latest predicted end date of all tasks in the stage—i.e., the earliest possible date the gate could be passed based on task progress. This reflects whether acceleration or delay is likely, independent of fixed scheduling constraints.
- Gate Actual Date is the date the gate is truly passed. It is the authoritative reference for evaluating past performance.
On Time status logic for gates
The status of a gate—whether it is On Time, At Risk, or Critical—is determined by comparing the Planned Gate Date (as the target) with two system-calculated values: the Forecast Gate Date and the Earliest Gate Date (based on the Minimum Critical Path of tasks in the current stage).
-
🟢 On Time: The gate is considered on time if the Planned Gate Date is on or after the Forecast Gate Date—meaning the current planning suggests that all stage tasks will be completed before or on the planned gate date.
-
🟠 At Risk: The gate is at risk if the Planned Gate Date is before the Forecast Gate Date, but still after the Earliest Gate Date—indicating that the current plan suggests a delay, but there is still potential to accelerate and meet the planned gate.
-
🔴 Critical: The gate is in critical status if the Planned Gate Date is earlier than the Earliest Gate Date—meaning that, even under best-case (minimum duration) conditions, the gate cannot be passed on time.
Deliverable
A Deliverable is a concrete outcome or result of one or more Tasks within a Stage. Deliverables serve as evidence that certain work has been completed and can be used to support Gate reviews and approvals. Deliverables may be documents, specifications, data entries, or any other tangible result.
Deliverables are linked to tasks in project templates and form the basis of quality control, compliance, and decision-making at Gate points.
Best practice for Deliverable naming:
-
Use clear, noun-based names without verbs to indicate the object being produced.
Examples: “Project Brief”, “Packaging Design”, “Final Recipe”, “Label Artwork”.
Deliverable Planning
Term | What It Suggests |
---|---|
Deliverable Forecast Date | System-calculated projected date, bases on the latest planning |
Deliverable Target Date | User-entered planning goal (optional Deadline, is hard non-negotiable cutoff) |
Deliverable Earliest Date | Earliest realistically possible (based on Minimal Critical Path) |
Deliverable Actual Date | System-stamped or user-entered |
On Time Status Logic for Deliverables
The status of a deliverable—whether it is On Time, At Risk, or Critical—is determined by comparing the Deliverable Target Date with two system-calculated values: the Deliverable Forecast Date and the Deliverable Earliest Date (based on the Minimum Critical Path).
-
🟢 On Time: The deliverable is considered on time if the Target Date is on or after the Forecast Date—meaning the current plan predicts the deliverable will be ready by the time it’s needed.
-
🟠 At Risk: The deliverable is at risk if the Target Date is before the Forecast Date but still after the Earliest Date—indicating that, while the plan suggests a delay, there may still be a chance to meet the target through acceleration.
-
🔴 Critical: The deliverable is in critical status if the Target Date is earlier than the Earliest Date—meaning that, even under best-case (minimum duration) conditions, the deliverable cannot be completed on time.
This logic provides a forward-looking view of timing risk and helps teams prioritize effort, escalate bottlenecks, or adjust expectations early.