Project management ideas

Trac is strong in basic, individual and small-team task management, but lacks features for heavy-duty project management such as in ​MS-Project and ​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.

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.

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 forecast completion date?
• How much ​Earned Value has the project achieved?
• How do incurred costs compare to Earned value (Cost Performance Factor)?
• 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 have a positive or negative effect on the overall schedule if they are early or late?
• How are my resources being utilized?

To answer these questions, the system 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.

Some of this is part of the Trac core, some is provided by existing plugins and some must be added to support project management. None of this is antithetical to Trac's design and implementation.

Task Properties

Answering the questions listed above requires capturing certain properties of a task:

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.

Current Work Estimate

The total time the task is expected to take, as of now. Like Original Work Estimate, but may be modified over the course of the project.

Expended effort

The amount of work expended against this task so far.

Assigned resources

The individuals who will work on this task.

% Effort

Per resource, 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. If there are 10 subtasks with 10 hours original work estimate and 6 are done, the task is 60% complete.

Dependencies

Other tasks that affect when this task can be started or finished.

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.

Dependencies

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. Sometimes A is referred to as B's Predecessor. 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.

While useful, the FF and SF dependencies are not commonly used and implementation in Trac 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 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).

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.

Milestone Properties

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.

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.

Task Scheduling

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.

The basic answer to "When will my project be done?" is generally displayed in a ​Gantt chart which shows tasks, dependencies, duration (scaled by resource availability) and milestones. Two threads ​here and ​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.

Consider a simplified project to design a new electronic device, with the following tickets:

ID	Summary	Milestone
1	Design the Schematic	New device
2	Design the Motherboard	New device
3	Design the Daughter board	New device
4	Design the packaging	New device
5	Write firmware	New device
6	Assemble units	New device

With this task list, supported by core Trac tickets and milestones, we'll know when we are done because all the tickets are closed but we have no way to project when that will be. If all the tasks could be done concurrently, the project length is the length of the longest task. And since Trac assigns a date to the milestone, we can work backwards to determine when work needs to start for the milestone to be met. However, core Trac has no way to record the time that a task should take. Hence, we need a field to hold [Estimated] Work:

ID	Summary	Work
1	Design the Schematic	24h
2	Design the Motherboard	8h
3	Design the Daughter board	8h
4	Design the packaging	16h
5	Write firmware	40h
6	Assemble units	8h

From here we can determine that the shortest duration of the project is one week. However, we know we cannot begin circuit board layout without a schematic. We need a field to hold Predecessors:

ID	Summary	Estimate	Predecessors
1	Design the Schematic	24h
2	Design the Motherboard	8h	1
3	Design the Daughter board	8h	1
4	Design the packaging	16h
5	Write firmware	40h	1
6	Assemble units	8h	2,3,4,5

For such a short task list we can manually inspect and see that assembly (8h) follows firmware (40h) follows schematic (24h) and the shortest project time is 72 hours (9 person-days) and we can take 9 days from the milestone date to know when we have to start work to finish on time. However, a project of any complexity may have many more tasks and manual inspection is impractical.

We can begin to do more effective project management if we have a task scheduler that can work backwards from the milestone, considers work and dependencies, and calculate task start and end dates and project start date.

If the milestone for this work is May 11, the schedule might look like the following:

ID	Summary	Work	Predecessors	Due	Start
1	Design the Schematic	24h		May 5, 2009	May 3, 2009
2	Design the Motherboard	8h	1	May 10, 2009	May 10, 2009
3	Design the Daughter board	8h	1	May 10, 2009	May 10, 2009
4	Design the packaging	16h		May 10, 2009	May 9, 2009
5	Write firmware	40h	1	May 10, 2009	May 6, 2009
6	Assemble units	8h	2,3,4,5	May 11, 2009	May 11, 2009

This is computed as follows:

• Assemble units is the last step and is due when the milestone is scheduled.
• Firmware, packaging design, and the circuit board all must be done before assembly or 1 day (the length of the assembly task) before the milestone.
• Schematic is due the length of the circuit board task before the circuit board's end.

To finish on time, the project must start on May 3, the earliest start time for any task.

However, the preceding schedule assumes that the motherboard and daughter board are independent tasks. If there is only one board designer, only one board at a time can be worked on. If we assign the same resource to the board designs, either one must be done before the other can begin (even in the absence of an FS dependency) or the time for both must be extended and the resource spread between them concurrently.

