Changes between Version 137 and Version 138 of ProjectManagementIdeas


Ignore:
Timestamp:
Feb 6, 2016, 7:49:21 AM (8 years ago)
Author:
figaro
Comment:

Further cosmetic changes

Legend:

Unmodified
Added
Removed
Modified
  • ProjectManagementIdeas

    v137 v138  
    33= Project management ideas
    44
    5 Trac is strong in basic, individual and small-team task management, but lacks features for heavy-duty project management such as in [https://products.office.com/en-us/project/project-and-portfolio-management-software MS-Project] and [http://sourceforge.net/projects/openworkbench/ Open Workbench]. This page discusses those missing features and how they can best be realized in Trac. We don't seek to make Trac a completely general project management solution and will limit resources to people and assume they are available full time.
    6 
    7 In Trac, a "project" is sometimes synonymous with "installation". On this page it is a set of related tasks and deadlines. Each phase in the project would have a milestone with a target date and tickets to complete the work for that phase.
     5Trac is strong in basic, individual and small-team task management, but lacks features for heavy-duty project management such as in [https://products.office.com/en-us/project/project-and-portfolio-management-software MS-Project] and [http://sourceforge.net/projects/openworkbench/ Open Workbench]. This page discusses those missing features and how they can best be realized in Trac. We don't seek to make Trac a general project management solution and assume that resources are limited to people only and that they are available full time.
     6
     7In Trac, a "project" is sometimes synonymous with "installation". On this page a project is defined as a set of related tasks and deadlines and each phase in the project has a milestone with a target date and tickets to complete the work for that phase.
    88
    99== Requirements and Definitions
     
    1212
    1313 * When will my project be done? That is, what is the forecast completion date?
    14  * How much Earned Value has the project achieved?
    15  * How do incurred costs compare to [https://en.wikipedia.org/wiki/Earned_value_management Earned value] (Cost Performance Factor)?
     14 * How much [wikipedia:Earned_value_management Earned Value] has the project achieved?
     15 * How do incurred costs compare to Earned value (Cost Performance Factor)?
    1616 * Am I on schedule? That is, is the percent complete for the overall project where it should be at this time?
    1717 * What tasks are on the critical path? That is, what tasks have a positive or negative effect on the overall schedule if they are early or late?
     
    3030=== Task Properties
    3131
    32 Answering the questions listed above requires recording certain properties of a task:
     32Answering the questions listed above requires capturing certain properties of a task:
    3333
    3434 Original Work Estimate:: The amount of work believed to be needed to complete the task as of before the task was started. This is ''not'' necessarily the time it will take to complete the task (duration). The task may be unassigned (and will take forever to complete), may have a resource assigned only part-time (so it will take longer to complete than the amount of work indicates), or have multiple resources assigned (so it may take less time to complete than the amount of work indicates). Typically work will be expressed in hours of effort of a resource.
     
    4646 Dependencies:: Other tasks that affect when this task can be started or finished.
    4747
    48  Work Breakdown Structure / 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 would have subtask 1.1.1 and 1.1.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 Work Breakdown Structure / 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 [wikipedia:Work_breakdown_structure WBS], task 1.1 would have subtask 1.1.1 and 1.1.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
    5151
    52 Task dependencies can be quite complex. Project management generally involves four types of dependencies between tasks or activities:
     52Project management generally involves four types of dependencies between tasks or activities:
    5353
    5454  Finish-to-Start (FS):: Task B cannot start until task A finishes. This is the most common. Sometimes A is referred to as B's Predecessor. When building a house, the walls cannot be put up until the foundation is complete.
     
    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 While useful, the FF and SF dependencies are not commonly used and implementation may be deferred.
     62While useful, the FF and SF dependencies are not commonly used and implementation in Trac may be deferred.
    6363
    6464'''Note:''' The relationships are directional and inverting them is not straightforward. If A has a FS dependency on B, it is '''not''' true that B has an SF dependency on A.
     
    6666=== Resource Properties
    6767
    68 In general a project resource may be many things such as a person working on a task (a carpenter or a software developer) or a source of supplies needed for a task (timber or computer systems).
     68In general a project resource can be a person working on a task (a carpenter or a software developer) or a source of supplies needed for a task (timber or computer systems).
    6969
    7070A resource may have a name and typically has some availability. An employee may have responsibilities in two departments and only be available for certain work 50% of the time or a vendor may only be able to supply a certain amount of timber or CPU cycles.
     
    7272=== Milestone Properties
    7373
    74 The essential property of a milestone is its date. Trac tickets which are part of a milestone are implicitly due by the milestone date. In general project management, milestones have FS dependency with some tasks. Together with dependencies between tasks, this dictates when tasks must be done to keep a project on schedule.
    75 
    76 Trac milestones are not first-class objects, because they lack history and comments that tickets have. An alternative to Trac milestones is to create a custom ticket type that can be used to set deadlines and have tickets which are required for that ticket scheduled as if they had a milestone with a due date set. To avoid conceptual conflicts with Trac milestones, I've called that ticket type an ''inchpebble''. Trac milestones may still be used to group tickets but a milestone may have many inchpebbles which set intermediate dates.
     74The essential property of a milestone is its date. Trac tickets which are part of a milestone are implicitly due by the milestone date. In general project management, milestones have FS dependency with some tasks. Together with dependencies between tasks, this dictates when tasks must finish to keep a project on schedule.
     75
     76Trac milestones are not first-class objects, because they lack history and comments that tickets have. An alternative to Trac milestones is to create a custom ticket type that can be used to set deadlines and have tickets which are required for that ticket scheduled as if they had a milestone with a due date set. To avoid conceptual conflicts with Trac milestones, I've called that ticket type an ''inchpebble''. Trac milestones may still be used to group tickets, but a milestone may have many inchpebbles which set intermediate dates.
    7777
    7878== Task Scheduling
    7979
    80 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 (Cost Performance Factor), and computes an estimated end time. This is the 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.
     80There are two fundamental ways to approach scheduling. One approach is to assume that all tasks are small and to divide total estimates by resource rate. Then, compare earned value to cost, compute CPF (Cost Performance Factor), and compute an estimated end time. This is the 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.
    8181
    8282The basic answer to "When will my project be done?" is generally displayed in a [wikipedia:Gantt_chart Gantt chart] which shows tasks, dependencies, duration (scaled by resource availability) and milestones. Two threads [https://groups.google.com/forum/?hl=en#!topic/trac-users/g8C2okgEBUI here] and [https://groups.google.com/forum/?hl=en#!topic/trac-users/MIR5asvHIzw here] on the Trac Users mailing list suggest that a Gantt chart is a fundamental requirement for project management, but so is scheduling tasks and in fact a necessary condition for producing a Gantt chart.
    8383
    84 Consider a grossly-simplified project to design a new electronic device, with the following tickets:
     84Consider a simplified project to design a new electronic device, with the following tickets:
    8585
    8686||'''ID'''||'''Summary'''||'''Milestone'''||
     
    174174=== Dependency and Duration
    175175
    176 Once we have a task scheduler, we can simplify presentation of task scheduling with a basic Gantt chart that shows just tasks and their dependencies and the resultant schedule.
     176Once we have a task scheduler, we can simplify the presentation of task scheduling with a Gantt chart that shows tasks, their dependencies and the resultant schedule:
    177177
    178178[[Image(simple-gantt.PNG)]]
     
    183183 * package design can proceed independently
    184184 * assembly can't be done until the circuit boards and packaging are ready
    185  * the product can't ship until it's assembled and has firmware
     185 * the product can't ship until it is assembled and has firmware
    186186 * the overall project will take 9 calendar days
    187187
     
    190190=== Progress
    191191
    192 If we also track work on tasks, we can monitor project progress at a glance.
     192If we also track work on tasks, we can monitor project progress at a glance:
    193193
    194194[[Image(gantt-progress.PNG)]]
     
    196196=== Resource Allocation
    197197
    198 When a resource is not available 100% of the time, tasks take longer than the work suggests. By assigning effort to resources, we can chart this delay.
     198When a resource is not available 100% of the time, tasks take longer than the work suggests. By assigning effort to resources, we can chart this delay:
    199199
    200200[[Image(gantt-resource.PNG)]]
     
    204204=== Critical Path
    205205
    206 Some tasks affect project schedule and some do not. The tasks which affect the schedule are on the ''critical path''.
     206Some tasks affect project schedule and some do not. The tasks which affect the schedule are on the ''critical path'':
    207207
    208208[[Image(critical-path.PNG)]]
    209209
    210 Packaging design and circuit board layout are so short, relative to other activities, that speeding them up doesn't help the project. But if we could shorten schematic design or firmware, we shorten the project's duration.
     210Packaging design and circuit board layout are so short relative to other activities, that speeding them up doesn't help the project. But if we could shorten schematic design or firmware, we shorten the project's duration.
    211211
    212212=== Sub-tasks
    213213
    214 To manage the complexity of the chart, we can break tasks down into sub-tasks and show various levels of detail.
     214To manage the complexity of the chart, we can break tasks down into sub-tasks and show various levels of detail:
    215215
    216216[[Image(roll-up-1.PNG)]]
     
    220220=== Progress Line
    221221
    222 A Gantt chart often includes a "today" line to show where a project stands.
     222A Gantt chart often includes a "today" line to show where a project stands:
    223223
    224224[[Image(progress-line.PNG)]]
     
    228228=== Slack Time
    229229
    230 A Gantt chart may also show slack time for tasks, how much they can slip before affecting the overall schedule.
     230A Gantt chart may also show slack time for tasks, how much they can slip before affecting the overall schedule:
    231231
    232232[[Image(slack.PNG)]]
     
    289289Trac has several Gantt chart plugins:
    290290
    291  [wiki:TracJsGanttPlugin TracJsGantt]:: A data-driven plugin which presents ticket status in a display much like MS-Project's WBS format.
     291 [wiki:TracJsGanttPlugin TracJsGantt]:: a data-driven plugin which presents ticket status in a display much like MS-Project's WBS format.
    292292
    293293 [wiki:FlashGanttPlugin FlashGantt]:: seems complex and stale.
     
    339339 * Custom Fields
    340340
    341 However, this doesn't seem to be all the data that MS-Project records for a task. If you add a column to the WBS in the Gantt chart, there are many more options. The most interesting is Work which is the amount of work required to complete a task. Only when a resource is assigned 100% are Work and Duration the same. We'd like to specify the ''work'' required for a task and let the system calculate its ''duration'' based on available resources.
     341However, this doesn't seem to be all the data that MS-Project records for a task. If you add a column to the WBS in the Gantt chart, there are many more options. The most interesting is Work, which is the amount of work required to complete a task. Only when a resource is assigned 100% are Work and Duration the same. We'd like to specify the ''work'' required for a task and let the system calculate its ''duration'' based on available resources.
    342342
    343343== Roadmap
    344344
    345 There seems to be a consensus that grandiose project management features for Trac should be implemented with a combination of plugins. The following plan assumes that approach:
     345There seems to be a consensus that grandiose project management features for Trac should be implemented with a combination of plugins, in which case this approach could be followed:
    346346
    347347 * Tasks will be represented as tickets. Additional non-core data will be needed. In object-oriented terms, Task could be a subclass of Ticket.
     
    361361  * !MasterTickets,
    362362  * !TimingAndEstimation, and
    363   * custom fields to hold assigned and calculated dates[[br]]A new Scheduling plugin can build on these plugins (or an interface that hides them), and create an as-late-as-possible schedule working back from a milestone.
     363  * custom fields to hold assigned and calculated dates and a new Scheduling plugin can build on these plugins (or an interface that hides them), and create an as-late-as-possible schedule working back from a milestone.
    364364
    365365 * We need a resource calendar plugin to allow describing resources and their availability. This should support notions of normal work hours, holidays, etc.
     
    382382
    383383 id:: Numeric ID, inherent in Trac.
    384  work:: Person-hours of work to complete task.
     384 work:: Person-hours of work to complete the task. An integer.
    385385 risk:: Relative risk as a measure of likelihood of the ''work estimate'' being accurate, where 0 means 'certain to be accurate'. An integer from 0 to 100.
    386386 priority:: Relative priority. An integer.
     
    400400
    401401 task:: The ID of the task this task depends on (I'd really like a better name here. ''parent'' is wrong. ''origin''? ''other''?)
    402  type:: Dependency type (FS, SS, SF, or FF)
     402 type:: Dependency type: FS, SS, SF, or FF.
    403403 lag:: Offset of this task's anchor relative to the anchor of ''task'', and 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''.
    404404
     
    407407An interface that abstracts the implementation details of dependencies and allows other parts of the PM system (e.g., a Gantt chart or scheduler) to retrieve and update dependencies including:
    408408
    409  * Finding related tasks
     409 * Finding related tasks:
    410410  * Finding predecessors (immediate and indirect).
    411411  * Finding successors (immediate and indirect).
     
    453453'''Note''': 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.
    454454
    455  * 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.):
     455 * 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:
    456456  * 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.
    457   * 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.
     457  * 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.
    458458  * 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.
    459459  * 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.
    460460
    461 '''Note''': A scheduling algorithm which handled only FS dependencies would be a ''very'' useful first step.
    462 
    463  * 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:
    464    * priority - More important/urgent work goes first
    465    * risk - Riskier work goes first
     461'''Note''': The FS and SS dependencies are the most common and FF and SF are a nice-to-have.
     462
     463 * Handle resource limitations: 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:
     464   * priority - More important/urgent work goes first.
     465   * risk - Riskier work goes first.
    466466   * work - A function may favor short tasks ("low hanging fruit") or long ones (which inherently have more risk).
    467    * task type - fix bugs before doing new features
    468    * percentComplete - Finishing something that's partially done is better than starting something new
    469    * "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.
     467   * task type -Ffix bugs before doing new features.
     468   * percentComplete - Finishing something that's partially done is better than starting something new.
     469   * "fit" - It is 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.
    470470
    471471== Schedule Scenarios
     
    482482
    483483== Reader Feedback
    484 
    485   ''Use this section to provide additional comments and or suggestions''
    486484
    487485=== Suggestion(s) by Jay Walsh