Best practices for submitting and reporting on actual work

Organizations choose to track work that is performed by resources in many ways. Microsoft Project Server 2010 supports flexibility for the varying tracking needs of organizations. Some organizations require the work submitted by resources to be recorded on a day-to-day basis, especially if the actual work is used for billing, payroll, or other financial purposes. Project Server 2010 can be used to capture actual work submitted by users. Some organizations choose to transfer actual work to other enterprise resource planning (ERP) and reporting systems. For example, an organization might choose to use Project Server 2010 to capture actual work, but then transfer the actual work to an accounting tool to drive invoicing to internal and external customers.

Because Project Server helps you manage projects, actual work can be captured in multiple ways, and it is displayed in the way that makes it most useful for the user who is accessing it. For example, in the timesheet the focus is on user-entered data on a per-day (or per-period) basis, whereas in the Microsoft Project client the focus is on the aggregate, or scalar, value for work completed and remaining on a task to help with planning.

This article outlines the set of best practices for submitting and reporting on actual work in Project Server 2010.

In this article

1. Use single entry mode

2. Protect user updates

3. Use submitted actual work from timesheets, instead of project plans, for timephased reporting

4. Use administrative time categories to track non-project work

5. Close tasks to updates, instead of using the Publish and Booking Type fields

Summary

Acknowledgements

1. Use single entry mode

The best practice to help make sure that actual work is populated correctly throughout Project Server 2010 is to use single entry mode and have resources only enter actual work through the Timesheet view.

To turn on single entry mode:

1. On the Quick Launch, in the Settings section, click Server Settings.

2. On the Server Settings page, in the Time and Task Management section, click Timesheet Settings and Defaults.

3. In the Single Entry Mode section, select the Single Entry Mode check box.

If your organization is using single entry mode, it may be in your best interests to hide the Tasks view completely so that resources can only enter actual work by using the Timesheet view. When both views are available, users can enter actual work in either view, and the data is persisted in both views. If your organization pulls data from timesheets to drive billing or payroll, for example, the best practice is to only allow users to enter actual work in the Timesheet view. This reduces the possibility for actual work to be incorrectly overwritten if a user can also enter actual work in the Tasks view.

An exception to this best practice is if there are material resources. Assignment owners for material resources must enter time for those material resources by using the Tasks view. If your organization has assignment owners that record time for material resources, the Tasks view should remain visible, and users should be instructed to only enter actual work for their assignments in the Timesheet view.

To hide the Tasks view:

1. On the Quick Launch, in the Settings section, click Server Settings.

2. On the Server Settings page, in the Look and Feel section, click Quick Launch.

3. Under Set Menu Item Details, click the Tasks view, in the Name column.

4. Click No in the Display link in Quick Launch list, and then click OK.

There are a few important notes to consider when single entry mode is enabled in your organization. Let's say a user's timesheet contains a line for a particular assignment, and that assignment is deleted. The next time that the user opens that timesheet, the line associated with the deleted assignment may be removed, depending on the following conditions:

• If the line contains no user entries, it is removed.

• If user updates are not protected, and the line contains approved actual work, it is removed.

• If user updates are protected, and the line contains approved actual work, the line remains in the timesheet. However, if the approved timesheet is recalled, then the line is removed.

• If the line contains actual work that has been entered into the timesheet but that is still pending approval, the line is removed, even when user updates are protected.

Project managers should use caution when deleting or changing assignments, to be sure that all submitted actual work is reviewed before the change or deletion. This helps to ensure that valid user-entered data is not lost. Assignments can be explicitly or implicitly changed in any of the scenarios listed below:

• The project manager explicitly deletes an assignment for which there are pending actual work updates.

• The project plan containing the assignment is restored from its archive.

• The project plan containing the assignment is deleted.

• The project plan containing the assignment is overwritten, using the Save As functionality in Microsoft Project 2010.

Top of Page

2. Protect user updates

Some organizations might choose to prevent a project manager from updating a team member's actual work inside the project.

Note:  Project managers are unable to update a resource's actual work recorded on a timesheet.

If your organization wants to maintain resource-entered values for actual work in the timesheets and make sure that value is reflected in the project plan, then the best practice is to turn on the feature in Project Server 2010 that protects user updates.

To protect user updates:

1. On the Quick Launch, in the Settings section, click Server Settings.

2. On the Server Settings page, in the Time and Task Management section, click Task Settings and Display.

3. In the Protect User Updates section, select the Only allow task updates via Tasks and Timesheets check box.

When you protect user updates, timesheets always maintain exactly what the user entered for timephased work, and the scalar values between timesheets and the project plan are always consistent. However, the timephased distribution of the scalar value may be slightly different in the project plan, as it is geared toward future work planning and not maintenance of actual work historical values. The scheduling engine may adjust some timephased actual work to keep the plan consistent.

