Changes between Version 72 and Version 73 of ProjectManagementIdeas

Timestamp:

May 21, 2009, 5:43:13 PM (15 years ago)

Author:

Chris Nelson

Comment:

Flesh out scheduler requirements

ProjectManagementIdeas

@@ -395 +395 @@
  task:: The ID of the task this task depends on  (I'd really like a better name here.  ''parent'' is wrong. ''origin''? ''other''?)
  type:: Dependency type (FS, SS, SF, or FF)
- lag:: Offset of this task's anchor relative to the anchor of ''task''. Whether the ''anchor'' for the dependency is the start or end of the task depends on the dependency type.  For example, if Task B has a FS dependency on Task A with a lag of 1 day, then Task B starts 1 day after Task A finishes.  Or, if Task B has an SS dependency in Task A with a lag of 1 day, then Task B starts 1 day after Task A starts.  (''lag'' is not scaled by ''percentEffort''.)
+ lag:: Offset of this task's anchor relative to the anchor of ''task''.  (''Lag'' may be negative.) Whether the ''anchor'' for the dependency is the start or end of the task depends on the dependency type.  For example, if Task B has a FS dependency on Task A with a lag of 1 day, then Task B starts 1 day after Task A finishes.  Or, if Task B has an SS dependency in Task A with a lag of 1 day, then Task B starts 1 day after Task A starts.  (''lag'' is not scaled by ''percentEffort''.)
 
 == IProjectCalendar ==
@@ -423 +423 @@
 Computing a schedule involves determining the ''computedStart'' and ''computedFinish'' for a set of tasks taking into account the dependencies between tasks and the resources assigned to those tasks.  Where the tasks do not have assignedStart or assignedFinish, the computed schedule prioritizes tasks to keep resources at or below 100% utilization.  However, assigned dates may force overloaded resources.  These overloads can then be reported and either manually resolved or resolved with a resource leveling module apart from the scheduler.
 
-Random algorithm notes.
+The following rules control the scheduling:
+
+ * Handle assigned dates
+  * It is an error for a task to have an assignedStart ''and'' an assignedFinish.
+  * If a task has an assignedStart, the computedStart is the assignedStart and the computedFinish is the computedStart plus the duration.  Done scheduling this task.
+  * If a task has an assignedFinish, the computedFinish is the assignedFinish and the computedStared is the computedFinish minus the duration.  Done scheduling this task.
+
+ * Handle dependencies (This must be done iteratively for all of a task's dependencies.  Several FS dependencies may produce different computedStart dates with the latest one being use.  Interaction between other types of dependencies is complex.)
+  * If a task has an FS dependency on another task, its computedStart is the other task's computedFinish plus lag.  The task's computedFinish is computedStart plus duration.
+  * If a task has an SS dependency on another task, its computedStart is the other task's computedStart plus lag. The task's computedFinish is computedStart plus duration.
+  * If a task has an FF dependency on another task, its computedFinish is the other task's computedFinish plus lag.  The task's computedStart is the computedFinish minus duration.
+  * If a task has an SF dependency on another task, its computedFinish is the other task's computedStart plus lag.  The task's computedStart is the computedFinish minus duration.
+
+ * Handle resource limitations[[br]]Tasks assigned to the same resource but with no other dependency between them and no assigned dates must be sequenced to keep from overloading the resource.  A comparison function can be used to determine which task should go first (as in many sorting algorithms).  {{{sequenceTasks(taskA,taskB)}}} would return -1 if taskA should go first, 1 if taskB should go first or 0 if it doesn't matter.  ''The scheduler should not be aware of the policy implemented in the comparison function.'' Possible criteria for sequencing the tasks include:
+   * priority - More important/urgent work goes first
+   * risk - Riskier work goes first
+   * work - A function may favor short tasks ("low hanging fruit") or long ones (which inherently have more risk).
+   * percentComplete - Finishing something that's partially done is better than starting something new
+   * "fit" - It's better to start a 2-day task on Wednesday and hold a 4 day task for the next week than to break up the longer task across a weekend.
+
+=== Random algorithm notes ===
 
  * As Late As Possible (ALAP) with only FS dependency is an easy scheduling algorithm.  A task without successors is due on it's milestone date and things back up from there.  However, it is sometimes helpful to use ASAP, even for single tasks.  For example, if a software development task is poorly understood so its estimate might be wildly wrong, that task should be tackled early in the project so that deviation from estimate is known early and there is more time to adjust for it.  Also, it's often desirable to handle bugs before new features so tasks might get ALAP and bugs ASAP within the same project.