Changes between Version 67 and Version 68 of ProjectManagementIdeas


Ignore:
Timestamp:
May 8, 2009, 10:30:31 PM (6 years ago)
Author:
ChrisNelson
Comment:

Scheduler notes

Legend:

Unmodified
Added
Removed
Modified
  • ProjectManagementIdeas

    v67 v68  
    4646 Dependencies:: Other tasks that affect when this task can be started or finished.
    4747
    48  Task Hierarchy:: A "Work Breakdown Structure" is often used to give a hierarchical organization of all tasks on a project.  Task 1.1.2 would have subtask 1.1.2.1 and 1.1.2.2.  We propose to express the hierarchy but not force explicit numbering. We propose that each task have a single parent, which is the next level up in a WBS.
     48 Task Hierarchy:: A "Work Breakdown Structure" is often used to give a hierarchical organization of all tasks on a project.  For example, interior painting of a new house might be broken down into paint the living room, paint the dining room, etc.  In a WBS, task 1.1.2 would have subtask 1.1.2.1 and 1.1.2.2.  We propose to express the hierarchy but not force explicit numbering. We propose that each task have a single parent, which is the next level up in a WBS.
    4949
    5050==== Dependencies ====
     
    6060  Start-to-Finish (SF):: Task B cannot finish until Task A starts.  When building a house, the builder may begin getting interim payments during construction but payment will not be completed until the owner can start moving in.
    6161
    62 In addition, managing the complexity of a large project requires breaking large tasks into smaller ones (or viewing groups of small tasks as larger aggregates).  For example, interior painting might be broken down into paint the living room, paint the dining room, etc.
    63 
    6462While useful, the FF and SF dependencies are somewhat more esoteric than the others and implementation may be deferred.
    6563
     
    8078== Task Scheduling ==
    8179
    82 There are two fundamental ways to approach scheduling.  One is to assume that all tasks are small and to divide total estimates by resource rate.  Then, one compares earned value to cost, computes CPF, and computes an estimated end time.  This is far simpler, but fails to capture tasks that only some people can work on and other complexities.   The other is to create an actual plan that shows when each resource will work on tasks.
     80There are two fundamental ways to approach scheduling.  One is to assume that all tasks are small and to divide total estimates by resource rate.  Then, one compares earned value to cost, computes CPF (Cost Performance Factor), and computes an estimated end time.  This is the far simpler approach, but fails to capture tasks that only some people can work on and other complexities.   The other approach is to create an actual plan that shows when each resource will work on tasks.
    8381
    8482The basic answer to "When will my project be done?" is generally ''displayed in'' a [http://en.wikipedia.org/wiki/Gantt_chart Gantt chart] which shows tasks, their dependencies, their duration (scaled by resource availability), and milestones.  [http://groups.google.com/group/trac-users/browse_thread/thread/83c0b6a248040542?hl=en Two] [http://groups.google.com/group/trac-users/browse_thread/thread/3084796acbc7233c/3f393a18f99cfebd?hl=en&tvc=2#3f393a18f99cfebd}}} threads] on the Trac Users mailing list, suggest that a Gantt chart is a fundamental requirement for project management but scheduling tasks is even more fundamental and a necessary precondition for producing a Gantt chart.
     
    253251== Resource Description and Allocation ==
    254252
    255 We need a proposal for how to describe available resources within trac.
    256 
    257 If we use tickets to express tasks, then one could assume that a ticket will be worked on by the ticket's owner.  It might then be necessary to allow tickets to have multiple owners.   Or, we might want to have a way to have a list of (resource,hours) pairs independent of the owner.
     253We need a proposal for how to describe available resources within Trac.  If tasks are tickets and tickets have owners who work on them, it seems reasonable that a resource is a Trac user.  There may be information we need to track for a resource that it not part of the user configuration.  It might also be necessary or desirable to allow tickets to have multiple owners.   Or, we might want to have a way to have a list of (resource,hours) pairs independent of the owner.
    258254
    259255= Related Work =
     
    345341There seems to be a consensus that grandiose project management features for Trac should be implemented with a combination of plugins which provide useful functionality on their own.  The following plan assumes that approach.
    346342
    347  * Tasks will be represented as tickets.
     343 * Tasks will be represented as tickets.  Additional, non-core, data will be needed.  (In object-oriented terms, you might say that Task is a subclass of Ticket.)
    348344
    349345 * We need a way to express WBS relationships, assuming !MasterTickets will be used to express dependencies.  If we need more than FS dependencies, we will need to extend !MasterTickets to express dependency type.
     
    372368
    373369Tasks for project management will be based on tickets but an abstract interface allows us to decouple a scheduler or other PM tool from the implementation of non-core ticket features like recording estimates and progress.  One user may choose to implement !IProjectTask on top of !TimeingAndEstimation and another on top of !TracHours.
     370
     371Tasks have start and finish dates.  We may want to be able to set these explicitly for individual tasks.  If no finish date is specified, the finish date is derived from dependencies.  If there are no dependencies, the task is assumed to finish on the milestone date.
    374372
    375373
     
    394392  * The date of the task's milestone
    395393  * Dependency on other tasks
    396   * Resource sharing
     394  * Resource sharing (contention)
    397395
    398396 * For ALAP with FS and 100% resource application (effort)
     
    405403
    406404 * 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.
     405
     406 * 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.
     407
    407408'''...more here...'''
    408409