Welcome to the Sporkforge.com project scheduler. This tool will generate an optimized schedule for your large-scale project (thousands of project tasks). It operates by first finding a schedule for your project which honors all scheduling and resource constraints (a "feasible" schedule), then attempts to optimize the schedule my minimizing the project's completion time.
Be sure to read and fully understand this important disclaimer before using this tool.
Contents:
The project scheduler takes two text inputs: the project specification, and an optional "Solution state data for incremental changes" value.
First a note about time values:
Times in the project specification and the solver output have the following format:
<day>-<hour>:<min>
So, for example, 5-11:00 means 11 am on day 5, and 3-18:45 means 6:45 pm on day 3. Note that the time line starts at 0-0:00 (12 am on day 0). 15 minutes is the smallest resolution the scheduler is implemented to handle, so any time not ending in :00, :15, :30, or :45 will be rounded up to the nearest 15 minute increment.
The largest valid time value is 999-23:45, which is the maximum time horizon for the scheduler.
The above represents points on the time line, however for time quantities such as task duration, setup time, etc., a number representing the number of hours is required. The same 15 minute increment resolution applies. For example, 3.25 represents 3 hours and 15 minutes.
The project specification defines the project in terms of a list of text blocks which define tasks and resource types.
Note that extra whitespace (spaces, tabs, and newlines) in the project specification text is ignored, so you may format the text as you please. Also, lines beginning with "#" are ignored, should you wish to insert comments or comment out portions of the text.
Tasks are defined by a name, a duration, a set of task dependencies which constrains when the task may start (i.e. tasks which must have started or have completed before work on this task may start, etc.), and a set of resources they need for work to proceed. There are also additional scheduling options.
The general form of a task block is:
task "<task name>" [task parameters] end
<task name> can be any name up to 256 characters long, as long as it is unique compared to the the names of other tasks.
Valid task parameters are:
This is the total number of resource hours required to complete the task.
If the task uses no variable-quantity resources, then the duration is the actual total time it takes to complete the task. If work on the task is scheduled over multiple (non-consecutive) time blocks, the sum of the lengths of those time blocks will equal the task's duration (minus any setup time specified via the setup_time parameter).
If the task does use one or more variable-quantity resources, then the duration is the total variable resource-hours required to complete the task, in multiples of the variable resource units specified.
For example, suppose a task has a duration of 10, and uses 1 variable unit of resource A and 2 variable units of resource B. If only 1 unit of resource A and 2 units of resource B are available when the task is scheduled, then the task will take 10 hours to complete. However, if 2 units of resource A and 4 units of resource B are available, then the task will only take 5 hours to complete (as there are 2 "units" of variable resources available).
The duration parameter is required.
This is the number of resource hours required to prepare for work on the task at the beginning of each scheduled time block of work. This can affect how "granular" the scheduling of this task is, as tasks with significant setup times would need to be scheduled over larger and fewer time blocks to minimize the total project completion time. Specifically, if work on the task is scheduled over N non-consecutive time blocks, then N times the setup time is effectively added to the project's duration.
If the task uses no variable-quantity resources, then the setup time is the actual total time it takes to prepare for work on the task at the beginning of each scheduled time block. If the task does use one or more variable-quantity resources, then the setup time is the total variable resource-hours required to prepare for work on the task, in multiples of the variable resource units specified.
The setup_time parameter is optional. When not specified, it defaults to 0 hours.
This parameter forces the scheduler to schedule the entire task over a single continuous time block.
The single_sched_segment parameter takes no arguments, and is optional. When not specified, the default is to allow scheduling over multiple time blocks.
This specifies a task dependency that constrains when the task may start, based on when task "<task name>" is scheduled and <criterion>, which may take one of the following values:
| completion | Task may not start until after task "<task name>" completes. | |
| start | Task may not start until task "<task name>" starts. | |
| start_plus <# hours> | Task may not start until <# hours> after task "<task name>" starts. |
The start_after parameter may be specified any number of times, once for each task dependency.
|
uses <# units> "<resource_type name>" <usage criterion>
This specifies a resource that work on the task requires. The task cannot be scheduled unless the resources it requires are available and not already scheduled to be in use by work on another task. <usage criterion> may be one of the following:
Note that if the task depends on more than one variable-usage resource type, then the same "scale up" multiple will be applied to all variable-usage resource types. Therefore due to resource availability constraints, the "scale up" multiple will be constrained by the most constrained resource type (the resource type with the smallest <# available units> / <# units> ratio). If a task depends on both variable-usage and fixed-usage resource types, the unit usage of the fixed-usage resource types remains the same regardless of any "scale up" of the variable-usage resources. |
This sets the minimum start time for the task, such that the task may not be scheduled to start earlier than <time>. This parameter is optional.
This sets the maximum start time for the task, such that the task may not be scheduled to start later than <time>. This parameter is optional.
Resource types are defined by a name and an "availability schedule", which is a schedule of unit quantities available over the project time line.
The general form of a resource type block is:
resource_type "<resource type name>" [availability settings] end
<resource type name> can be any name up to 256 characters long, as long as it is unique compared to the the names of other resource types.
[availability settings] specifies the unit quantity availability of the resource type over the time line. It is a sequence of overlaying quantity/time interval schedules of either of the following two forms:
The above statement sets the resource type availability to <# units> over the entire time line.
The above statement sets the resource type availability to <# units> over the given <start time>-<end time> period. If the optional [repeat_every <# hours>] portion is included, then a period of the same quantity and time length will be repeated after the initial period regularly on the time line, such that each successive period will begin <# hours> after the previous one started. Note that <# hours> must be greater that the length of the <start time>-<end time> period.
A resource type's availability is initialized to 0 units over the time line. Then each successive set_to statement changes the resource quantity to its specified quantity over the time periods indicated - that is, each set_to statement's usage schedule is "overlaid" over the previous availability time line. Therefore the ordering of the set_to statements matters.
For example, suppose that resource type "employee" has 10 units available every Monday-Friday from 9 am to 5 pm, except on the 23rd day which is a holiday.
One way to specify the availability of resource type "employee" would be as follows (assuming day 0 falls on a Monday):
resource_type "employee" set_to 10 from 0-9:00 until 0-17:00 repeat_every 24 set_to 0 from 5-9:00 until 6-17:00 repeat_every 168 set_to 0 from 23-9:00 until 23-17:00 end
The first set_to statement sets the available quantity of "employee" to 10 on a daily schedule. The second set_to statement sets the quantity to zero on the weekends. The third set_to statement sets the quantity to zero on the holiday. Notice that moving the first set_to statement from first place to second or third place would make the availability schedule incorrect.
Another way to specify the availability of resource type "employee" would be as follows:
resource_type "employee" set_to 10 from 0-9:00 until 0-17:00 repeat_every 168 set_to 10 from 1-9:00 until 1-17:00 repeat_every 168 set_to 10 from 2-9:00 until 2-17:00 repeat_every 168 set_to 10 from 3-9:00 until 3-17:00 repeat_every 168 set_to 10 from 4-9:00 until 4-17:00 repeat_every 168 set_to 0 from 23-9:00 until 23-17:00 end
Solution state data for incremental changesThe "Solution state data for incremental changes" is a string of characters that is displayed at the end of a previous scheduling run's output. It encodes the state of the previous solution that the scheduler can use in the next scheduling run. This is useful when making incremental changes to the project specification, as the scheduler uses a randomized process to search for optimal schedules, and there is no guarantee that it will generate an incrementally different schedule from the previously-generated one, even if the project specification has only changed slightly. The solution state data solves this problem by informing the scheduler of "where it left off" in the search space from the last run, so to speak. To use the solution state data from the last scheduling run, simply copy and paste the string of letters and numbers from the bottom of the scheduler output into the input text box. Do not worry about the formatting of it, or whether it's indented, etc. All whitespace (spaces, breaks, and newlines) will be ignored when reading the value. You need only include the entire string with everything in the same order it was printed out. If the solution state data gets accidentally changed, or if the project specification has changed too significantly since the run from which the solution state data was generated (for example, if the number of tasks has changed), then the solution state data will be discarded, and a warning message will be displayed to notify you. The scheduler would then proceed to schedule the project as normal, without using any previous state data. |
If the project fails to find a feasible schedule, either due to overly restrictive constraints, or another problem such as a cyclical dependency, the scheduler will exit and display information which can help resolve the problem - for example, the scheduler will attempt to identify tasks which it has problems scheduling and inform you of them. It will also inform you of any incremental changes to the project specification that could be made which would result in a feasible schedule (when using the provided "Solution state data for incremental changes").
If a feasible schedule is found, then the results will be displayed in four main sections:
This section states the number of tasks and resource types in the project, and the resulting project completion time of the schedule. It also gives the total number of hours scheduled for all project tasks.
In each row of this section is the schedule for each task, listed in the order they appear in the project specification. If the task was scheduled over a single time block, then a single time range will be displayed in the format <start time> - <end time>. If the task was scheduled over multiple time blocks, then multiple time ranges will be displayed, separated by a semicolon.
For each resource type, the total unit-hours scheduled will be shown, as well as a schedule of unit allocations to each task that uses that resource type.
Once the scheduler has completed optimizing the schedule, it will proceed to make small, individual variations to the project specification and recalculate the resulting project completion time. It then reports all such "incremental" changes that result in an earlier project completion time. This will give you ideas as to how to shorten the project's time to completion. Remember to copy and paste the provided solution state data into the "Solution state data for incremental changes" input box to reproduce the shortened project completion results.