With 100% applied to each task, the motherboard and daughter board are worked on serially:

ID	Summary	Work	Predecessors	Resource	Due	Start
1	Design the Schematic	24h			May 5, 2009	May 3, 2009
2	Design the Motherboard	8h	1	Monty	May 9, 2009	May 9, 2009
3	Design the Daughter board	8h	1	Monty	May 10, 2009	May 10, 2009
4	Design the packaging	16h			May 10, 2009	May 9, 2009
5	Write firmware	40h	1		May 10, 2009	May 6, 2009
6	Assemble units	8h	2,3,4,5		May 11, 2009	May 11, 2009

With 50% applied to each task, the board designs are worked on in parallel but take twice as long:

ID	Summary	Work	Predecessors	Resource	Due	Start
1	Design the Schematic	24h			May 5, 2009	May 3, 2009
2	Design the Motherboard	8h	1	Monty (50%)	May 9, 2009	May 10, 2009
3	Design the Daughter board	8h	1	Monty (50%)	May 9, 2009	May 10, 2009
4	Design the packaging	16h			May 10, 2009	May 9, 2009
5	Write firmware	40h	1		May 10, 2009	May 6, 2009
6	Assemble units	8h	2,3,4,5		May 11, 2009	May 11, 2009

Calendar

The schedule above isn't accurate unless we have a 7-day work week. If we assume that the work week is Monday to Friday, firmware has to finish Friday, May 8 and schematic has to finish Friday, May 1, so the project must begin April 29. Applying calendar information, our task list looks as follows:

ID	Summary	Work	Predecessors	Resource	Due	Start
1	Design the Schematic	24h			May 1, 2009	April 29, 2009
2	Design the Motherboard	8h	1	Monty	May 7, 2009	May 7, 2009
3	Design the Daughter board	8h	1	Monty	May 8, 2009	May 8, 2009
4	Design the packaging	16h			May 8, 2009	May 7, 2009
5	Write firmware	40h	1		May 8, 2009	May 4, 2009
6	Assemble units	8h	2,3,4,5		May 11, 2009	May 11, 2009

MS-Project supports many calendars in a project. Roughly speaking, the project calendar has working hours per day and working days per week (e.g., 9-5, Monday-Friday) and resource calendars can override that (e.g., Ethan is on vacation the August 15-19).

Gantt Charts

Dependency and Duration

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:

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 is assembled and has firmware
• the overall project will take 9 calendar days

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:

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 delay:

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:

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.

Sub-tasks

To manage the complexity of the chart, we can break tasks down into sub-tasks and show various levels of detail:

Progress Line

A Gantt chart often includes a "today" line to show where a project stands:

Bumps to the left indicate tasks that are behind schedule.

Slack Time

A Gantt chart may also show slack time for tasks, how much they can slip before affecting the overall schedule:

The black bars extending from the bottom of circuit board and packaging design indicate how much those tasks can slip without affecting deliverable.

Should talk about lag here

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.

Earned Value

To compute Earned value, we need unchanged original estimates and an estimate of remaining time.

Resource Description and Allocation

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 is 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.

Trac Core

