Understanding the Project Request Component

You can define templates, and use them to create project requests that have similar characteristics and structure or that are repeated periodically. Templates can serve as identified "best practices" for certain projects or project types. The only fields that are required when you are defining a template are the business unit, the template ID, and a description; you can complete as many of the remaining fields for scoring, attachments, cost, benefits, dependency, and milestone information as you want. When establishing a project request, you can either create it from scratch or create it by using a template and then modifying or adding any necessary details.

Templates differ from project requests in the following ways:

• Templates are not involved in the project request approval workflow process.

  You can't submit templates for approval nor cancel them.

• Templates do not integrate with Program Management.

• Templates are not included in portfolio analysis.

• You cannot create versions of a template.

To maintain templates, use the Project Request component pages. When accessing the search page for the Project Request component, select the Template check box to add, update, or view a template instead of a project request. The settings that are established by using the Privileges for Project Requests and Templates page control who can create and update templates. If a user is granted edit privileges for templates, that user can create a new template or update an existing template by selecting the Template check box when accessing the Project Request component pages. If a user has view-only privileges for templates, then the Template check box does not display in Add mode, because that user can create only project requests, not templates. In Update/Display mode, that user can select the Template check box to view an existing template. The user is not able to save any changes to the template, however, they can save it as a new project request, and then modify it.

You can also create a template from an existing project request, specifying which categories of project request fields to include in the template definition. You cannot edit the start date or end date fields; however, an option is available to move cost and benefit details an appropriate number of periods.

A proposed project request can include multiple versions so that each of the versions can be compared and analyzed before a request is approved. For example, the initial version could be "best case," in which return on investment and key business objective support scores are very high, but at the cost of high estimated costs and high risk. The second version could be a scaled-down version of the project request with less benefit for less risk. Multiple versions can exist until one is approved. At that time, the status of the remaining versions that are in pending status changes to canceled. (Versions that are already declined remain in declined status.) When you create a version, its field values automatically default to the values of the current project request; modify any field values that differ for the new version.

You enter estimated project request costs and expected benefits by general ledger business unit, department, and account. These amounts are the expected cash inflows and outflows that are related to the proposed effort. Optionally, you can capitalize costs, which spreads the costs evenly over three fiscal years, starting with the fiscal year and period of the first entered cost amount. The system uses these amounts to determine the return on investment for each project request.

Milestones enable you to manage the progress of a project request or its defined risk elements. You associate standard milestones with project requests by using the Project Request - Milestone page. You associate risk milestones with risk elements by using the Project Request - Risk Elements page.

You define milestones independently of project requests by using the Milestone page.

Score groups enable you to associate objectives and risks with a project request for the purpose of generating scores that indicate how well the project request meets the objectives or how much it is at risk. These scores provide a comparative measurement for all of the project requests within a given portfolio and help determine which project requests to approve.

You can define two score groups for a project request, one for evaluating risk and another for evaluating other scores that you want to compare during portfolio analysis, including key business objective (KBO) support. Ideally, your organization identifies standard KBOs, and all project requests that are grouped into a portfolio are associated with the same score groups so that the scores are a true comparison. Score groups are based on a scorecard portfolio definition, and the rows within a score group are derived from the nodes of the tree on which the portfolio is based. Each row of a score group is referred to as a risk category (for the risk score group) or category (for the other score group).

Because groups are based on a scorecard portfolio, you can weight the relative importance of each of the risk categories that compose the score group. The weighting is considered when the system determines the score.

The risk score group has additional functionality to help manage risks. Risk elements can be associated with each risk category within the risk score group, and risk milestones can be assigned to each risk element. These milestones can have an impact on the net score for primary risk, depending on the probability that they will occur and their current status.

When a project request is submitted for approval, it triggers a business process event that places the work item on the worklist of the person who is identified in the Approver field on the Project Request page. Only users who are associated with the PPM Approver role can approve, decline, return, or cost a project request. After the approver performs one of these four actions, the work item is removed from the approver's worklist.

The steps that occur during the workflow procedure for project request approvals are:

1. A user creates and saves a new project request, but does not submit it.

   Based on the initiative type that the user enters for the project request, the owner and approver fields are populated automatically on the Project Request page.

   The system initially sets the status to Pending.

2. The user submits the project request for approval by clicking the Submit button on the Project Request page.

   The system updates the status to Submitted.

3. The system sends the project request to the approver's worklist.

4. The approver views the worklist and clicks the project request link to review it.

5. The project request approval page appears.

   The approver selects one of these options:

   Approve	Approves (or operationally approves) the project request. When this option is selected, the system responds in one of these ways, depending on whether funding department manager approval is required: If funding department manager approval is required: The system updates the status to Operationally Approved, which indicates that the project request is approved from one perspective only. Then the system routes the project request to the worklist of every manager whose department appears on the Project Request component's Cost page. Assuming that each of these managers has adequate spending authority, which is defined in PeopleSoft Workflow Virtual Approver, they all must approve the request for its status to change to approved. If any one of the funding department managers denies the project request, the system changes the status to Declined and does not allow the project request to be resubmitted. If any of the funding department managers changes the project request status to Returned, the system starts the approval process over again, and PeopleSoft Workflow routes the project request back to the worklist of the initial requester of the project. The project requester can resubmit a returned project request; however, all of the same approvals are still required, assuming that the amount of the estimated costs does not change enough to cause higher or lower levels of spending authority by the approvers. If funding department manager approval is not required: The system updates the project request status to Approved and either generates a new project with a processing status of Active, or, if a project already exists, updates the status of the project to Active. If any other versions of the project request exist, the system automatically sets them to a status of Declined, sets their associated projects to a processing status of Inactive, and cancels any labor resource assignments for those projects. The only exception to this occurs when the approver does not have adequate authority to approve the amount of the project request's estimated costs. In this case, PeopleSoft Workflow's Virtual Approver locates the manager of the initial approver and routes the request to the manager for approval. Note: You establish whether funding department manager approval is required when you establish workflow options by using the PPM Preferences (BC_GENERAL_PREF) component. See Workflow Options.
   Return	Returns the project request to the individual who is identified as the requester on the project request. The system updates the project request status to returned and adds it to the worklist of the requester for rework. If anyone resubmits the request, the approval process starts over from the beginning.
   Decline	Denies the project request. The system updates the project request's status to declined. If integration with Program Management is enabled, the system also changes the processing status of any corresponding projects in Program Management to inactive (if an associated project exists), and changes any resource assignments for the project to a status of Canceled.
   Cost	Indicates that detailed cost information is required. The system sends the project request to Program Management for cost details, routing the project request to the project manager, and updates the project request status to Costing. This signifies that the project manager must create a detailed plan by using the various project planning tools that are in Program Management. When the plan is complete, the project manager clicks the Send to Project Request button by using the Project Request Estimate Summary page in Program Management. The system subsequently updates the project request status to Submitted, triggering a message on the project request to indicate that a detail plan is created, and routes the project request back to the worklist of the designated approver.

Image: Project request approval workflow

The following diagram provides a graphical depiction of the project request approval workflow and its impact on the project request status, as described in this section:

This table provides a key for the abbreviated roles that are in the project request workflow diagram:

Image: Project request status values

This diagram shows the possible status values that a project request can assume given its current status: