Planned, Expected and Actual

Planned, Feasible and Actual

 * Planned dates and data hold the original dates and data (start end, duration, cost etc.) put in the planner.
 * Actual dates and data hold the final actual dates and data as recorded by the team on task/action/gate start/completion.
 * Feasible dates and data are automatically and continuously updated based on how the project progresses.
 * Feasible Start Date is the earliest possible date the gate or action can start (based on prior dependencies).
 * If there is no precedence or dependencies this is equal to the planned start date.
 * If there is a precedence then this is the earliest start date possible, after the completion of the precedence.
 * Feasible End Date is the expected completion date.
 * This is the "Feasible Start Date + Planned Duration".
 * Feasible Window is the length (in days) of the available time window to complete the action/gate.

In the ideal scenario, where each item is completed on-time and exactly as planned, all three are the same. In the real world however this is rarely the case.

Example
Consider the project shown in the table below comprised of three top level gates, six sub-gates and 12 actions.

Planning Stage
Settings and Assumptions


 * There is a same level precedence for each Gate and Sub-gate. No precedence is set for the actions within a gate, however the plans calls for them to run sequentially.
 * Monday, Tuesday, Wednesday, Thursday and Friday are workdays. Weekends include Saturday and Sunday. Holidays include December 25th, July 4th, January 1st, the fourth Thursday of November, the first Monday of September, and the last Monday of May. This is set through the Work Days Scheduler interface, which can be found in Manage Repository under the Repository Settings.
 * Each Action has a duration of three days.
 * Actions start at the beginning of the workday assigned (i.e. first thing in the morning) and end at the end of the workday assigned.  For example a two day action starting on January 1 would be completed on January 2 (e.g. all day on day 1 and all day on day 2).
 * Action 1 starts in January 2, when completed Action 2 starts and so forth.
 * No lag time between gates and actions.

Planned Dates
Based on the above settings and assumptions, including weekends and holidays, the planned dates would be as follows:

Planned Costs
Planned costs can be automatically included/calculated based on the resources assigned to each action. See also DFR Resources, which can be found in Manage Repository under the Repository Settings.

For this example we will only consider labor costs and ignore other cost variables. From a labor prespective assume the following resources are assigned to the project.

These are defined in team resources as follows:

The allocation to tasks is as follows:

From the inputs as defined above then the planned costs would be:

Planned Resource Loading
In this example the only resource used was personnel. Based on the prior entries each team member's utilization is as follows. Note that, in this case, overallocation exists for the two managers since they also serve on the CUS Teams.



Action 1
Assume that the project got started a day late, i.e. the initiating action (A01) got started on Jan-3 instead of Jan 2.

Then on Jan-3 the DFR Plan would then transform as follows:



Resource Conflicts

The late start of A01 causes a resource conflict as shown next.



Action 2
Assume that action A01 was completed on Jan-05 and A02 started on Jan-07. Then the entire plan would shift as follows: