Planning for Global Settings

As described previously, you will need to plan for how you will view and manage the roles, processes, projects, resources, and reporting that will be used in your enterprise project management environment. One of the most important aspects of this is to plan your project and resource attributes, called enterprise outline codes in Project Server 2003. To do this, you may need a series of planning meetings with key people in your organization.

Planning Project Attributes

First, you will decide the attributes you want to assign to projects. Do you want to be able to report on projects by which department they belong to, which customer they belong to, or what project lifecycle they are currently in? Do you want particular data for each task in a project, such as status or associated cost center?

To establish a set of project and task attributes for your organization, you need to first determine all information that needs to be reported about projects and tasks .

For instance, Elkhart Software has offices in Denver and Seattle. Some projects are located in Seattle, and some in Denver. Elkhart Software also has multiple customers and several internal project sponsors to oversee the projects. Elkhart Software would therefore need to create three enterprise project outline codes: location (Denver and Seattle), customer (the customers), and sponsor (the sponsors). Elkhart Software additionally wants to be able to report on each project by priority and state. For each task, Elkhart Software has decided that they want to be able to report on each project's task billing code.

Planning Resource Attributes

To establish the set of resource skills and attributes for your organization, you need to first determine all information that needs to be reported about resources.

The most important resource attribute you will need to establish is the resource breakdown structure (RBS). This attribute establishes how managers can view their resources. For example, the RBS might be the organization or department a resource works in, such as IT, Operations, or Finance. The manager of the IT department may have views that allow them to view all IT personnel, but not those resources in Operations and Finance.

Another attribute might be the location of the resource. Let's consider an example in which Elkhart Software has offices in Denver and Seattle. Some resources are located in Seattle, and some in Denver. It would be useful to be able to attribute either Denver or Seattle to each enterprise resource so that managers can look at resource usage by role and location. Resource skills might include project manager, technical writer, system administrator, tester, trainer, and developer.

You can begin planning your enterprise resource definitions by determining what roles people have played on your project teams . You can refer to past and current projects, and create a list of skills that have been required on those projects.

When you have determined the skills needed by the organization, you might want to break down the definitions further. For example, instead of simply listing the skill programmer , you might want to have information on different types of programmers, such as Web, Visual Basic, and C++ programmers. Or, you could associate skill levels, such as junior and senior, with each skill. You might also want to consider skills that you might need in the future, not just the current ones.

You can also assign multiple skills to each resource. To learn more about this, see "Enabling Multiple Skills per Resource," p. 1087 .

The way to enable the gathering and reporting of customized information for an organization is through outline codes and custom fields. For more information, see "Creating and Using Custom Outline Fields," p. 854 .

Other Planning Considerations

Besides enterprise outline codes to help with analysis and reporting of project and resource data, you will want to consider the following other planning activities.

Plan for Consistent Project Schedules

Make sure all project managers in your organization use consistent methods and data input techniques to produce the project schedules. Using enterprise project schedule templates helps ensure that this happens. You will want to make sure they all use the enterprise calendar, which accounts for your company's holidays, and you will want to ensure that all schedules have the same custom fields if you are trying to collect special data for each task in a project (such as billing code or status for each task). You will additionally want to consider if you would like to use Versions. Versions are snapshots of projects and associated schedule data. By saving a project plan as different versions, a project manager can create several copies of the plan for internal project team use, while keeping at least one version, Published, available for external use.

Plan for Consistent Views in Project Professional

Also, you might want to make all input consistent by setting enterprise views, Gantt Charts, timescale settings, and other preferred enterprise styles for viewing project schedules in Project Professional.

Plan for Managing Time Reporting

You will need to decide how you would like to report time to capture actuals in your project schedule, and to capture timesheet data from your team members . You may want to

• Input actuals data directly into the project schedule and not use the timesheet application

• Use the timesheet application and allow project managers to decide whether they want to collect actuals based on % complete, total actual hours, or hours day-by-day

• Use the timesheet application, but ensure enterprise consistency by allowing project managers to capture data in only one of three ways: collect actuals based on % complete, total actual hours, or hours day-by-day

• Use the timesheet application and capture actuals on a day-by-day basis for the entire enterprise, and lockdown time reporting periods so that team members cannot enter time except during actual periods. This is a new feature of 2003, and provides excellent auditing capabilities for your organization.

• Add review and functional manager approval processes and functions to your timesheet processes. This is a new feature that allows someone other than the project manager to also review and approve timesheets.

• Create a process for adjusting actuals and using the feature in Project Server 2003 for the adjustments. This would be used only with the new lockdown feature of 2003.

Plan for Collaboration and Document Management

You will want to decide on how your project managers and their teams will want to use the collaboration and document features in Project Server 2003.

• Your organization will need to decide whether it wants to use status reports regularly to keep the project manager aware of task or project status apart from the task status updates recorded via time reporting.

• Your organization will want to decide whether it wants to use issues to help manage problems that occur in the course of a project.

• You will want to decide whether you would like to use risk management for your projects to document and analyze possible jeopardy items or opportunities for your project. This is a new feature for Project Server 2003.

• You might want to store and track all your project's documents using a document management method and the tool within Project Server 2003. New to this feature in Project Server 2003 is the capability to manage versions, and have check-in/ check-out capabilities to ensure more document management integrity.

Plan for Roles, Security, and Views

Your organization will also need to plan for

• The roles you will use (project manager, portfolio manager, and so on)

• System access rules to Project Server 2003 based on those roles

• Access rules to the data stored and viewable in Project Server 2003 based on those roles (for instance, a team member should not be able to view resource rate information)