| FF | Free Float | The number of days that a Task can be delayed until a successor task is affected. |
| TF | Total Float | The number of days that a Task can be delayed until the project end date is delayed. |
| FS | Free Slack | =Free Float |
| TS | Total Slack | =Total Float |
| Critical Task | A task with total float =0 | |
| CP | Critical Path | A path connecting a series of critical tasks via their relationships. A schedule may have more than one critical path. |
| ES | Early Start | Gantt chart calculated for a task. |
| EF | Early Finish | Gantt chart calculated. |
| LS | Late Start | Gantt chart calculated. |
| LF | Late Finish | Gantt chart calculated; Note: when TF=0 then EF=LF |
| F-S | Finish - Start | Relationship between a task’s Start and its preceding task’s Finish. |
| S-S | Start - Start | Relationship between a task’s Start and its preceding task’s Start. |
| F-F | Finish - Finish | Relationship between a task’s Finish and its preceding task’s Finish. |
| Lag | Duration (days) overlaid on top of the relationships above. | |
| Baseline | Captured off the schedule at a point in time, for comparison with the schedule to date (or another baseline at another point in time). |
| Considered Supplier | The process of selecting a supplier for a deliverable typically starts with a list of suppliers that could be considered for a contract. It may go through several stages, from REI ( request for expression of interest), to RFQ or RFP (Request for quotation or Proposal) to a contract. | |
| intent to award | At the end of the supplier selection process the status of a system is awarded: typically the PM, at that time, has made a selection unofficially and is now in the process of negotiations with a supplier, leading to a “draft” | |
| draft | At the end of the negotiations, a draft contract is generated, that may go through legal review etc. | |
| Approved and finalized | In some corporate procedures there is a two-step contract approval phase: approval ( by the PM or the contracts administrator etc.) and someone higher in the corporate hierarchy ( such CEO, VP Finance, etc.) who “finalizes” with a signature |
| RACI Matrix | Universal Program Management concept. (Responsible, Accountable, Consulted and Informed), sometimes just called Responsibility Assignment Matrix (RAM). In a way, the ProjectContexts Ownership Permissions concept is similar. | |
| Owner Permissions |
Sometimes called Dynamic Permissions. The Owner permission matrix organizes what an Owner can do, and which owner needs to be notified of. The matrix itself can be edited by the PM. It is different from the role permissions matrix which is set at the corporate level and is valid across all projects. |
|
| PM | Project Manager | Assigned to a Project by the PMO. (Project Management Office) |
| PO | Project Owner | Essentially the Project Manager. |
| SO | System Owner | A System Owner reports to higher System Owner or to the Project Owner, following the WBS. |
| TO | Task Owner | A task Owner reports to a System Owner or to the Project Owner directly if the relevant task is a Project Task. |
| CO | Context Owner | |
| IO | Issue Owner | |
| AO | Action Item Owner |
In ProjectContexts, a top down view is composed of project systems, where each “system” could be composed of other (sub-) systems or tasks. A " system" could be a “digestive system”, a “work package”, a “summary task” as defined in other softwares, a “Phase” etc. In a work break down structure (WBS), systems essentially are the elements of a project over and above “tasks”. See also Project Structure.
Types of systems
| Internal Systems | Systems for which your company has a contractual obligation, either as a Customer or as a supplier. For example the delivery of a motor to your customer, governed by contract | |
| External Systems | Systems for which there are (typically) no contractual obligations, but obligations nonetheless. For example, to meet permit requirements. The Customer and/or supplier could be the local municipality fire department. |