Changes between Version 73 and Version 74 of ProjectManagementIdeas


Ignore:
Timestamp:
May 21, 2009 7:54:08 PM (5 years ago)
Author:
ChrisNelson
Comment:

Scheduling method (ASAP vs. ALAP)

Legend:

Unmodified
Added
Removed
Modified
  • ProjectManagementIdeas

    v73 v74  
    425425The following rules control the scheduling: 
    426426 
     427 * Choosing a method 
     428  * If using As Soon As Possible, tasks without precedessors should be done done today (or the start of the project, if that's later), and their successors when they are done, etc. 
     429  * If using As Late As Possible, tasks without successors should be done at the end of the project and their predecessors done right before they must start, etc. 
     430  * It may be desirable to override the method for individual tasks so exploratory work is done ASAP and clean up work is done ALAP, regardless of the overall method being used. 
     431 
    427432 * Handle assigned dates 
    428433  * It is an error for a task to have an assignedStart ''and'' an assignedFinish. 
    429   * If a task has an assignedStart, the computedStart is the assignedStart and the computedFinish is the computedStart plus the duration.  Done scheduling this task. 
    430   * If a task has an assignedFinish, the computedFinish is the assignedFinish and the computedStared is the computedFinish minus the duration.  Done scheduling this task. 
     434  * If a task has an assignedStart, the computedStart is the assignedStart and the computedFinish is the computedStart plus the duration. 
     435  * If a task has an assignedFinish, the computedFinish is the assignedFinish and the computedStared is the computedFinish minus the duration. 
     436 
     437NOTE: Once a task is begun, its assignedStart is set from the computedStart so recomputing a schedule doesn't change its start.  We may have to deal with split tasks, however, if a task is begun then put down and resumed later. 
    431438 
    432439 * 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.) 
     
    440447   * risk - Riskier work goes first 
    441448   * work - A function may favor short tasks ("low hanging fruit") or long ones (which inherently have more risk). 
     449   * task type - fix bugs before doing new features 
    442450   * percentComplete - Finishing something that's partially done is better than starting something new 
    443451   * "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. 
    444452 
    445 === Random algorithm notes === 
    446  
    447  * 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. 
    448  
    449  * There are three constraints that influence a task's scheduling: 
    450   * The date of the task's milestone 
    451   * Dependency on other tasks 
    452   * Resource sharing (contention) 
    453  
    454  * For ALAP with FS and 100% resource application (effort) 
    455   * Task A's finish date is the milestone date if it has no successors 
    456   * Task A's finish date is Task B's start date if B has an FS dependency on A (A -> B) 
    457   * Resolve resource conflict: 
    458    * Task A should be before B if A has successors and B does not 
    459    * Task A should be before B if A is higher priority 
    460    * Task A should be before B if A has more risk 
    461  
    462  * With the above rules for putting A before B, does scheduling become a sorting operation that just needs a comparison function which implements those rules?  Intuitively, an O(n^2^) sort like bubble sort would work but something like a merge sort might not because tasks in the partitions might depend on one another.  Perhaps partitioning can be done to eliminate dependencies. 
    463  
    464  * It might be helpful or interesting to consider saving schedules or scenarios.  If we stored resource assignment, start and finish data in a table keyed by schedule and ticket, we could store multiple possible schedules and choose to display different ones.  An initial release could have only a single schedule and no facility for creating alternatives.  A later refinement could add scenario support.  If a start or finish date was configured for a task, the schedule would copy that data and not allow editing or recomputation of those dates; other tasks would flow around that fixed time.  If a task lacked a start or finish date, the scheduling of that task would be fluid and computed by the scheduler. 
    465  
    466 '''...more here...''' 
     453== Schedule Scenarios == 
     454 
     455It might be helpful or interesting to consider saving schedules or scenarios.  If we stored resource assignment, start and finish data in a table keyed by schedule and ticket, we could store multiple possible schedules and choose to display different ones.  An initial release could have only a single schedule and no facility for creating alternatives.  A later refinement could add scenario support.  If a start or finish date was configured for a task, the schedule would copy that data and not allow editing or recomputation of those dates; other tasks would flow around that fixed time.  If a task lacked a start or finish date, the scheduling of that task would be fluid and computed by the scheduler. 
    467456 
    468457= Disclaimer =