Changes between Version 137 and Version 138 of ProjectManagementIdeas
- Timestamp:
- Feb 6, 2016, 7:49:21 AM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ProjectManagementIdeas
v137 v138 3 3 = Project management ideas 4 4 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 assumethey 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 havea milestone with a target date and tickets to complete the work for that phase.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 general project management solution and assume that resources are limited to people only and that they are available full time. 6 7 In 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. 8 8 9 9 == Requirements and Definitions … … 12 12 13 13 * When will my project be done? That is, what is the forecast completion date? 14 * How much Earned Valuehas 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)? 16 16 * Am I on schedule? That is, is the percent complete for the overall project where it should be at this time? 17 17 * 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? … … 30 30 === Task Properties 31 31 32 Answering the questions listed above requires recording certain properties of a task:32 Answering the questions listed above requires capturing certain properties of a task: 33 33 34 34 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. … … 46 46 Dependencies:: Other tasks that affect when this task can be started or finished. 47 47 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. 49 49 50 50 === Dependencies 51 51 52 Task dependencies can be quite complex.Project management generally involves four types of dependencies between tasks or activities:52 Project management generally involves four types of dependencies between tasks or activities: 53 53 54 54 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. … … 60 60 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. 61 61 62 While useful, the FF and SF dependencies are not commonly used and implementation may be deferred.62 While useful, the FF and SF dependencies are not commonly used and implementation in Trac may be deferred. 63 63 64 64 '''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. … … 66 66 === Resource Properties 67 67 68 In general a project resource may be many things such asa person working on a task (a carpenter or a software developer) or a source of supplies needed for a task (timber or computer systems).68 In 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). 69 69 70 70 A 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. … … 72 72 === Milestone Properties 73 73 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 doneto 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.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 finish 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. 77 77 78 78 == Task Scheduling 79 79 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 computesan 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.80 There 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. 81 81 82 82 The 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. 83 83 84 Consider a grossly-simplified project to design a new electronic device, with the following tickets:84 Consider a simplified project to design a new electronic device, with the following tickets: 85 85 86 86 ||'''ID'''||'''Summary'''||'''Milestone'''|| … … 174 174 === Dependency and Duration 175 175 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.176 Once 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: 177 177 178 178 [[Image(simple-gantt.PNG)]] … … 183 183 * package design can proceed independently 184 184 * 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 firmware185 * the product can't ship until it is assembled and has firmware 186 186 * the overall project will take 9 calendar days 187 187 … … 190 190 === Progress 191 191 192 If we also track work on tasks, we can monitor project progress at a glance .192 If we also track work on tasks, we can monitor project progress at a glance: 193 193 194 194 [[Image(gantt-progress.PNG)]] … … 196 196 === Resource Allocation 197 197 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 .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: 199 199 200 200 [[Image(gantt-resource.PNG)]] … … 204 204 === Critical Path 205 205 206 Some tasks affect project schedule and some do not. The tasks which affect the schedule are on the ''critical path'' .206 Some tasks affect project schedule and some do not. The tasks which affect the schedule are on the ''critical path'': 207 207 208 208 [[Image(critical-path.PNG)]] 209 209 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.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. 211 211 212 212 === Sub-tasks 213 213 214 To manage the complexity of the chart, we can break tasks down into sub-tasks and show various levels of detail .214 To manage the complexity of the chart, we can break tasks down into sub-tasks and show various levels of detail: 215 215 216 216 [[Image(roll-up-1.PNG)]] … … 220 220 === Progress Line 221 221 222 A Gantt chart often includes a "today" line to show where a project stands .222 A Gantt chart often includes a "today" line to show where a project stands: 223 223 224 224 [[Image(progress-line.PNG)]] … … 228 228 === Slack Time 229 229 230 A Gantt chart may also show slack time for tasks, how much they can slip before affecting the overall schedule .230 A Gantt chart may also show slack time for tasks, how much they can slip before affecting the overall schedule: 231 231 232 232 [[Image(slack.PNG)]] … … 289 289 Trac has several Gantt chart plugins: 290 290 291 [wiki:TracJsGanttPlugin TracJsGantt]:: Adata-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. 292 292 293 293 [wiki:FlashGanttPlugin FlashGantt]:: seems complex and stale. … … 339 339 * Custom Fields 340 340 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.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. 342 342 343 343 == Roadmap 344 344 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:345 There 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: 346 346 347 347 * Tasks will be represented as tickets. Additional non-core data will be needed. In object-oriented terms, Task could be a subclass of Ticket. … … 361 361 * !MasterTickets, 362 362 * !TimingAndEstimation, and 363 * custom fields to hold assigned and calculated dates [[br]]Anew 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. 364 364 365 365 * We need a resource calendar plugin to allow describing resources and their availability. This should support notions of normal work hours, holidays, etc. … … 382 382 383 383 id:: Numeric ID, inherent in Trac. 384 work:: Person-hours of work to complete t ask.384 work:: Person-hours of work to complete the task. An integer. 385 385 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. 386 386 priority:: Relative priority. An integer. … … 400 400 401 401 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. 403 403 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''. 404 404 … … 407 407 An 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: 408 408 409 * Finding related tasks 409 * Finding related tasks: 410 410 * Finding predecessors (immediate and indirect). 411 411 * Finding successors (immediate and indirect). … … 453 453 '''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. 454 454 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: 456 456 * 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 computedStartplus 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. 458 458 * 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. 459 459 * 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. 460 460 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. 466 466 * 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 features468 * 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 4day 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. 470 470 471 471 == Schedule Scenarios … … 482 482 483 483 == Reader Feedback 484 485 ''Use this section to provide additional comments and or suggestions''486 484 487 485 === Suggestion(s) by Jay Walsh