In the default Gantt Chart view, Microsoft Project automatically displays a Duration column to the right of the Task Name column. So, a good question to ask is, “What is Duration?” According to the Project Help article about Duration in Microsoft Project 2013, Duration is “…the total span of active working time for a task. This is generally the amount of working time from the start to the finish of a task.” There are other ways to describe Duration as well. For example, I like to describe Duration as the “window of time” during which work is performed on a task.In Microsoft Project, the Duration field is an unusual field because the software allows you to do either of the following:
- Manually enter a value in the Duration field
- Assign a resource to a task, enter a Units value and Work value for the resource, and then let the software calculate the Duration for you
If you want to manually enter a Duration value for a task, Microsoft Project allows you to enter the Duration value in the following time units: Minutes, Hours, Days, Weeks, or Months. For example, Figure 1 shows a project in which I entered a Duration value using each of these time units.
Figure 1: Duration values entered for tasks
There is no problem with manually entered Duration values. In fact, in some companies the preferred methodology during task planning is to estimate task Duration values. The only “gotcha” about which I want to warn you is when you enter a Duration value in months. What is a month? To most of us, we would assume that a month is the span of working time from the first day of the month to the last day of the month. Using December 2014 as an example, we would assume that a month would run from Monday, December 1, through Friday, December 31. Unfortunately, this is not how Microsoft Project thinks about months.
In all versions of Microsoft Project, including the 2013 version, a month is defined by default as a time span of 20 working days. To see this definition in Microsoft Project 2010 or 2013, click the File tab, click the Options tab in the Backstage, and then click the Schedule tab in the Project Options dialog. In the Calendar options for this project section of the dialog, the software includes the Days per month field. Notice in the Project Options dialog shown in Figure 2 that the default value is 20 days in the Days per month field. In other words, to Microsoft Project, one month is equivalent to four work weeks or 20 working days. You can actually see this if you refer back to Figure 1 and look at the schedule of the Task E task, which is 1 month.
Figure 2: Days per month setting in the Project Options dialog
In Microsoft Project 2013, the software will allow you to change the value in the Days per month field to a maximum value of 100 days! This makes no sense, by the way. In the real world, we normally change the value in the Days per month field to either 21 days or 22 days as needed in each project. Because Microsoft Project’s definition of a “month” is so rigid, I want to warn you about entering Duration values in months. Rather than entering Duration values in months, I would recommend that you enter Duration values in days or weeks instead to give you the flexibility you desire.
Leading Practice: When you manually enter Duration values, I recommend that you be consistent in your use of time units. For example, enter all of your Duration values in Days or Weeks, but do not mix Days, Weeks, and Months in the same project as this can lead to confusion with your team members and project stakeholders.
Understanding Elapsed Durations
When you enter a Duration value for a task in Microsoft Project, the software always calculates the schedule of the task in working days. For example, a Duration value of 10 days indicates a time span of 10 working days, calculated according to the schedule of the Project Calendar specified for your project.
The software gives you an additional method for entering Duration values known as “elapsed Durations.” When you enter an elapsed Duration value for a task, Microsoft Project calculates the schedule of the task in calendar days, and ignores all nonworking time such as weekends and company holidays. For example, an elapsed Duration value of 20 days means 20 calendar days, including weekends and company holidays.
You can enter elapsed Duration values in minutes, hours, days, weeks, or months. To enter an elapsed Duration value, simply prefix the time unit with the letter “e”, such as 5 eDays. By the way, most people enter elapsed Duration values in days. For example, suppose that I have a task named Ship Equipment to India and I expect the task to complete in 4 calendar days. In this case, I would enter the Duration value as 4 eDays. This means that if I ship the equipment to India on Friday, it will arrive the following Monday because the elapsed Duration includes the Saturday and the Sunday. In situations like this, using elapsed Durations can be a very useful technique for scheduling your project. However, I also want to warn you about two possible negative consequences with using elapsed Durations in your projects:
- Elapsed Durations are measured in 24-hour days, not 8-hour days.
- Entering a Duration value in eMonths may not generate the schedule you expect.
Because Microsoft Project measures elapsed days as 24 hour days, this means that if you assign a human resource to a task with an elapsed Duration value, the software assigns the human to work 24 hours/day, even though the resource’s calendar shows that they only work 8 hours/day. For example, notice in Figure 3 that I assigned Mickey Cobb to work full time (the Units value is 100%) on the Task A task which has an Duration of 5 eDays. Notice in the Task Form pane that Microsoft Project calculated that she will perform 120 hours of work during those 5 elapsed days, rather than the 40 hours we might expect. Because of this, I strongly recommend that you never assign human resources to tasks with an elapsed Duration.
Figure 3: Resource assigned to a task with an elapsed Duration
If you enter a Duration value in elapsed Months, Microsoft Project always measures the elapsed month as exactly 30 calendar days. This means if you schedule a task to start on February 1 with a Duration value of 1 eMonth, the task ends in March and not on February 28 or 29 as you would expect. If you schedule a task to start on December 1 with a Duration value of 1 eMonth, the task ends on December 30, not on December 31. You can see this in the schedule of the Task B task shown previously in Figure 3.
To make matters worse for us when using elapsed Durations, there is no setting in Microsoft Project (not even the Project Options dialog) where you can change the definition of an elapsed Month. This means that the software will always calculate an elapsed Month as 30 calendar days and you cannot change it. Because of this inflexibility, I do not recommend you use elapsed Months as Duration values. Instead, focus on using elapsed Days or elapsed Weeks rather than elapsed Months.
For even more information about using Microsoft Project, be sure to download a set of our Microsoft Project 2013 reference cards by clicking the Download Now.
Interested in how EPMA can help your schedules? Contact us today at 1.888.444.EPMAor enroll for one of our training classes.
Please feel free to leave comments below or check out our other blogs on Microsoft Project, Project Server, SharePoint and Project Management Methodology.
Follow us at @EPMAinc, linkedin, or facebook
In order to ensure compliance policy requirements are met within the messaging environment, messaging data must be classified and maintained for periods of time based on the classification level.
In Exchange 2003, the Mailbox Manager provided a means to delete messaging data, including calendar and task objects. Mailbox Manager was limited in its ability, however:
- The Mailbox Manager would ignore and not delete any appointments if they were tagged as recurring, regardless of end date, start date, sent date, or last modification date.
- The Mailbox Manager would ignore and not delete any tasks that were not marked as completed.
In Exchange 2007, Mailbox Manager was replaced with Messaging Records Management (MRM). Managed Folders, the feature in Exchange 2007, enabled customers to apply retention settings to default folders, such as Inbox and Deleted Items, and also deploy custom managed folders. Users would sort their messages by placing them into different managed folders, with each folder having a different retention setting. With respect to the calendar and tasks folders:
- Non-recurring calendar items expire according to their end date. Recurring calendar items expire according to the end date of their last occurrence. Recurring calendar items with no end date do not expire.
- Non-recurring tasks:
- A non-recurring task expires according to its message-received date, if one exists.
- If a non-recurring task does not have a message-received date, it expires according to its message-creation date.
- If a non-recurring task has neither a message-received date nor a message-creation date, it does not expire.
- Recurring tasks expires according to the end date of the last occurrence. If a recurring task does not have an end date, it does not expire. A regenerating task (which is a recurring task that regenerates a specified time after the preceding instance of the task is completed) does not expire.
Messaging Records Management in Exchange 2010
Exchange 2010 introduced Messaging Records Management 2.0 and the Retention Policy framework. The framework consists of retention tags and retention policies. Retention tags are used to apply retention settings to messages and folders. A retention policy is a group of retention tags that can be applied to the mailbox. The use of the word “retention” in this 2.0 naming convention is misleading. In addition to controlling when items are expired out of the mailbox, retention tags can also be used to control when items move to the archive .
With Exchange 2010 , SP1 and SP2 through SP2 RU3, MRM 2.0 does not provide support for assigning retention tags either directly to calendar and task items or to the calendar and tasks folders. Many of you, our customers, have spoken to us about the need for this functionality and see this as a takeaway when compared to previous versions of Exchange.
In the end, compliance requirements need to be met. Excluding calendar and task items from the retention policy framework means that customers that have business and/or legal compliance policies for managing data are unable to guarantee the requirements are met.
Calendar and Tasks Support in Exchange 2010 SP2 RU4 and later
In Exchange 2010 SP2 RU4, we’ve added support for Calendar and Tasks folders to Retention Policies.
If you currently use or plan to use Retention Policies, this has important implications for your messaging environment.
- Beginning with Exchange 2010 SP2 RU4, administrators can create retention tags via the cmdline for use with the Calendar and Tasks default folders. The supported retention actions are: DeleteAndAllowRecovery, PermanentlyDelete, MarkAsPastRetentionLimit. Note that calendar and task items can be moved to the archive mailbox via the MoveToArchive retention action that is associated with the All or Personal retention tag type.
- Default Policy Tags (DPTs) used to move or delete items will now apply to Calendar and Tasks folders.
How Calendar and Tasks items are expired
Calendar and task items are different than normal message items. When a calendar or task item is saved, the item is stamped with its specific properties. To ensure that a collision (or conflict) doesn't occur between the Mailbox Folder Assistant (MFA) and the assignment of the default properties during an auto-save event, the will not process calendar and task items immediately. Instead, the assistant will delay processing of calendar and task items for 2 hours (based on last modification time of the item; if there is no last modification time, then it is based on the creation time).
Unlike message items, end users cannot assign different retention tags to either the Calendar or Tasks folders or calendar and task items. In other words, Calendar and Tasks retention tags are only controlled via the administrator.
The following logic is used to determine the start date for expiration or move to the archive for calendar items in the Calendar folder:
- Non-recurring calendar items expire (or move to the archive) based on the end date of the item.
- Recurring calendar items expire (or move to the archive) based on the end date of their last occurrence. Recurring calendar items without an end date neither expire nor move to the archive.
- If an item is found within the Calendar folder that doesn't have a proper item type, it's ignored (as the item is might be corrupt).
The following logic is used to determine the start date for expiration or move to the archive for task items within the Tasks folder:
- Non-recurring tasks:
- A non-recurring task expires (or moves to the archive) according to its message-received date, if one exists.
- If a non-recurring task does not have a message-received date, it expires (or moves to the archive) according to its message-creation date.
- If a non-recurring task has neither a message-received date nor a message-creation date, it neither expires nor gets moved to the archive.
- Recurring tasks expire (or move to the archive) according to the end date of last occurrence. If a recurring task doesn't have an end date, it does not expire (and isn't moved to the archive).
- A regenerating task (which is a recurring task that regenerates a specified time after the preceding instance of the task is completed) doesn't expire (or get moved to the archive).
- If an item is found within the Tasks folder that doesn't have a proper item type, it's ignored (as the item might be corrupt).
Before You Deploy Exchange 2010 SP2 RU4
Support for Calendar and Tasks in Exchange 2010 SP2 RU4 means you’ll need to treat this update rollup differently. If you don’t use Retention Policies or if you don’t mind Calendar and Tasks items being moved to archive or deleted automatically based on the DPT settings, you can skip the rest of this post.
However, if you are concerned about the effects of this new functionality will have on your calendar and task items, you can implement the following temporary workarounds:
If you don’t want Calendar and Tasks items to ever expire, you can disable the functionality that is included in Exchange 2010 SP2 RU4. Add the following registry key to your Mailbox servers:
- Path: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeMailboxAssistants\Parameters
- Name: ELCAssistantCalendarTaskRetentionEnabled
- Type: DWORD
- Value: 0 = Do not process Calendar and Task folders
- Value: 1 = Process (default with RU4)
If you want Calendar and Tasks folders to expire at a different interval than s, you can follow the following steps:
- Place all mailboxes on Retention Hold
- Apply Exchange 2010 SP2 RU4 to your Mailbox servers.
- Create s for Calendar and Tasks folders with the desired retention settings.
- Inform users about the change.
- When ready, remove the retention hold from mailboxes.
We are glad that we were able to bring this long sought after feature to the product. If you have any questions, please let us know.
Ross Smith IV
Principal Program Manager
Exchange Customer Experience