Determine Core Requirements

I’ve grouped the most critical requirement areas for initial Project Server configuration. These are core to getting something more than out-of-the-box up and running. Once you’ve defined the core requirements, you have enough information to extend this document with configuration-specific information and designs. Noncore requirements support information gathering for features that may or may not be implemented.

Determine Deployment Level

Before you begin to design your customizations, you should define the deployment audience for the application and how application data gets protected across that audience. Doing this well includes keeping things simple yet deep enough to represent current and reasonably certain future requirements. How will you deploy Project Server in your organization? What audience will it serve?

A deployment confined to a single department is straightforward. Outline code values can reflect the department’s internal view of the organization. An interdepartmental deployment in which departments share a single portfolio database is designed differently than when multiple instances of Project Server are created on one server. The important thing to know is where to set the margins for your custom structures. If your goal is ultimately to deploy across departments under one portfolio umbrella, then you should represent or at least allow for it in outline code structures that represent your organization.

Define the Project

Microsoft Project largely supports project management practices and assumes familiarity with organizational constructs of organizations that practice this management discipline at least somewhat by the Project Management Institute’s (PMI’s) Project Management Body of Knowledge (PMBOK). Project Server adopters who want a lighter implementation may still find value in less sophisticated adaptations provided they understand the tradeoffs.

You’ll need to define what your organization means by “project.” Does your organization’s definition of a project match PMI’s definition of a project? If not, how does it vary? Will you use projects to track maintenance type of work? If so, what adaptations will be required to accommodate this? Primarily, you want to identify exceptions so that you can deal with them in the configuration design.

Define the Project Organization

Because the primary purpose of project management software is to enhance the project management process, your organizational approach to project management is square one in requirements gathering. I’ve stressed the importance of the assessment phase and mending the organizational disconnects; this is where you define the future state of the project organization that your Project Server implementation is designed to support while or after you implement the necessary process changes in your organization.

At this point you’ll begin using the tables provided in the template document. Remember that it’s perfectly OK to modify the tables or establish breaks in them to insert additional explanatory information and narrative content as you feel appropriate.

Table 3-1 contains the key requirements-gathering points for defining the project organization of your company. Often, you’ll use “N/A” (not applicable) as an appropriate answer. Make sure you’ve thought these N/As out carefully.

Table 3-1: Requirements Gathering Points for the Project Organization

REQUIREMENT	VALUE
Total number of active projects to accommodate.
Near-future number if deployment expansion is a near-term goal.
Average project size in number of tasks.
Largest expected project in number of tasks.
Average project duration (can be expressed in elapsed time or duration units, and note which method you’re using).
Longest anticipated project duration (can be expressed in elapsed time or duration units, and note which method you’re using).
Will external dependencies be used? (Y/N)
Earned value method used (physical, work, N/A).
Total number of system users.
Total number of human resources.
Total number of other work resources.
Total number of material resources.
Does the company span multiple locations? (Y/N; if Y, provide details.)
Do projects span multiple locations? (Y/N; if Y, describe control structure and resource sharing plan.)
Do location codes exist? (Y/N)
Will Project Professional users span multiple locations? (Y/N)
Will Project Web Access users span multiple locations? (Y/N)
Is this a single locale or multiple language installation?
Are Master Projects allowed? (Y/N; if Y, explain management strategy.)
Will the system specify a single currency setting? (Y/N; if yes, provide.)
Will project managers be allowed to use local base calendars? (Y/N)
Define date range for long-range resource availability information.
Define date range for OLAP information and frequency of update.
Who will be responsible for maintaining resource data?
Who will be responsible for maintaining project artifacts?
Who will be responsible for updating resource calendar data?
Authentication method for the Project Server.
Minimum password length.
Require server authentication prior to publishing? (Y/N)

Define Project-Level Characteristics

After you understand the greater project organizational needs, you must delve into more project-specific requirements. To be effective, you must look for hidden treasures in existing project documents. You’re looking for the appearance of repetitive data across multiple reports. How do your users want to see project data expressed? Your challenge is to find project attributes that will help to mold your portfolio presentation. Table 3-2 includes the pointers you’ll need to identify requirements in this section.

Table 3-2: Project-Level Requirements

REQUIREMENT	VALUE
Describe project life-cycle phases and the importance of these to management reporting.
Is there a corporate project numbering system? (Y/N; if yes, specify.)
Are there accounting codes that are applied at the project level? (Y/N; if yes, specify.)
Are individual projects aggregated into programs supporting related initiatives? (Y/N; if yes, describe.)
Are programs aggregated into multiple portfolios? (Y/N; if yes, describe.)
Are projects identified by client or consumer entity? (Y/N; if yes, describe.)
Describe other unique identifiers for projects that may be required for reporting or interfaces with other host applications that may apply.
Describe informational fields to be maintained at the project level.
Is there a need for archived versions of projects in the data store? (Y/N; if yes, describe.)