Top of Page

3. Use submitted actual work from timesheets, instead of project plans, for timephased reporting

Actual work can be captured by using either the Project 2010 client (project plan) or timesheets. However, many users only capture actual work directly from their resources by using timesheets, especially if they are also protecting actual updates as previously described. When you are using timesheets to track the submission of actuals on a daily or weekly basis, the best practice is to report directly against the actual work captured in timesheets when syncing with external ERP and reporting systems. The timesheet data is specifically rendered to ensure accuracy on a historical and per-period basis exactly as the user entered it, even when conditions in the project plan have changed.

While many calculations are made in a project plan, such as cost based on cost rates, these can be easily replicated with timesheet data. The project plan, on the other hand, renders the actual work data (and other schedule data) with an emphasis on future work planning (analytics and earned value calculations). Therefore, there may be circumstances where the user-entered value in the timesheet does not exactly match the same value in the project plan for a specific day. However the overall aggregate, or scalar, value for the assignment will be consistent between the project plan and the timesheet when protected actuals is enabled.

If you are reporting on submitted actual work from timesheets, it is important that resources be asked not to reassign or self-assign tasks. All assignments should go through the project manager or resource manager. This helps ensure proper handling of actual work data.

The BI Center in Microsoft Project Web App provides report templates that take advantage of the reporting database (T-SQL) and Analysis Services (OLAP). These templates may help you author reports against the timesheet's data store.

Top of Page

4. Use administrative time categories to track non-project work

Some organizations require the tracking of administrative activities, or non-project work. Examples of administrative activities include sick time, vacation, and work-related repetitive activities such as customer support, system maintenance, or meetings. We recommend that these activities be tracked by using administrative time categories. These categories require minimal maintenance, and time that is captured in these categories can be used to generate data analysis reports from the corresponding OLAP cube.

For more information about how to set up administrative time categories, see Administrative Time.

If administrative time categories do not meet your organization's needs, and you decide to use projects to track administrative activities, the project owner should follow these guidelines for more efficient projects:

• Limit the number of resources assigned to the project plan to less than 100 resources.

• Limit the duration of the project plans to track administrative activities on a quarterly or half-yearly basis.

• Keep tasks in the project plan automatically scheduled, with a fixed units task type.

• Keep the project plan's schedule in line with time reporting periods.

Top of Page

5. Close tasks to updates, instead of using the Publish and Booking Type fields

Project managers may find the Publish and Booking Type fields helpful for controlling task and resource visibility. The Publish field can be used to control which tasks are visible in Project Web App, and the Booking Type field can be used to control which resources are visible during the resource planning process. However, be aware that these fields are part of the early planning process. They are not designed for limiting users' ability to continue to track time on a particular task. If the Publish and Booking Type fields are used incorrectly, they can result in the removal of task entries from a user's timesheet or task status. This is especially critical because the removal of task entries may mean the loss of submitted time.

For more information about the Publish and Booking Type fields, see the following Help articles:

• Publish (task field)

• Add a user account in Project Server 2010

• Create a new resource

If you want to close a particular task so that no additional time can be submitted, you can use the Close Task to Update option in Project Server 2010.

For more information about how to close a task to updates, see Close tasks to update.

Top of Page

Summary

If your organization uses actual work captured in Project Server 2010 together with other ERP or reporting systems, it is in your best interests to follow the guidelines described in this article:

• Use single entry mode

• Protect user updates

• Use submitted actual work from timesheets, instead of project plans, for timephased reporting

• Use administrative time categories to track non-project work

• Close tasks to updates, instead of using the Publish and Booking Type fields

By following these best practices, you are working to preserve the accuracy of the actual work data that is entered in timesheets by your organization's resources.

To maintain the actual work data for a project that has been completed or is no longer active, follow the guidance offered in Archive a completed project.

Top of Page

Acknowledgements

The Project Server Content Publishing team thanks the following contributors to this article:

• Bobby Burns, Program Manager II, Project/Project Server

• Aik Chen, Senior Support Escalation Engineer, Project/Project Server

• Christophe Fiessinger, Senior Technical Product Manager, Project/Project Server

• Heather O'Cull, Senior Program Manager Lead, Project/Project Server

• Keshav Puttaswamy, Principal Group Program Manager, Project/Project Server

• Matt Roe, Program Manager, Project/Project Server

• Saurabh Sanghvi, Program Manager, Project/Project Server

• Eli Sheldon, Program Manager, Project/Project Server

• Brian Smith, Senior Support Escalation Engineer, Project/Project Server

• Eric Zenz, Senior Program Manager Lead, Project/Project Server

Top of Page