Changes between Version 67 and Version 68 of ProjectManagementIdeas
- Timestamp:
- May 8, 2009, 8:30:31 PM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ProjectManagementIdeas
v67 v68 46 46 Dependencies:: Other tasks that affect when this task can be started or finished. 47 47 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. 49 49 50 50 ==== Dependencies ==== … … 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 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 64 62 While useful, the FF and SF dependencies are somewhat more esoteric than the others and implementation may be deferred. 65 63 … … 80 78 == Task Scheduling == 81 79 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 otheris to create an actual plan that shows when each resource will work on tasks.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 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. 83 81 84 82 The 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. … … 253 251 == Resource Description and Allocation == 254 252 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. 253 We 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. 258 254 259 255 = Related Work = … … 345 341 There 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. 346 342 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.) 348 344 349 345 * 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. … … 372 368 373 369 Tasks 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 371 Tasks 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. 374 372 375 373 … … 394 392 * The date of the task's milestone 395 393 * Dependency on other tasks 396 * Resource sharing 394 * Resource sharing (contention) 397 395 398 396 * For ALAP with FS and 100% resource application (effort) … … 405 403 406 404 * 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 407 408 '''...more here...''' 408 409