Packages

Packages can be used to create priority overrides for individual tasks to facilitate cross-project prioritization, or they can be used to prioritize entire projects.  Packages are created via the add menu in the Projects view, or via the right-click menu.  Packages can live at the root of your workspace or within other packages.   In order to nest packages, you need to drag and drop the intended sub-package on top of the intended parent package.  

Packaging tasks for cross-project prioritization

When you're scheduling concurrent projects, the package essentially functions as a “to do” list from across your projects.  Let's look at a very simple example.  All work is assigned to one person in this example in order to emphasize the schedule behavior:  

In our starting plan above, tasks are scheduled (as always) in the order in which they're listed.  You can see that the Website Project starts and finishes before the Brochure Project starts.  The problem is that many people don't have the luxury of working one project at a time in sequential fashion like that.  The reality is that you're probably moving between tasks from different projects all the time.  To model that, you need to use packages, like so:

In the modified plan above, we created a package called ASAP above the projects.  Then, we dragged one task from each project up into the ASAP package.  This is called "packaging a task".  We listed the tasks in the ASAP package in the order in which the work needs to get done - priority order.  The schedule is now calculated so that all of the tasks packaged into ASAP get scheduled first (in order as listed), then the non-packaged tasks get scheduled in the order in which they're listed. 

Here are some things to know about packaging tasks:

• You can package a task by dragging and dropping, or by right click > change package, or by choosing the package in the task's edit pane:

• A packaged task is represented twice in your plan.  The task's priority position drives the schedule date.  That's the packaged task.  The breadcrumb next to this task shows you the project that the task was packaged in from.
• The task's placeholder position continues to represent the packaged task within the project structure. The breadcrumb for this task shows you the package that the task was packaged out to. 
• When you look at the project structure (the blue project folder), individual tasks are listed in the order that reflects their priority position relative to each other.  If packaging a task causes that order to change, the packaged task will shift to the appropriate new position in the project structure to reflect that change.  We call this concept magnetism.

Using packages for concurrent project management

When you are juggling concurrent projects, you'll likely need to package tasks into a more extensive package structure.  Take a look at our Multi-Project Scheduling help article for additional detail.

Packaging projects

Packages can also be used to group entire projects together.  If you have a list of 30 projects, it can be nice to put some organizational structure around them.  For example, you might nest projects into quarterly packages, or active projects vs. backlog packages, etc. 

Best Practice Tip:  notice in the screenshot above that the packages we use to group projects live separate from, and below, the packages we use to establish priority overrides for individual tasks.