The Overdrive option on the member availability setting tells the scheduling engine to turn off load balancing for that resource. The effect is that all tasks assigned to an overdrive resource will start on the current date unless the task is pushed out by delays or dependencies. Availability is still respected in terms of days of week and hours per day.
Resources that have overdrive scheduling enabled are identified on the People tab member list in the availability column. Click on the member name to jump over to their profile and turn Overdrive on or off via the checkbox in the availability section:
To see the effect of an overdrive resource on scheduling, let’s look at a schedule with a virtual member called Contractor. In the image below, overdrive is not turned on for the Contractor, so their work flows out as you’d expect — they needs to finish their higher priority task (Task 2) before their next task (Task 4) starts. The orange line shows that the expected finish date for the entire project is being driven by Task 8.
Now let’s take a look at that same plan with overdrive turned on for the Contractor virtual member. Notice in the image below that they are now scheduled to start all of their tasks on the current day. Look closely at the timeline and you’ll see that the project will also be done sooner. The finish date for the project is now being driven by Eric’s work (Task 7), since the Contractor’s work will be completed earlier.
When to Use Overdrive
Use overdrive to model work that is being done by a pool of always-ready resources. In the example above, let’s suppose that we have engaged a team of contractors who have guaranteed us that somebody will be available to start each contractor task immediately when the task is assigned to them. We don’t know or care which specific contractor will do each task, so it’s easiest to assign all of those tasks to just one virtual member that is set to overdrive.
Availability still counts. The availability setting on an overdrive resource tells LiquidPlanner how many hours per day that resource can put toward the assigned tasks. This is no different than a non-overdrive resource. LiquidPlanner calculates a range of task finish dates in accordance with the task effort and the owner availability. The difference is that other tasks assigned to the overdrive resource are not factored into the equation. This is demonstrated in the example below in which the Review Board resource has been set to overdrive, which allows us to model work being done simultaneously on two tasks.
Here is another example, where dependencies are used in conjunction with overdrive to model a process flow:
- In the scenario above, Haley creates a proposal draft and sends it out to an external review board. The board must review the draft and get it back to Haley within 8 hours, at which point Haley must start creating the next draft. And so on.
- We know that somebody is always available to start the review as soon as Haley hands off a draft. Again, we don’t know or care who will do each review, so it’s easiest to assign all of the review tasks to the same virtual member, which is set to overdrive.
- Dependencies are used to ensure that one task can’t start until the previous task is finished.
Use overdrive scheduling to model work done by machines. Let’s say you need to account for the time it takes to print brochures, programs, and booklets at a nearby printing company. Since the printing company can print as soon as they receive an order, overdrive scheduling can be used to model a group of tasks scheduling at the same time.
To set this up, create a virtual member to represent the printing machines and enable overdrive scheduling in the virtual member profile. Next, assign each printing task to the virutal member machine and see how these tasks can overlap and schedule simultaneously. Use dependencies if the printing tasks cannot begin until another item is marked done.
Virtual vs. Real Overdrive Resources
In our examples above, the Contractor and Review Board are virtual members because they are external resources who should not have access to any part of the plan.
There might be cases where you’d prefer to use a real member instead of a virtual member. For example, a full (or restricted) member might make sense if you want a trusted representative of an internal or external resource pool to sign into your workspace and make updates to all of the tasks assigned to them. A portal guest makes sense if you want to collaborate with the person, but you need tighter control over what they can see and edit.