There are a couple of tickets (​#31, ​#886) and some discussion about ticket ​linking and ​relationships in the Trac core. There are also some ​TracCaseStudies with uses of Trac in a project management environment.

There is also a cookbook recipe on ​Requirements management.

Trac Plugins

Dependencies

MasterTicketsPlugin supports FS dependency, but calls it blocks and blocked by.

The ​SubTickets proposal talks about adding composition type dependency (parent/child relationships).

SubticketsPlugin and ChildTicketsPlugin provide composition type dependency that can be used for WBS.

The TracDependencyPlugin was created in August 2009 and shows promise as a more complete and flexible solution than upgrading MasterTickets.

The ProjectPlanPlugin has the ability to present dependencies visually.

Time and Scheduling

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 has estimate and percent complete. It is possible to extract this from either recording convention and we should allow either convention via a configurable interface. There is also a TimeEstimationAndQuotingSpecification.

DateFieldPlugin has some helpful wrappers around custom fields to validate them as dates.

SchedulingToolsPlugin has a scheduler, resource availability and Gantt chart in a simple fashion. It is in alpha stage, however.

TeamCalendarPlugin keeps track of user availability.

AnjLabSyncItPlugin is a Windows program that synchronises MS-Outlook calendar tasks with Trac tickets.

Gantt Charts

Trac has several Gantt chart plugins:

TracJsGantt

a data-driven plugin which presents ticket status in a display much like MS-Project's WBS format.

FlashGantt

seems complex and stale.

GanttChart

is a very simple Gantt chart implemented in a formatted text region. It is manually edited, not data-driven.

GanttCalendar

provides nice views of tickets. It uses "Completed [%]" in 5% increments, "Start" (YYYY-MM-DD), and "End" (YYYY-MM-DD) custom fields. It includes an administrative calendar, perhaps where holidays and such can be recorded.

Earned Value Chart

a macro that creates an earned value chart by using the earliest start date of all tickets in the milestone and the planned end date of the milestone.

Data Exchange

The TicketImportPlugin can import tasks exported from MS-Project as a CSV file. There is a patch to import dependencies, so MS-Project can feed MasterTickets.

Because Microsoft products are present in many environments, it would be nice if we could get availability information from Exchange to feed a project calendar. Just reading from the group calendar would probably be enough. That way users would only have to put in their vacations, etc. in one place.

MS-Project Task Properties

MS-Project goes far beyond what is likely to be put into a Trac-based project management solution, but it may be helpful to consider what task properties are recorded and what their analogs may be in Trac tickets.

The MS-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

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.

Roadmap

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:

• Tasks will be represented as tickets. Additional non-core data will be needed. In object-oriented terms, Task could be a subclass of Ticket.

• 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.
  • Note that there is a patch to TicketImportPlugin that imports WBS relationships. It is known to work with MasterTickets and Subtickets plugins and may work with others.

• The TimingAndEstimationPlugin can be the basis of recording estimates.
  • The plugin should be extended to support original and revised estimates, and to store default estimates in the database or configuration or derive them from history for experience-based scheduling, rather than have rules to use default values for tickets with tiny estimates.

• A simple Gantt chart can be implemented to show dependencies and schedule based on manually-entered due dates.
  • TracJsGanttPlugin provides such a display.

• Basic scheduling (ignoring resource conflicts and availability) can be provided based on:
  • core Trac tickets,
  • MasterTickets,
  • TimingAndEstimation, and
  • 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.

• We need a resource calendar plugin to allow describing resources and their availability. This should support notions of normal work hours, holidays, etc.

• Additional dependency types can be added, perhaps by enhancing or forking MasterTickets.

• Additional Gantt display options (e.g., critical path) can be added independent of additional dependency types.

• The scheduler can be enhanced to take into account resource conflicts.

Design

To maximize the flexibility in mixing and matching plugins to provide features for project management, I propose to leverage Trac's ​Component Architecture to specify a number of interfaces in a tracpm namespace. In this way a Gantt chart, a workload chart, a task scheduler, etc. can all use the tracpm interfaces regardless of whether, for example, Subtickets or Childtickets (or even ticket decomposition in a future Trac core) are used to represent parent/child relationships.

IProjectTask

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 TimingAndEstimation and another on top of TracHours.

An IProjectTask has the following properties:

id

Numeric ID, inherent in Trac.

work

Person-hours of work to complete the task. An integer.

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.

priority

Relative priority. An integer.

percentComplete

How much of work is done? This can be computed from time remaining vs. total estimate or time worked vs. total estimate. We will not, necessarily, store percent complete, but is rather a calculated field.

resource

Name of resource assigned to this task.

percentEffort

How much of resource's time is spent on the task.

duration

How long will resource take to complete work with percentEffort. For example, a 16-hour task with 50% effort will take 4 days.

assignedStart

An explicit, user-specified constraint on when the task must start. A date.

assignedFinish

An explicit, user-specified constraint on when the task must finish. A date.

computedStart

The result of scheduling this task based on constraints. Equals assignedStart if that field is set.

computedFinish

The result of scheduling this task based on constraints. Equals assignedFinish if that field is set.

dependencies

A list of other tasks (by id) and the dependencies of this task on them.

assignedStart and assignedFinish are likely mutually exclusive, that is, only one can be set; though both could be set if percentEffort was allowed to be computed.

Each dependency specifies:

task

The ID of the task this task depends on (I'd really like a better name here. parent is wrong. origin? other?)

type

Dependency type: FS, SS, SF, or FF.

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.

IProjectDependencies

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:

• Finding related tasks:
  • Finding predecessors (immediate and indirect).
  • Finding successors (immediate and indirect).
  • Finding descendants (children and further generations).
  • Finding ancestors (immediate and further generations).
  • Finding all related tickets (predecessors, successors, descendants, ancestors, and possibly those that share a resource).
  • Finding all the tickets due in a time range, begin..end.
    • If begin is not specified, all due by an end.
    • If end is not specified, all that start on or after begin.
• Manipulating task relationships:
  • Reparent B as a child of A (removing any existing parent). If A is None, remove B's current parent, if any.
  • Link B as a successor of A (same as making A a predecessor of B). Other dependencies are unchanged.
  • Unlink B as a successor or predecessor of A (order doesn't matter).

IProjectCalendar

The essential feature of a project calendar is that it knows when work is not done (weekends and holidays) so that task duration can account for that down time.

A slightly more sophisticated implementation would track individual resource availability so that the schedule can account for vacations and such.

An IProjectCalendar should provide the following methods:

Used to have startFromFinish() and finishFromState() here but those are likely scheduler functions. I think what we need here is hoursAvailable(resource, date) which a scheduler can call on each date and subtract the result from the work it is trying to schedule.

IProjectResource

Describes resource availability. May need calendar options for individuals. Some may want progress rates and costs, and some may not - this is surely controversial.

IProjectSchedule

Computing a schedule involves determining the computedStart and computedFinish for a set of tasks taking into account the dependencies between tasks, the resources assigned to those tasks, and the resource availability. Where the tasks do not have assignedStart or assignedFinish, the computed schedule prioritizes tasks to keep resources at or below availability. However, assigned dates may force overloaded resources. These overloads can then be reported and either manually resolved or resolved with a resource leveling module separate from the scheduler.

The following rules control the scheduling:

• Choosing a method:
  • If using As Soon As Possible, tasks without predecessors should be done done today (or the start of the project, if that's later), and their successors when they are done, etc.
  • If using As Late As Possible, tasks without successors should be done at the end of the project and their predecessors done right before they must start, etc.
  • It may be desirable to override the method for individual tasks so exploratory work is done ASAP and clean up work is done ALAP, regardless of the overall method being used.

• Handle assigned dates:
  • It is an error for a task to have an assignedStart and an assignedFinish.
  • If a task has an assignedStart, the computedStart is the assignedStart and the computedFinish is the computedStart plus the duration.
  • If a task has an assignedFinish, the computedFinish is the assignedFinish and the computedStared is the computedFinish minus the duration.

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.

• 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:
  • 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.
  • 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.
  • 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.
  • 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.

Note: The FS and SS dependencies are the most common and FF and SF are a nice-to-have.

• 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:
  • priority - More important/urgent work goes first.
  • risk - Riskier work goes first.
  • work - A function may favor short tasks ("low hanging fruit") or long ones (which inherently have more risk).
  • task type - Fix bugs before doing new features.
  • percentComplete - Finishing something that's partially done is better than starting something new.
  • "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.

Schedule Scenarios

It might be helpful 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.

Contributors

The bulk of this page was prepared by Chris Nelson who makes no claim to be a certified project planner. It is based on his understanding of project management after 25 years of software development.

Other contributors:

• Olemis Lang
• Greg Troxel

Reader Feedback

Suggestion(s) by Jay Walsh

While I like the idea of where you are going with this. The concepts and "design" section have taken a turn towards specific implementations. I would suggest a combination of making these ideas configurable, as well as extending various classes and providers to be extensible/replaceable.

First, thanks for the feedback. I'm not sure what section you mean when you say "concepts" and the design section is intended to describe extension points that provide a common interface to other PM-related components. -- CLN, 2011-08-02

I'm not sure where I was going with that, as I skimmed, I got the impressions some specific implementations were being incorporated. The ability to change these via extensibility is all I was commenting about. -- JW, 03 Aug. 2011

• For example, one may not want a "work" field, since man hours effort, in their project may have little value. Instead, they may wish to use "days" for calendar time, or "dollars" for contractor costs.

While I think Trac is heavily weighted to tracking work, being a little more abstract with what the estimate and progress are isn't a bad thing. -- CLN, 2011-08-02

• instead of "risk", one might want business value.

I envision the priority rule for scheduling being the most commonly replaced component. If risk doesn't mean anything to you, ignore it (or if risk is 0 throughout your project, it won't affect the priorities). -- CLN, 2011-08-02

The ability to replace it is always preferred if possible. "ignored" fields as just clutter. Look at some of the default trac fields that people happen to not use. there are plugins designed to hide them, just to make life easier. That said, your comment is valid. If taken into context with the later concept of somehow making a "provider" for where this value comes from, it could be used rather than ignored --JW, 03 Aug. 2011

• for any of this meta data, it would seem logical to support "Calculated fields" for the children, such as in the ValuePropagationPlugin

• Another area is the "providers" The ability to assign a provider to return the value in a custom or default field.
  • for example: % Complete, a straight calculation of hours done/hours total may work in most casts, for a specific case....one might need to provide it manually on some wiki page, which a provider looks up....., or something)
  • or a more pointed example, "calculated completion date", lets assume the company wants to use an ​Evidence Based Scheduling approach. in which case, they may also want to replace the Gantt views with the Probable Ship Dates graph? or maybe not.... The ability to do so would be key however.

It almost seems like any custom or default field added to this concept should be able to specify it's very own provider, optionally.

Can you say more about how that would work? Frankly, my knowledge of Trac internals grows slowly and as needed for my little bit of plugin programming. -- CLN, 2011-08-02

When I was typing that, I had in my mind the concept of how the TypedTicketWorkflowPlugin works. An .ini setting with additional data in the .ini value(s) that modify who/how that particular thing works. Not sure if that concept is something that can be applied here. Maybe something like the following:

[pm-config]
calc-end-date = custom
calc-end-date.provider = CustomCalPlugin
calc-end-date.params = %s

or maybe something like this?

[pm-config]
calc-end-date = custom
calc-end-date.format = dd-MMM-yyyy
calc-end-date.provider = ValuePropogationPlugin
calc-end-date.params = method:max,query:parent=self

Of course that example set is rather rough, hope it illustrates the thoughts. -- JW, 03 Aug. 2011

I specifically was of the line of thought that I would like to pull some of these values directly from my requirements specifications somehow, hence the lean toward some sort of configurable "provider" for the entries, as I have no idea how I would "pull" the data from the requirements at this point, other data from calculation and projections using different projection methods, as well as "override" capability where data is entered by hand sometimes. -- JW, 03 Aug. 2011

Third party software

There is a ​Google Gadget Gantt chart which might be used for the visualizations once the data is made available (e.g., using ​TracGViz plugin). That widget is developed and maintained by ​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.

​Planner is an open source project management program.

Gnome Office has a ​Planner, which is also ​forked.

​dotProject is an open-source, web-based project management system. A quick review suggests its task management isn't as good as Trac. It has a Gantt chart but ​wikipedia notes "as of version 2.0 the task dependencies feature is not complete". It has a troubled history but is forked as ​Web2Project.

The article ​15 Useful Project Management Tools mentions Trac. None of the tools obviously have scheduling in them.

​Jira sounded promising but doesn't seem to have scheduling. Their chart examples don't include a Gantt.

​Basecamp is popular and promising, but it is also commercial and doesn't support Gantt charting capabilities:

For years project management software was about charts, graphs, and stats. And you know what? It didn’t work. Pictures and numbers don’t get projects done. Basecamp tackles project management from an entirely different angle: A focus on communication and collaboration. Basecamp brings people together.

There is no automatic scheduling either. They have a nice feature where you can subscribe to milestone updates via iCalendar.

Also:

• ​Open Workbench is a Microsoft Windows-based application not suitable for integration with a web-based tool like Trac.
• ​GanttProject is a desktop application developed in Java.
• ​TaskJuggler is a free and Open Source project management tool, with a [TaskjugglerPlugin Trac plugin] to export to it.
• ​Virtual Planner (Pale Purple) is an alternative visualization tool.

References and Related research

Scheduling activities in a project is an area of active research in ​Operations Research (cf. ​Project Scheduling) and has been proven to be ​NP-hard, which requires enumerating all solutions to get to the optimal solution. If you have a small or dynamic project or if your estimates are routinely off by 5-10%, you won't see the benefit of mathematically optimal scheduling.

To be practical as a Trac plugin, the implementation should not require heavy-weight, opaque abstractions or multiple threads. Furthermore, we desire an algorithm which can update a schedule as part of a ticket change listener rather than having to completely recompute a schedule for each, individual change.

---

Old design notes (to be reworked in document)

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

What do we need in the user interface?

A "chart these" button on a report page would be very nice.

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.