[[PageOutline]] Trac is strong in basic, individual and small-team task management but lacks features for heavy-duty project management ''a la'' Microsoft Project, Project Manager Workbench, etc. This page discusses those missing features and how they can best be realized. = Requirements and Definitions = Project management support software should help us answer a few basic questions: * When will my project be done? (That is, what is the forecasted completion date.) * Am I on schedule? (That is, is the percent complete for the overall project where it should be at this time.) * What tasks are on the critical path? (That is, what tasks must be finished on time to not affect project completion.) * How are my resources being utilized? * How will a change (e.g., in scope or constraints) affect project completion or resource utilization? To answer these questions, it must know about: * Tasks to be done * Dependencies between tasks * Resources available to do tasks * Assignment of resources to tasks * Deadlines for task or project completion == Task Properties == Answering the questions listed above requires recording certain properties of a task. Duration:: The amount of work needed to complete the task. This is ''not'', necessarily, the time it will take to complete the task. The task may be unassigned (and will take forever to complete) or has a resource assigned only part-time (so it will take longer to complete than the amount of work indicates). Assigned resource:: The individual who will work on this task. % Effort:: The amount of the resource's time that will be spent on this task. If the resource is working on a 2-day task 50% of the time, we expect it to take 4 days. % Complete:: The amount of the task that has been done already. Dependencies:: Other tasks that affect when this task can be started or finished. === Dependencies === Task dependencies can be quite complex. Project management generally involves four types of dependencies between tasks or activities: Finish-to-Start (FS):: Task B cannot start until task A finishes. This is the most common. When building a house, the walls cannot be put up until the foundation is complete. Start-to-Start (SS):: Task B cannot start until after task A starts (though they may finish independently). When building a house, interior painting cannot begin until the dry wall is started. (Each room can be painted as soon as its dry wall is up.) Finish-to-Finish (FF):: Task B cannot finish until task A finishes (though they may begin independently). When building a house, inspections cannot be completed until construction has completed (though parts may be inspected before the whole job is done). 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. 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. While useful, the FF and SF dependencies are somewhat more esoteric than the others and implementation may be deferred. ''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. == Resource Properties == 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 (cement or paint or computer systems). 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 cement or paint or CPU cycles. We don't seek to make Trac a completely general project management solution and will -- at least for now -- limit resources to people and assume they are available full time. == Milestone Properties == What are they? = Gantt Charts = The basic answer to "When will my project be done?" is generally provided by a [http://en.wikipedia.org/wiki/Gantt_chart Gantt chart] which shows tasks, their dependencies, their duration (scaled by resource availability), and milestones. As discussed in [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, a Gantt chart is a fundamental requirement for project management. In its most basic form, a Gantt chart shows: Tasks:: Self-contained units of work Dependencies:: Relationships between tasks that constrain when they can be done Milestones:: Dates by which one or more tasks must be completed It may also show resource assignments and progress in tasks. It often includes a "today" line to show where a project stands. (If the project is on schedule, all tasks to the left of ''today'' are complete and any task that spans ''today'' has a progress bar to the right of ''today''.) A Gantt chart may also show slack time for tasks, how much they can slip before affecting the overall schedule. It often also highlights the ''critical path'', the set of tasks which determine the overall length of the project and which delay the project completion unit-for-unit as they are delayed or extended. == Component Data == Each Gantt chart component or feature requires data to support it. For Trac-based project management, this data is often in addition to the core ticket data. In general, we might expect to have multiple resources assigned to a task but if we use a Trac ticket as the basis for a task, we have only a single resource, the ticket owner. === Core Fields === Core ticket fields include relevant to project management include: * owner (who is working on it) * milestone (what milestone this ticket is part of) * status (new, assigned, ..., closed) * summary (short description) Core milestone fields relevant to project management include: * name * due (date and time) * completed (treated as a Boolean: open or closed) === Additional Data === For project management, we must have the following additional information about a task/ticket: * estimate (expected work required to complete task) * percent complete * dependencies * percent effort '''NOTE:''' While Gantt charts typically show percent complete, this can be computed from time remaining vs. total estimate or time worked vs. total estimate. We will not, necessarily, store percent complete. It is intuitive for display and analysis but difficult for data entry. = Resource Utilization = There are several views of resource utilization which may be helpful: * utilization over time (80% loaded this week, 110% next week, 70% the week after, etc.) * allocation at a time (10% on task 1, 20% on task 2, 50% on task 3, etc.) Both views may be combined in a sequence of stacked bar graphs. At T1, a resource is 80% utilized with 20% each on four tasks, at T2, one task is complete and the resource is 60% utilized with 20% on each of the remaining three tasks, etc. = Related Work = == Trac Plugins == Trac has three Gantt chart plugins: [wiki:FlashGanttPlugin FlashGantt]:: seems complex and stale. [wiki:GanttChartPlugin GanttChart]:: is a very simple Gantt chart implemented in a formatted text region. It is manually edited, not data-driven. [http://willbarton.com/code/tracgantt/ TracGantt]:: has potential but has some funky fields (e.g., Due to Assign) that don't seem to be appropriate to what we want to do with a Gantt chart. MasterTicketsPlugin supports FS dependency (but calls it ''blocks'' and ''blocked by''). The [http://trac.edgewall.org/wiki/SubTickets SubTickets] page talks about adding composition type dependency. Can this be done in a plugin like !MasterTickets or must it be in the core? TimingAndEstimationPlugin and TracHoursPlugin add estimated and actual hours fields to tickets. There is some disagreement about whether the estimate is the remaining time (so total estimated time is actual + estimate) or total time (so remaining time is estimate - actual). A Gantt chart typically wants estimate and percent complete. It is possible to extract this from either recording convention and we should likely allow either convention via a configurable interface. == Other work == There is a [http://www.viewpath.net/Website/ganttcharts/googlegadget.aspx Google Gadget Gantt chart] which might be leveraged for the visualizations once the data is made available (e.g., using [https://opensvn.csie.org/traccgi/swlcu/wiki/En/Devel/TracGViz/ TracGViz plugin]). That widget is developed and maintained by a company (i.e., [http://www.viewpath.net/ ViewPath]). Besides users need access to the internet and their projects environments '''have to''' be available too so that the iGoogle container be able to retrieve the data to display in the chart. All this means that local deployments (intranets, ...) are not possible. [http://www.simpleprojectmanagement.com/planner/home.html Planner] is an open source project management program. GNOME Office once included [http://wiki.linuxquestions.org/wiki/MrProject MrProject] (which may be another version of Planner). The news of !MrProject's death may be exaggerated; [http://live.gnome.org/Planner GNOME Live!] lists a 0.14.4 release in April 2009. Also: * [http://www.openworkbench.org/ Open Workbench] is a Microsoft Windows-based application not suitable for integration with a web-based tool like Trac. * [http://openproj.org/openproj OpenProj] also appears to be a desktop application. However, their [http://openproj.org/wiki/index.php/Available_Views views] page may guide development of PM output for Trac. * [http://www.ganttproject.biz/ GanttProject]'s website isn't very informative but it appears to be a desktop application. = Design = A Gantt plugin for Trac should analyze ticket dependencies and produce an interactive, explorable Gantt chart showing task progress and project status. By "project", I mean a set of related milestones. Perhaps a software project has a Design Phase, an Alpha Release, a Beta Release, and a General Release. Each phase would have a milestone with a target date and tickets to complete the work for that phase. There must be a way to specify which milestones to include either listing explicitly or by giving a pattern or substring filter. == What do we need in the back end ? == The chart should be able to show all tickets (though that may be a very complex chart) or alternately all those tickets matched by a (query | report) or any other ticket group provider. To effectively display project progress, tickets must have estimated and actual times as in the TimingAndEstimation plugin. It is also desirable to have loop detection to error-proof the tool used to create dependencies. It would be nice to be able to choose an As Late As Possible or As Soon As Possible algorithm for laying out tasks. == What do we need in the user interface ? == A "chart these" button on a report page would be very nice. Tasks in the chart should be links to the tickets they represent (preferentially opened in a separate tab or window). Milestones should be displayed in the chart as well. The chart should support interactively "folding" groups of tasks to hide detail. Zooming in order to see the WBS in more detail. Panning or scrolling in order to display the schedule at a different time. Each task's bar in the chart should show actual hours. The chart should have a Today line. The chart (or an accompanying report or tool) should aid in resource leveling by (at least) showing overcommitted resources. Visual indications about delays, task completion and other significant events. It would be nice to be able to create task dependencies graphically using the Gantt chart as a GUI or to change a milestone date by dragging it along the chart. = Design guidelines = In order to agree about how to implement this functionality, the very first step should be to describe the possible architectures (i.e., how the different components are going to interact with each other since the moment the request is sent by the client until the Gantt chart is rendered by the browser) that will be considered. == Components == In order to add flexibility to the final solution, the '''MVC pattern''' ''should'' be considered during its development. Hence the following components need to be implemented in order to add Gantt charts to Trac. === The Model === It provides the data in the Gantt chart and is not just a single element but a set of components like the following : * The ticket models, which provide data about the issues found in the project environment * Trac query mechanism which provides a way to select (filter) the tickets being shown. * [#RelatedWork Other plugins] used to track ticket dependencies * [#RelatedWork Other plugins] used to track task/subtask relationships * [#RelatedWork Other plugins] used to estimate the time needed to finish the given tasks * Maybe one (a few) component(s) whose role is to provide the functionality specific to Gantt charts, thus acting as a central access point and a mediator so as to put all the other components together. === The View === It ''should'' be a JavaScript component (is this possible ?) responsible for rendering the data provided by ''the model''. Besides it ''might'' support [#Whatdoweneedintheuserinterface other dynamic features] === The Controller === {{{ ¿What do we need this for? }}} === Implications === The aforementioned separation ''should'' allow the replacement of any of the components involved. Hence the following modifications ''should'' be made easily (the list being intentionally incomplete) : - Replace the JS-based view by another made with Flash. - Use a custom, or specific estimation strategy. = Roadmap = 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. == Dependency and Duration == There is some benefit to very basic Gantt that showed just tasks and their dependencies and the resultant schedule. [[Image(simple-gantt.PNG)]] Disregarding any resource constraints, this chart shows * circuit board design and firmware development follow schematic design * package design can proceed independently * assembly can't be done until the circuit boards and packaging are ready * the product can't ship until it's assembled and has firmware. * the overall project will take 9 calendar days (Clearly this is a gross simplification and likely not accurate in many ways.) This requires only that the ticket have some information about estimated effort or duration of the task and simple FS task dependency. == Progress == If we also track work on tasks, we can monitor project progress at a glance. [[Image(gantt-progress.PNG)]] == Resource Allocation == 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 time dialation. [[Image(gantt-resource.PNG)]] When the hardware and software engineers are only available half time, the project gets delayed. == Critical Path == Some tasks affect project schedule and some do not. The tasks which affect the schedule are on the ''critical path''. [[Image(critical-path.PNG)]] Packaging design and circuit board layout are so short -- relative to other activities -- they speeding them up doesn't really help the project. But if we could shorten schematic design or firmware, every day we take out of one of those activities we also take out of the project schedule. == Sub-tasks == To manage the complexity of the chart, we can break tasks down into sub-tasks and show various levels of detail. [[Image(roll-up-1.PNG)]] [[Image(roll-up-2.PNG)]] = Development Plan = 1. Fork !MasterTickets as !TicketDep (or something) and add ''composed of''/''part of'' dependencies and [http://trac.edgewall.org/wiki/SubTickets#CreatingSubtickets means to create them]. Plan for but do not yet implement ''starts with'' and ''ends with'' dependencies. 1. Specify the interfaces necessary for a scheduling plugin to use dependencies, estimates, and time worked to determine project schedule. * Consider adding a percentage available when scheduling resources. 1. Specify the interfaces necessary for a Gantt chart to get data from tickets. * Each task must have a name, duration, percent complete, and start or end. (The start or end comes from schedule calculations, not direct ticket data.) * Access to dependencies between tickets is also needed so as to render the chart. 1. Implement those interfaces on top of TimingAndEstimationPlugin. = Disclaimer = The bulk of this page was prepared by Chris Nelson who makes no claim to be certified project planner or anything of the sort. It is based on his understanding of project management after 25 years of software development. [#Contributors Other developers] have also offered some hints and useful comments (according to their experience) in order to enhance this page, and get a better understanding of the features and requirements needed. = Appendix : Microsoft Project Task Properties = Microsoft Project goes far beyond what is likely to be put into a Trac-based project management solution but it may be helfpul to consider what task properties MSProject records and what their analogs may be in Trac tickets. The Microsoft Project ''Task Information'' property sheet includes: * General * Name * Duration * Estimated (Boolean) * Percent complete * Priority * Start date * Finish date * Predecessors - A list of related tasks and their relationships * ID * Task Name * Type (FS, SS, etc.) * Lag (delay between tasks, overlap between tasks or lead if negative) * Resources - A list of resources * Resource Name * Units (% Effort for workers) * Advanced * Constraint * Deadline (a date or N/A) * Constraint (ASAP, ALAP, Start no earlier than, etc.) * Constraint date * Task Type (Fixed Units, Fixed Work, Fixed Duration) * Calendar (Standard, 24hr, Night Shift) * WBS code (outline number from Work Breakdown Structure such as 1.3 for the third subtask of task 1) * Earned value method (% Complete or Physical % Complete) * Notes (Like ticket comments, only worse) * Custom Fields == Contributors == - Olemis Lang