Define the Task Organization

Like seeking characteristics at the project level, hunting down requirements at the task level involves reviewing existing reports and documents. What does your organization wish to track to the task level? Are there accounting or job codes to capture? Review Table 3-3 and include these points in your requirements discussions.

Table 3-3: Task Organization

REQUIREMENT	VALUE
Are there job codes or accounting codes associated with tasks? (Y/N; if yes, describe.)
What is a typical default task type?
Is task scheduling effort-driven? (Y/N)
Is a unique Work Breakdown Structure (WBS) used? (Y/N; if yes incorporate description in text.)
Describe other unique identifiers for tasks that may be required for reporting or interfaces with other host applications.

Define the Resource Organization

The consumption of resources drives project cost. Therefore, capturing attributes for the enterprise resource pool is one of the most important requirements-gathering activities. Not only must you understand how resources get acquired for project work, but you must also understand the reporting structures in the organization in order to take full advantage of all of the security features in Project Server.

To help you identify resource organization attributes, look at typical sources of resource information such as the company address book, the Active Directory (if you can access it), and HR information available to you. Review Table 3-4 and record information pertinent to your organization. Identify where your initial resource data will come from.

Table 3-4: . Resource Organization

REQUIREMENT	VALUE
Will the Resource Breakdown Structure (RBS) be implemented? (Y/N; if yes, provide RBS definition.)
Are rate tables required? (Y/N; if yes, provide rate table definitions.)
Describe other unique identifiers for resources that may be required for reporting or interfaces with other host applications.
Are skill sets currently defined for resources? (Y/N; if yes, describe or provide reference to attachment.)
Do location attributes apply to resources? (Y/N)
Describe other attributes that target resource selection.
Describe ways that resources are categorized in the company for reporting, management, and accounting purposes.
Describe the source(s) for resource data.

Identify Default Working Times and Alternate Calendars

Setting this information up has always been an underlying requirement to using the Project client effectively. With Project Server, you configure working times once at the server and the calendars become available to all users through the system. You must identify calendars required for human resources and nonhuman work resources if you implement them as determined with the guidance of Table 3-5.

Table 3-5: Calendars and Default Working Times

REQUIREMENT	VALUE
Describe the default working times for your company.
Describe additional calendars required for your implementation for tasks or resources.
Are resource units adjusted to account for nonproject time in scheduling? (Y/N; if no, describe calendar method.)

Define Project Tracking Methods and Options

Tracking methods and tracking options determine how resources report on tasks and control the appearance of timesheets for team members. Choosing a tracking method is a core decision driven primarily by the degree to which an organization values accurate effort tracking. In the world of project management maturity, high-achiever organizations track effort. There are, however, organizations that are typically time-to-market driven that don’t value effort tracking. For these organizations, a less accurate approach to tracking is good enough.

Does your organization want to track effort as accurately as possible? If so, have resources report hours worked and hours remaining against task work. Use Percent Work Complete only for date-driven planning where tasks planning is predominately a fixed duration. In this case, effort is inferred and calculated by Project Server and is therefore less accurate. In my experience, percentages climb faster earlier in the life of the task than they do later in the life of the task.

If project tasks in your organization’s world are predominately fixed work, where you are almost certain that effort doesn’t vary, having resources report hours worked only without reporting remaining work or percentage complete might be right for your organization. This approach has the disadvantage of quietly marking tasks complete without manual intervention, because there’s no systemic data conveyed to indicate delay rather than completion. Take this approach if you’re only looking for a data capture of hours worked. Review Table 3-6 for guidance with regard to capturing your requirements.

Table 3-6: Determining Tracking Methods

REQUIREMENT	VALUE
Will a single-tracking method be enforced or will project managers choose the reporting method for each project?
Specify the default tracking method.
Define the default start day of a week.
Will timesheets span weekly or monthly periods?
If timesheets will span weekly periods, how many weeks should display in the timesheet?
If timesheets will span monthly periods, how many reporting periods in a month? (Up to three may be defined—specify start and stop parameters for all specified.)
Will time entries be made by the day, by the week, or by the time period?
What is the maximum number of hours a resource may report in a given day?
Current tasks are defined as tasks that start up to how many days from the current date?
Will you collect nonproject time? (Y/N; if yes, specify categories.)

Determine Security Requirements

To determine security requirements, you should bring the organizational chart to the table. Explain how access to project or resource data might be affected by a person’s position on the organizational chart. You must define security rules for the Project Server roles you’ve identified for use in your organization. Consider how these might be defined by a person’s role in the project organization as described in Table 3-7.

Table 3-7: Defining Security Requirements

REQUIREMENT	VALUE
Define who has access to all project data across the enterprise.
By role, describe the criteria by which an executive, project manager, resource manager, team lead, or resource has access to project data.
By role, describe the criteria by which an executive, project manager, resource manager, team lead, or resource has access to resource data.
Define special roles of internal or extranet users and the data access they should have.