Freezing your project as it progresses

During the planning phase of the project you want to specify as little as necessary and have TaskJuggler calculate the rest of the project variables. As the project progresses, more and more variables turn into constants. Whenever this happens, you should tell TaskJuggler about it. If you don't do this, TaskJuggler will assume that it has full freedom to pick these values and you will end up with a project plan that has nothing to do with the past part of the project. Especially when you have a fairly dense resource allocation, the plan will become very dynamic. Small changes in the plan can result in a significantly different scheduling result. The scheduling algorithm that is used by TaskJuggler is fairly complex and always tries to achieve the best possible result. It does not know that you have scheduled the project before and expect a similar result after the changes. The result is always correct according to the specification you have entered, but it can differ a lot even after fairly small changes. That is why you have to tell TaskJuggler when scheduled values have become reality and are no longer flexible.

Once a task has been completed it is a good idea to remove the allocation statements from this task to prevent accidental resource allocations when the bookings don't exactly sum-up to the required effort. If you have specified all work on a task by bookings, you could also remove any hardcoded start and end dates as well as dependencies, but this is not required. You just have overspecified the task. In case you have made contradicting statements, TaskJuggler will issue an error message. This is for example the case when you have a fixed start date and a booking that starts earlier than this start date.

In general it is perfectly ok to overspecify your project. For example, you can have a fixed start date on a task as well as a start dependency. As long as they don't contradict each other, they can peacefully live together and you can use them as additional check points.

The following example contains the minimal elements to freeze your project as it progresses.

project prj  "Project" "1.0" 2000-01-01-0:00-CET - 2000-03-01-0:00-CET {
  timezone "CET"
  now 2000-01-08
  scenario plan "Plan" {
    projection { strict }
  }
}

resource r "Resource"

task t "Task" {
  start 2000-01-01
  effort 10d
  allocate r
}

# Include the data from previous scheduling run.
# We assume that the exported data has been frozen.
# By importing it, we make sure they don't get changed any more.
include "CompletedWork.tji"

# Export only bookings for 1st week as resource supplements
export "CompletedWork.tji" {
  start 2000-01-01
  end 2000-01-08
  properties bookings
  hideresource 0
}

The now property is only used to illustrate that we want to freeze the project one week after it got started. The scenario definition is necessary to switch the scheduler into projection mode. It will then assume that all resource allocations prior to the current date have been specified. It will only allocate resources after that date on its own. The export report outputs all allocations for the time prior to the current date. These are either the allocations generated by the scheduler or the ones that are provided in the included file. But keep in mind that the scheduler only generates allocations after the current date. So, when you start the project with an empty include file, you need to set the now date to the start of the project. Even though the include file gets rewritten every time you regenerate the reports, changes you have made in this file will not get lost. TaskJuggler will always include the current version prior to rewriting the file with potentially extended information. Therefore it is possible to start with a generated version of the allocations and then modify them to reflect what really happened.