Manage Project Requests

Overview

Portfolio Planning allows for department/organizational leadership to review and evaluate project requests. In most cases once a project request is submitted an appropriate Portfolio workflow will be applied which will guide the request through the review steps identified by the department responsible for managing that project type.

The applied workflow will determine which elements and applicable sections are editable, and/or required. As well as which Enterprise Service Management (ESM) group is responsible for completing that project review step. Additionally, each step is configured to allow, or not allow the reviewer(s) to edit, reject the request, return to requestor, reject step, forward the step.

In this article:

• Initial Review
• Project Scoring
• Next Steps
• Gotchas & PItfalls

Initial Review

The exact elements associated with a project request's initial review will be dependent upon the specific portfolio workflow assigned to the request; however, in general the following elements should be examined:

• General - Review the core elements of the project's charter, playing special attention that all required fields are correct. The specifics will vary depending upon which project request form was used; however, the following are common for all project requests:
  • Project Name
  • Sponsor
  • Acct/Dept
  • Type
  • Start Date - the estimated date the project will begin execution
  • End Date - the estimated date the project is expected to be completed by
• Goals - Optional, add any UA wide goal(s) which the project facilitates. Include supporting details/comment.
• Organizational Risks - Optional, select a classification for each organizational risk listed. Include a succinct comment supporting the selection.
• Supporting Documentation - Optional, add any documentation required to evaluate the request, or to execute the project.
• Expenses - Optional, add any non-labor expense(s) expected as a part of the project.
• Role Forecasts - Optional, add any labor related commitments expected as part of the project.
• Scorecard - For each element on the associated scorecard, select a response.
• Stakeholders - Optional, add one, or more, stakeholder(s) affiliated with the project. For each stakeholder added enter a succinct description of their responsibilities and/or concerns as well if they are Responsible, Accountable, Consulted, and/or Informed (RACI).
• Risks Register - Optional, add any known threat or opportunity associated with the project.

Once the initial review is complete do the following:

1. On the project request, click Business Case.
2. Click Actions.
3. Click Approve Step.
4. In the Approve Step dialog, enter a brief comment and then click Save.

Project Scoring

The departmental group responsible for determining if a project request should proceed forward will leverage the project's score to assess its relative value. Project requests can be quite varied in nature, making comparisons difficult. The use of a common set of criteria that are relevant to all requests helps to ensure each project request can be assessed more accurately. The request's score is the sum of the scores of the various criteria associated with the scorecard assigned to the request. Additional information on scorecards can be found in the How Project Requests are Evaluated KB article.

We recommend scorecards be used as an input or factor in decision-making, but project request scores should not be the sole determining factor. For example, if project request A receives a score of 87 and project request B receives a score of 84, this does not necessarily mean that project request A should be approved over project request B.

The score should not be the only deciding factor for several reasons:

1. The scorecard criteria may be missing questions or be weighted incorrectly.
2. There may be qualitative factors to consider.
3. Making decisions based on the score creates a large incentive for people to optimize for a high score, rather than for good project outcomes.

Scores can and should be used to band or group project requests. For example, project requests receiving a score in the lower quartile usually should not be considered.

View the project request's score by doing the following:

1. On the project request, click Business Case.
2. Scroll down to the Composite Score section.
3. Review the project's Scorecard Score and Composite Score.

Once the project scorecard review is complete do the following:

1. On the project request, click Business Case.
2. Click Actions.
3. Select one of the following options:
   • Reject - Return to Requestor
   • Reject - Return to Previous Step
   • Reject - Decline Request
   • Approve Request
4. In the selected response dialog, enter a brief comment and then click Save.

Next Steps

Once a project request is approved, it can be staffed. If the project request is declined, the creator is notified via email that the project request has been declined.

• Convert a Project Request to a Project

Gotchas & Pitfalls

Project requests cannot be edited or evaluated in TDWorkManagement if they are in a Not Submitted state.  The request owner must submit the request in the Service/Client Portal.  The request owner can only be modified by an ESM Enterprise Admin.

Need additional help or have issues

For support, requests may be submitted anytime using the appropriate Enterprise Service Management form. Requests generate a Ticket which will be worked in order received and urgency by IT Employees with the knowledge and permissions to assist with the request.

For immediate assistance please review the Contact Us page for the appropriate support group.