jxProject.com
|
|
- Overview
- Gantt
- Resource
Scheduling - Date & Timeline
Formatting - Resource
Leveling - Printing
and HTML - Activation &
Proxy Settings - Sponsor
Updating - Problems and
Solutions - Quick Start
Editing - PDF Documentation
JxProject 2.6.1.2 – Resource Scheduling
User Documentation
September 21, 2011
Schedule: The resource scheduling capabilities of jxProject are both flexible and powerful and thus they are somewhat more complex than other project management tools. You would be well served to literally memorize the architecture and principles which are explained in this section. All of the scheduling of calendars and resources is done using “rules”. The rules are mildly complex however when you combine the importance of the order of the rules along with the interaction between resources and parent calendars, it can get very confusing. Be sure to ground yourself with a solid understanding of the principles governing the interaction of Calendars, Resources, Rules and Segments.
Figure 1: The Calendar/Resource Schedule Interface
The labels used in describing the basic components of the jxProject interface in Figure 1 will be used consistently throughout this document.
Elements of the Schedule Chart: The tree table and the Schedule Chart are closely related and only serve as alternative visual representations of the exact same data. Each row in the Table represents the data in the same row in the Chart to the right. Each day is represented as a full 24 hour period starting at midnight. Time which is scheduled as work or non-work time is shown for each day and is coded as follows.
Work Time: This is represented as solid green with no outline.
Non-Work Time: This is divided into paid and non-paid. Both of these time types have black outlines but the fill color for paid is green while the fill color for non-paid is gray.
Chart Background: Areas of the chart which are colored gray are the days which contain no scheduled work time as defined by the “Base Schedule”. The Base Schedule is explained below.
Chart Header: The header defines the dates of the period of the schedule you are viewing. The upper scale is denoted in weeks and the lower scale is in days. You can stretch and shrink the time scale by pressing the (keyboard shift key and the right mouse key on the chart header) simultaneously and dragging it to the right to stretch the scale and the left to shrink the scale.
Chart Pan Scrolling/Auto scrolling: Pan scrolling the chart is activated by single clicking on the table with the middle mouse button. The pan scroll will work for any component inside a scroll pane and gives the user the ability to fly over the component.
Elements of the Tree Table: A tree table is what you get when you cross a traditional GUI table with a traditional GUI tree. It’s a table with expandable collapsible nodes. The furthest left column of the tree table is the “key” field and it can never be scrolled out of view. Every other column in the table can be scrolled and the order of the columns can be changed by dragging the columns into different positions using the column headers. The Tree Table contains nodes of two different types which are Calendars and Resources. The descriptions of the fields in the table are often similar between the two but not exact. Now a few definitions:
Key: Each Node is assigned a unique key when it is created. However, you can renumber them by “right clicking” on the header which will bring up a single option popup-up menu to renumber the nodes.
Show: This is purely a diagnostic tool to assist you in identifying which rules are driving which parts of the schedule. It is the only field in this table that is editable. If this is unchecked, all of the rules defined in that node are no longer displayed on the chart. Also, any nodes underneath the node, which inherit their scheduling from the node, are not displayed. If you load up this example and uncheck the Zulu node, you will see a lot of the schedule disappear. That is because most of the nodes are inheriting their schedule from the Zulu Calendar. Whether these flags are on or off has no effect on the schedule used in solving the project plan.
Name: Calendars have a single name while Resources are listed as last, first, initial. If you type a name into a blank field a resource will automatically be created.
Rules (count): This is the number of schedule rules which are associated with this node.
Time Zone: This is a description of the time zone which governs this node which includes its offset from Greenwich Mean Time as well as general description of the areas of the globe which use that time zone.
Tree Table row header: You can increase and decrease the table row height by pressing the (keyboard shift key and the right mouse key on the row table header) simultaneously and dragging it towards the bottom to increase the row height and towards the top to decrease the row height.
Table Pan Scrolling/Auto scrolling: Pan scrolling the tree table is activated by single clicking on the table with the middle mouse button. The pan scroll will work for any component inside a scroll pane and gives the user the ability to fly over the component.
Key Components of the Schedule: Every schedule for every project must contain the Zulu (GMT 00:00) Calendar as the root node and a Default resource. Each project must also contain a node (Resource or Calendar) which is designated as the Base Schedule.
Calendar: A Calendar can have its own time zone and can have an unlimited number of Calendars and Resources underneath it. However, only Calendars which are directly underneath the root Calendar or Zulu Calendar can have their own time zones. A Calendar that is more than 1 level deep must inherit the time zone from its parent Calendar. In our example above, the “Part Time” Calendar gets its time zone from the Silicon Valley Calendar.
Resource: A Resource always inherits its time zone from its parent Calendar. A Resource cannot have any nodes underneath it.
Zulu Calendar: This is always the root Calendar and it has a fixed time zone of GMT+00:00. You can add or remove Rules from the Zulu Calendar and all nodes underneath Zulu will inherit those Rules.
Base Schedule: There must be one and only one node designated as the Base Schedule, and it can be any Calendar or Resource which resides in the table. The Base Schedule determines the point of view from which the entire project plan is viewed. All dates in the schedule and Gantt interfaces are presented in the time zone of the Base Schedule. Also, the days which are determined to be “non-work days” are determined by the Base Schedule and appear as gray days in the chart backgrounds. In our example above the Base Schedule is the Calendar named “Silicon Valley”. You can set the Base Schedule by right clicking on the name of the node, you will get a pop-up menu with one option which is “Set as Base Schedule”, click that option and you’ll see the red arrow move to your selected node.
Default Resource: There must be one and only one Resource designated as the Default Resource. It is designated by an icon of a “juggler” and it has a single rule to work Monday through Friday 8 hours per day (40 hours per week). You cannot edit the Default Resource although you can drag and drop the Default Resource to change the parent Calendar in which the Default Resource is scheduled to work. Any tasks which have no resources assigned to them automatically utilize the Default Resource schedule to satisfy the Resource constraint requirements.
Rule: All Calendars and Resources can have an unlimited number of scheduling rules except, for the Default Resource. Rules define a start and end time in days and contain filters for days of the week. Rules can contain zero or more Time Segments.
Time Segment: Segments range from zero to 24 hours in total duration and one Time Type per Segment.
Time Type. There are three types: Work Time(green), Non-Work Time (paid)(black outline; green fill) and Non-Work Time (unpaid)(black outline; gray fill).
Have you memorized all of this yet? ;-) I’m only giving you definitions at this point, next I will go over the pieces of the interface and then I will give you a little story of how I expect you to use this interface. I’ll even tell you some of the “gottchas” to be careful of. You need to know all of this by heart to master jxProject. There really isn’t anything you can afford to not understand if you want to build an accurate project plan using this tool.
Title Bar:
The
title bar contains the jxProject logo/icon followed by the file name
which is currently open. Only one file can be open at a time.
Menu Bar:
The
menu bar consists of drop down menus which provide access to most of
the functionality in jxProject. Each of the menus is shown and
outlined below.
|
|
|
|
|
|
|
|
|
Tools Menu: See The document for documentation on the tools Menu and the Global Options Dialog. |
|
Documentation: Nothing will happen, not implemented yet.
|
File
Menu:
Edit
Menu:
View
Menu:
Insert
Menu:
Help
Menu:
1. Start: This is the Month-Year that will be the leftmost part of the chart. It always starts at the first day of the month.
2. Duration Years: This is the number of years to view in the chart. The range values is 0.1 to 4.0 years; the default is 1.0.
3. Gantt View: Switch the display to the Gantt View.
Lower Tool Bar:
The
Schedule is mostly independent of the project plan. You can
view the schedules of your Calendars and Resource for hundreds of
years into the past or future if you like. The default start
date will be near your project start date but you can change this to
anything time you wish to see.
Outdent: see Menu Bar > Edit > Un-Indent Selection
Indent: see Menu Bar > Edit > Indent Selection
Undo; see Menu Bar > Edit >Undo (Note: Graphic needs updating)
Redo; see Menu Bar > Edit >Redo (Note: Graphic needs updating)
Zone Aware: If this is checked, then Chart areas will shift to their respective time zone offset relative to the Base Schedule. Load the example file above and click this button on and off to see what I mean. This is just used to help you with visualization of how teams in different time zones overlap or don’t overlap their work time schedules.
|
|
|
Tree Table Interaction:
|
|
|
|
|
Resource
Utilization: This screen shot shows the schedule view with
tasks and summary tasks being displayed with the time segments
rendered on top of the tasks. The height of the rows has been
increased so that the task keys and descriptions are readable.
Tasks where the resource is less than 100% dedicated have a solid
triangle painted in the upper left corner of the task. Summary
tasks have a black outline and tasks have a blue outline.
Basically this is a custom Gantt chart for each person on the
project. Tasks which are associated with the default resource are
not displayed or resource leveled. If resource leveling is
enabled, it is impossible to over allocate resources.
Table
row header:
Dragging and Dropping: Using drag and drop it is possible to move or copy Calendars and Resources to/from the TreeTable to/from the chart..
TreeTable: To initiate a drag, select one or more rows using the row header to select the entire row. Then press and drag the left mouse button on one of the selected rows from the row header. If the drag gesture is recognized, your cursor will change to reflect the type of drag operation that has been initiated. The default drag is a move, if you hold down the control key while initiating the drag, the operation will be a copy. A copy cursor has a “+” sign on it. When Resources are copied, the tasks which were assigned to the original resources are not assigned to the copied resource(s). Be aware the time zones of copied calendars or resources can change based on their level within the hierarchy.
Chart: To change resource assignments, select the task, the press down with the left mouse button on the body of the task and drag the task and drop it on a different resource row in the chart to move the task. Hold the cntrl key down during the drag/drop operation to copy the task to another resource.
Schedule Chart Interaction:
·
Schedule chart header: The header defines the dates
over which the chart starts and ends. The upper scale is
denoted in weeks and the lower scale is in days. You can
compress and expand the time scale by pressing the keyboard shift key
and the right mouse key on the chart header simultaneously and
dragging it to the right to expand the scale and the left to compress
the scale. As you expand/compress the time line it will automatically
change formats to suit the level of scaling. There are at least 20
preset formats for the header and they can be fully customized by the
user by the time line format dialog. Right click on the header and
select “TimeLine Format...”, and a dialog for customizing
the format will be displayed. See the chapter on Date Formating and
TimeLines for more details. Note: The row height can be adjusted in a
similar manor, see “Table Row Header” for specifics.
Chart Interaction: The user can alter the duration and resource assignments of the tasks from the chart. To alter the duration select the task, then press down with the left mouse button on the right end of the task and drag left or right to alter the duration of the task. Drag and Drop of the tasks on the chart is also supported, see above.
Task Edit Dialog: To initiate this dialog, double-click on a task in the chart. See the Gantt Chart documentation for images and specifics on the operation of this dialog.
Schedule Edit Dialog: To initiate this dialog double click on the “Key” field of the Calendar or Resource you want to edit. Or double-click on a blank space on a row in the chart. This dialog is the only way to edit most of the data associated with a Calendar or a Resource. This dialog has three tabs which are: “Resource”, “Calendar” and “Rules”. When this dialog is open, some of the buttons and other capabilities of the Schedule are disabled. I’ll leave it as an exercise for the user to discover what you can and cannot do. But you can double-click on another row in the table and load it into the dialog. You don’t have to close the dialog to change Nodes. If you have edits pending in the dialog, and you try to change selected nodes, you’ll get a warning to save or cancel your current changes.
|
|
|
|
|
|
|
|
|
Rules Table: This contains all of the rules defined for this Calendar or Resource. The order is always sequential and rules can overlap each other. The rule furthest to the bottom of the list takes priority in an overlap situation. The active field says whether the rule is active or not; inactive rules to not participate in any scheduling. The String field does nothing, I had an idea for it at one time but this will probably go away or be replaced with something else. The rules can be reordered by drag and drop.
|
|
Gotchas: Make sure you have the “days” selected that you want to rule to apply on. It’s very easy to make a mistake by focusing on the start and end dates and cycles and forget to filter for the correct days of the week. Schedule Edit Dialog Buttons:
|
Figure
1: Schedule Edit Dialog (Resource Tab):
Figure
2: Schedule Edit Dialog ( Calendar Tab):
Figure
3: Schedule Edit Dialog (Rules Tab)
If you’ve read through all of this excruciating detail up until now, I wouldn’t be surprised to find you passed out on the floor blowing bubbles. I’ve written the above material in a reference fashion so you can refer to it in the future without having to wade through dialog that you don’t need. Now we are going to get into how all of these little pieces fit together to form a schedule.
Review:
Calendars and Resources exist in parent/child relationships. Calendars can have Calendars and/or Resources as children but Resources cannot have any children.
The schedule of Calendars and Resources is determined by the Rules which they contain and the Rules which their parent Calendars contain. Rules can and often do overlap each other. The Rule that is farthest down in the hierarchy and list order has the highest priority in an overlap situation!!!
Rules contain zero or more Segments. (A Rule should always have at least one Segment; zero is a mistake really). In order for a rule to be enforced for a particular date, it must be active, the date must be between (inclusive) the start and end dates of the rule, the “day of the week” for the date must be selected for the rule, and the rule must not be overridden by another rule which is lower in the hierarchy/list and satisfies the active, start, end, day-of-week requirements.
Segments define a time type and a period of time within a 24 hour period. Segments cannot overlap and always appear in early to late order. If you define the Segments in an unordered or overlapping fashion, jxProject will immediately sort the segments and remove any overlap. It’s kind of unfriendly that way but it removes ambiguity.
Recommendations on how to organize your Rules to build Schedules:
You want to put your most basic scheduling rules inside Calendars and as high up in the hierarchy as possible. For example, if you regular work week is Monday – Friday 8 to 5; put that rule up in the Zulu Calendar so everything can inherit that Rule.
You should group people that have similar schedules together under Calendars. In our example project, the “Silicon Valley” team and the “Koblenz, Germany” team belong to separate Calendars. This is needed in order to give those people separate time zones but also to accommodate different Holiday schedules. Also, notice the “Silicon Valley” Calendar has a Calendar underneath it “Part Time” which schedules Monday and Wednesdays as non-work days to override the 40 work Rule. The result is that the Resources under the “Part Time” Calendar are only scheduled to work 24 hours a week; Tuesday, Thursday and Friday.
Put your Holidays, such as Christmas, just below your 40 hour work rule inside a Calendar. The “Silicon Valley” calendar has several Rules defined for North American Holidays.
Resources will usually only contain Rules which schedule non-work time to override the regular 40 hour work rule. These would typically be to schedule vacations or account for personal days off.
Be descriptive with the names of your Rules to assist in troubleshooting should the need arise. If you are scheduling a week of time off to go bike riding in August, call it the “5 days August biking” Rule.
Test your Knowledge:
How many Rules would be required to establish a schedule where a group of three people worked Tuesday and Thursday from 9am to 5pm and Monday, Wednesday and Friday from 6am to 3pm? Answer: 2 Rules.
How many Rules would be required to schedule a person as on Vacation for one day? Answer: 1 Rule
How many Rules would be required to schedule a person as on Vacation for Thursday, Friday and Tuesday where Saturday, Sunday and Monday were already scheduled off by the parent Calendar? Answer: 1 Rule – Define the Rule for the period of Thursday through Tuesday and only select the days Thursday, Friday and Tuesday as the days-of-week for enforcement.
Can you define a Rule with no Segments? Answer: Yes, but it would have no effect on the Schedule.
Can you define an active Rule that has valid defined Segments but has no effect on the Schedule? Answer: Yes – If you do not select any of the days-of-the-week it would be the same as no Rule at all.
Could you define a single rule that Schedules a person for time-off every fourth week on Friday and Monday for the next six months? Answer: Yes
Can a single Rule that has 3 Time Segments enforce only 1 of the Segments on a particular day? Answer: No – When a Rule is enforced all of its Segments are used on that day that it is active.
Techniques for Trouble Shooting Schedules:
After implementing your schedules you should always confirm your schedule is correct by closely reviewing the schedule chart for each of your Resources over the period you expect your project to run. If you find the schedule does not reflect what you think it should, you are going to need to do some investigation. Because rules are inherited and do override each other things can get confusing. There are diagnostic tools built in to help you isolate the problem.
Let’s say you find a day for one of your Resources that are scheduled as paid-time-off but should not be. How do you find where this is coming from? First you need to find the Rule responsible for this “day off”. It has to be coming from the Resource its self, or one of the Resource’s parent Calendars. Toggle off the “show” checkbox in the Tree Table for the Resource and parent Calendars until this particular day off disappears. That will tell which Node owns the Rule that is scheduling the day off. Now toggle the show button to “on” and open up the Schedule Edit Dialog for that Node to review the rules. You could work in a brute force fashion and select each rule, make it “inactive” and press the “apply” button. This will turn off the rule and update the schedule. When you see the day off disappear, then you’ve found the rule that’s causing that day off. You’ll need to take it from here to resolve the problem.