HP-PPM Data Dictionary     Last Updated: Januray 19, 2009 - New GoDaddy Integrated Site Load

        This Data Dictionary document contains definitions,functions and data attributes (both standard and custom) displayed, updated and\or utilized throughout the HP-PPM modules related to the Enterprise Change Management Process. It also contains functional defintions related to the PM Processes being facilitated and utilizing the HP-PPM tools. Each entry contains a brief definition and some, a detailed explanation of utilization and behavior. The elements are alphabetized exactly as they appear in the applications. Where appropriate, hyperlinks to project and/or organization documents are included to enable a more detailed understanding of the data element or it's behavior characteristics. Additional and related information may be found in the Change Management Glossary. To search the Dictionary for all elements related to a topic you may also select "FIND" under the "Edit" menu or proceed to the beginning of the alphabetic section by selecting:

        Any attributes or functions which contain an Owner Name and Last Update date specifically relate to version 7.1 of the HP-PPM system. Verison 6.0 attributes and functions may not have changed, or simply may not yet be deployed. Check with HP-PPM Support for specific questions. If the data element is not listed or the information is incorrect or incomplete, please advise by sending email to HP-PPM Support for inlcusion in this document.

The Percentage Complete attribute reflects the amount of work accomplished divided by the total amount of work estimated for the task. When Time Sheet hours are being utilized to update work plan tasks, hours charged against tasks by unassigned resources (people) are not considered in the % Complete calculation. This value may be set or calculated, depending on how the project and\or task is configured to be managed as follows:

• Manual Entry   This attribute value can be set by the task owner to reflect estimated work completed.This should not be done for projects that are being updated thorugh time sheet entry.
• Calculated Value   The value of this field is automatically calculated when time sheet entry is enabled. Percent Complete is maintained at the resource and task level. This calculation is Actual Effort hours to date divided by Actual Effort hours to date plus Estimated hours to complete (commonly referred to as Estimated at Completion (EAC). Please note, hours charged against tasks from unassigned resources are added to the Task Actual Hours but are not considered in the % Complete calculation based on current configuration.

Access Grants are configuration elements which define a specific capability to create, view, edit or delete a specific Request Type object. Multiple Access Grants are combined under a Security Group to facilitate common data needs across common roles to many stakeholders. While many individual Request Type specific attributes are controlled based on the Work Flow, you must have the associated Access Grants through the inclusion of a Security Group to even see the Request. Only system Administrators can effect changes to Security Groups and Access Grants

Examples of Access Grants.
• Time Mgmt: View Time Sheets
• Demand Mgmt: Edit Requests
• Project Mgmt: Edit Work Plan Templates

Activity is a table driven, broad categorization utilized at the task, summary task and Time Sheet work effort level. This attribute serves as a filtering mechanism and is the primary method for the application of accounting capitalization rules (SOP 98-1). This attribute is not currentntly being utilized but will be configured and implemented as part of the project accounting initiative. It is planned to be utilized at the Work Plan Phase level, and will therefore be set inside the Project & KTLO Work Plans, and not involved in Time Sheet Entry.

The Actual Duration is the calculated number of workdays based on the Scheduled Finish date less the Scheduled Start date. If the Task has started, then the Actual State date is used. If the Task is Finished, then the Actual Finish date is used. Workdays are based on the Demand Management, Enterprise Calendar which reflects Holidays. Summary level tasks Duration is based on the earliest Actual Start date (Scheduled Start date if none of the tasks have been started) and the latest Scheduled Finish date (unless all tasks have been Completed or Cancelled, in which case the Actual Finish date is used) of all sub-tasks of the summary task.

The Actual Effort expended on the task can be gathered (by enabling the Actual Effort field in Project Type Settings) thorugh entry against a Project Task. Using the basic function (without Time Management & Time Sheet Entry), hours can be entered from either the web application based on a Task view or in the Project Workbench on the Details tab or columnar listing. The actual hours entered must reflect the cumulative hours to date for the task. As this is not a transaction based entry, an algorithm prorates the hours among the assigned Resources (see the Resources tab in the task details) based on the Scheduled Effort hours as a percent of total Scheduled Effort hours. It then spreads the hours evenly across all the days between the Actual Start date and the current entry date based on the availability of each resource.
      With Time Management & Time Sheet entry enabled, all Actual Effort is entered against a Project Work Plan Task or a Request on a Time Sheet Transaction basis.

The Actual Start date indicates the date that work started on the task deliverable. This attribute is automatically set to the current date when the task State is changed from Ready to In Progress and should be populated on the day the work starts in order to provide effective communications across the project team related to project status and issues. The algorithm which allocates actual effort among the resources and across time uses the Actual start date to determine when actual hours will be reflected in the Assignment Load Report. This field must be populated prior to the entry of the Actual Finish date in order for the Actual Duration of the task to be calculated. The Actual Start date for a summary task will be the earliest date entered on any of it's sub-tasks.

The Actual Finish date indicates the date that work completed on the task and the deliverable was finished. This attribute should be populated on the date the work finishes in order to provide effective communications across the project team related to project status and issues. This field will trigger the calculation of the Actual Duration and will automatically set the % Complete to 100 and change the task status to Completed. The Actual Finish date for a summary task will be the latest date entered on any of it's sub-tasks.

The Application attribute is a menu selectable name which identifies the primary application impacted by the requested change. Other applications, teams or areas impacted by, or involved in, the implementation of the change would be included in the Potential Applications Impacted and Other Potential Impacts attributes in the Assess & Solution section. The Application list is maintained in the Application - Enabled validation list and includes the Application Name and the contact email address for each. This attribute and validation provide a means to automatically notify the Application SME (Subject Matter Expert) that their input and collaboration is required. This list is maintained by the Application Support Team. Please forward requests for specific updates (Applications names [NO version number] & SME contacts) to Application Support.

The Assess & Solution section of the v7.1 Change Request includes those fields which define the Solution and Deployment approach for execution. These values are editable through the Definition and Assessment steps of the work flow, but then are locked as the Change Request is released for prioritization or scheduling. See Change Request for more details and context.

The Assessed By person is responsble for defining the solution and gathering all of the Assessment and Estimation information. They are the only person who can forward the Change Request for Review & Prioritization or for Scheduling from the Assessment Step. This field is required at Definition work flow step completion. The Assessed By can assign the request to other team members for collaborative development of the information. See Change Request for more details and context.

The Assessment Priority drop down list reflects the Sponsor's sense of urgency relative to gathering the Assessment and Estimation information related to the implementation of the solution, not the implementation itself. This field may be populated on Entry but is required during Defnition and Assessment work flow steps. This field is locked and uneditable after implementaiton estimates have been completed. See Change Request for more details and context.

An Asset in HP-PPM is currently not utilized and is undefined.

An Asset Class is an Attribute that provides Sorting & Reporting Classifications in the Proposal Management function.

The Assigned field is utilized to provide access to team members who need to collaborate on a particular work flow step in the Change Request process, and facilitates the selection of mulitple Assignees concurrently. This allows collaboration during the definition, assessment and execution steps of the work flow process. The predecessor of this attribute, the Assigned To field, (currently being utilized in the Project and Proposal Requests), is limited to a single Assignee.

The Assigned To attribute is utilized in Project and Proposal request types for the routing and access control to data elements. By selecting a person from the drop down menu, you are effectively sending the Request form to the person's My Requests portlet which on their Team Member preconfigured dashboard. This portlet automatically lists and links to all Request Types which are currently assigned to the user (i.e. it reflects those actions which are awaiting your attention). Other behavior associated with the Assigned To field are specific to Request Types and associated Workflows. A response is expected within 24 hours. If you are assigned a Request and it's not clear as to your involvement, please contact the Document Contact or Workflow step manager so that it can be reassigned if directed in error.

A Budget is a system object which consists of cost type lines which indentify cost values by period (monthly) in thousands of dollars. The line items are associated with budgeted department numbers, general ledger codes, and represent the estimated cost and timing to implement the associated initiatives. The Staffing Profile cost associated with resource ROLES, valued based on Portfolio rates per hour, can be rolled into the associated budget as estimated labor and contract costs. The Budget object receives actual labor costs from the Time Sheet entry process and carries those in a comparative view by month. Actual non-labor costs are not currently input or fed to the HP-PPM budget. The Staffing Profile, if maintained in an "Estimate at Completion" perspective, provides a continuously updated financial forecast of both labor and capitalized labor expenditures. For more details on other Governance, analytical and management components which utilize Budgets see Programs and Scenarios

The Budget Labor Category field on each line of the Staffing Profile will determine the budget line the labor value is rolled up into. Each category is reported on a separate line in the budget, based on the hours and rate assoicated with the line item Role. Although the field is not required if the Staffing Profile is not synched with a Budget (set through the Change Header button on the Staffing Profile), synchronization attempts without this value on any single line (with hours or not) will generate a warning message and fail to move any laobr values to theBudget.

The Built By person is responsible for the completion of the change once it has been released for execution. This person must populate the Estimated Start Date and Target Production Deployment Date on the first SAVE of the CR in the Scheduling step. The CR should not be updated in the Scheduling step until resources are available to begin work. Once the Dates and Assignees are entered, the Built By moves the CR into the Working status. At this pont the DATE fields are no longer editable. The Built By is the only person that can enter the Complete or Stop Work status. If work has stopped for any reason, the CR should be returned to the Prioritization Step. If released for continuation or completion, the Date fields will be cleared when the CR moves into Scheduling for updating. See Change Request for more details and context.

The Business Impact attribute is a text field utilized in the Change Request, Risk, Issue and Scope Change Requests. This field is specifically included to capture the impact of the problem, proposed change, risk or issue on the business, project or project deliverables. The objective is to define the metrics to value the impact so that evaluation based on strategic priorities and cost benefit analysis can be completed. Included here should be any customer, transaction, volume, revenue, cost or other specific data. This data should relate specifically to the problem, issue, risk or Scope Change Request defined in the Detailed Description attribute.

The Business Problem is a concise description of the negative impact of the issue. This is a required field on initial Entry, and during the Defining and Prioritization work flow steps. This field is locked and uneditable after the implementation estimates have been completed. See Change Request for more details and context.

The Capacity field in the Resource Profile contains a percentage which is applied to available work hours and reflects workhour capacity for consumption by assigned tasks. This may reflect project, non-project, keep-the-lights-on and\or maintenance tasks, based on the Resource Managers need to define, assign, track and report where their resource utilization is going. Tracking non-project tasks is a Resource Management option, so enterprise wide evaluations based on skill sets that are available in more than one area should be carefully undertaken.

The Category attribute appears in both the Resource Profile and in the Advanced Tab included in the Staffing Profile line item definition. While the two attributes are related, they serve different functions and have no systematic or behavioral connection. In both cases the attribute indicates a resource type as either: Contractor, Full Time Employee, Part Time Employee or Consultant. The Resource Profile Category will be updated by the LDAP\Active Directory automated process from the Employee Master in 2008. This attribute has no known behavior based on our configuration. It could be used to set ROLE based rates, but we are only utilizing the ROLE and Organization attributes for rate application to estamated labor. The Staffing Profile labor category, which includes the same values, may be utilized to drive the rate valuations associated with ROLE estimates for Proposal processing, and is a required field for Proposals designated as Capitalization eligible.

The Change Request is a Request Type and workflow, used in IT, to define changes to applications which are small or simple enough to implement outside of a formal project. Typically all of the resources to complete the work are managed by a single manager or group. As CRs (as Change Requests are referred to) get defined and estimated, it may be discovered that the solution is either too large or complex to execute, so they may be closed out to a project or as an individual requirement to a Proposal. There is no capability to track time directly against a Change Request, so many are added as tasks to non initiative project work plans to facilitate tracking development time against the solution. Security and edit access to the various fields in the form are controlled based on a combination of the users named on the form in specific roles in combination with the specific work flow step the Change Request is in (see Stakeholders listed below, by step).

• Step 0 - Create the Change Request - Status Not Sumbitted   Any Demand License holder can enter an HP-PPM Change Request. After logging into HP-PPM, under the Demand Management Menu in the left nav bar, select Create a Request, then Change Request. The initial objective is to fully define the problem and all considerations for it's resolution. The Creator would typically enter the following Request attributes:
• Request Status    The status of a request represents the state of the document and is determined based on the current work flow step of the associated process. As the Work Flow steps are executed, the document is delivered to the appropriate next step and Stakeholders are notified via email. The Request Status should reflect the activity to be executed during the step, and may not reflect the current status or condition of the underlying information, depending on activity taken or pending in the current work flow step.
• Request Name   A concise title (40 character limit) by which the Request will become known is a required field. This can only be changed by the Document Contact after initial review and not after the Definition step has been completed.
• Application    This drop down selection menu in the Change Request is a required field on initial entry and indicates the primary technology component requiring change. The Document Contact should insure that a knowledgeable technologist familiar with the Application is engaged early in the process. Secondary Application impacts should be included in the Other Applications Impacted field to provide Alerts and Notifications to designated application owners.
• Sponsor Priority    This drop down selection menu in the Change Request includes: Low, Medium, High, Critical and On-Hold. This field is editable in the Entry, Definition and Prioritization steps.
• Business Problem    This 200 character required field should define the negative impact of the current condition. It is editable in the Definition and Assessment steps.
• Assessment Priority    This drop down list reflects the Sponsors sense of urgency relative to gathering the Assessment and Estimation of implmentation costs and efforts, and not for implementing the solution. The available values: Low, Medium and High. This attribute is required prior to Definition Completion.
• Existing Condition    This 1,800 character field should describe the current problem, behavior or condition which is causing the need for the requested change.
• Desired Date    This calendar date selection reflects the Sponsor's need for the completion of the change implementation.
• Document Contact    This work flow control person co-ordinates the completion and management of the CR until it is released for Scheduling. The Document Contact is typically the Sponsor representative and responsible for managing the CR through completion, cancellation or closure. In the Entry step this is a required field and triggers an email notification to the person selected when the Change Request is Submitted.
• Requested By    Anyone listed in the Directory can be assigned to the Requested By attribute. They will not necessarily have, and do not require, any HP-PPM access. This person should be the business owner or beneficiary requesting the change. This person is considered the Sponsor of the Request and should be able to articulate the value and need for the requested item. If the Change Request is worked and implemented, the Requested By Sponsor must have the authority to authorize the utilization of the resources based on the estimated time and cost of the work.
• Created By    is the person who initially entered the Request and populated some of the definitonal values. This value is automatically added to the Request record based on the login ID. If the Creator wants to be able to continue editing the Change Request after initial submission, then the Creator must Assign themselves to the Request as the Creator has limited edit access (as the Creator) after submission.
• Assigned   The Assigned attribute provides the ability to route the Change Request to other Stakeholders for collaborative resolution. Mulitple names can be selected in this field. Except on initial Entry and Scheduling, any names in this field are cleared at the completion of each work flow step. Those in the Assigned field will have edit access to the document based on work flow access controls. If the Created by person wants to Save the CR and continue the intial entry, he\she should assign the document to themselves, otherwise assign the document to the Requested By person or their representative. The person named as the Created by will not have edit access to the CR once submitted. A valid Demand License holder must be listed in the Assigned field at all times, as it reflects who has the responsibility to act.
• Proposed Change    This 1,800 character field should define the desired new behavior, adjustment or requirements to be implemented to address the issue or problem. In a more complicated change, this section and attribute would typically be defined by the person assigned to assess and estimate the implementation cost and effort. In a simple change, this might be completed by the initiator.
• Risks    This 1,800 character field should define any risks associated with either not addressing the problem; addressing the problem in general; or specifically related to the proposed solution. If additional information is available or required, documents can be attached in the reference section and identified here.
• Dependencies    This 1,800 character field should identify any dependencies related to the development and implementation of the proposed solution. Dependencies considered should include resource, other project, proposals or development efforts required as predecessors, organizational, educational or training impacts or requirements.
• Potential Applications Impacted    The purpose of this multi-selection field (required at Assessment Completion) is to provide an opportunity to notify those in the organization whose technology applications may be impacted by, and therefore need to know about, this proposed change. An automatic notification will be sent to the Contact of Record for each application in the listing. Only applications identified as having a Contact, being generally understood, and potentially impacted by changes, will be maintained on the listing. Please submit additional entries (which must include a person to be alerted) to HP-PPM Support. Applications added to the Applications menu in the Summary section will be automatically added to this list as well.
• Other Potential Impacts    Like the listing above, the purpose of this multi-selection, non-application field (required at Assessment Completion) is to provide an opportunity to notify those in the organization that may be impacted by, and therefore need to know about, this proposed change. An automatic notification will be sent to the Contact of Record for each element in the listing. Only elements identified as having a Contact, being generally understood, and potentially impacted by changes, will be maintained on the listing.
• NOTE:   In order to simplify the process for inter-organizational CRs, the Assess & Solution section and fields are available at initial entry. While this will enable Request completion in one step, the work flow steps will still need to be executed in order to promote the Request into the Estimation step for Hours addition.


• >Step 1 - Define the Change - Status Defining   Review and completion of the definition is the respoonsbility of the Document Contact. The objective of this step is to provide an appropriate level of detail based on the complexity to enable an assessment of what will be required to complete and deliver the requested change. It is important to insure an initial review and identification of potentially impacted applications and areas so that adequate input can be collected and associated with the definition. In addition, the following field level activities would be expected:
• Request No.    This 5 digit control number is sequentially issued by the system, across all Request Types, and is utilized as a link to the Request in portlet representations.
• Request Name   A concise title (40 character limit) by which the Request will become known is a required field. This can only be changed by the Document Contact after initial review and not after the Definition step has been completed.
• Application    This drop down selection menu in the Change Request is a required field on initial entry and indicates the primary technology component requiring change. The Document Contact should insure that a knowledgeable technologist familiar with the Application is engaged early in the process. Secondary Application impacts should be included in the Other Applications Impacted field to provide Alerts and Notifications to designated application owners.
• Sponsor Priority    This drop down selection menu in the Change Request includes: Low, Medium, High, Critical and On-Hold. This field is editable in the Entry, Definition and Prioritization steps.
• Business Problem    This 200 character required field should define the negative impact of the current condition. It is editable in the Definition and Assessment steps.
• Assessment Priority    This drop down list reflects the Sponsors sense of urgency relative to gathering the Assessment and Estimation of implmentation costs and efforts, and not for implementing the solution. The available values: Low, Medium and High. This attribute is required prior to Definition Completion.
• Existing Condition    This 1,800 character field should describe the current problem, behavior or condition which is causing the need for the requested change.
• Desired Date    This calendar date selection reflects the Sponsor's need for the completion of the change implementation.
• Priority Rank Order    This is a numeric only field available in all work flow steps to facilitate prioritization of Change Requests.
• Document Contact    This work flow control person co-ordinates the completion and management of the CR until it is released for Scheduling. The Document Contact is typically the Sponsor representative and responsible for managing the CR through completion, cancellation or closure. In the Entry step this is a required field and triggers an email notification to the person selected when the Change Request is Submitted. Only stakeholders with a Demand License can be selected, and only the CR Creator, the current Document Contact or the Requestor can change the Document Contact selection.
• Assigned   The Assigned people will always have edit access to the document, based on attribute and work flow controls. In the Defining step of the Change Request, the Document Contact and the Assigned may re-assign the document to other stakeholders for elaboration. After completion of your contribution, you should delete your name from the Assigned list.
• Assessed By    This field designates and identifies the person responsible for gathering and entering all of the Assessment and Estimation information. This field is required at the work flow step completion for Defining the Change and sending the request forward to Assess and Estimate. The Assessed By can assign the request to other team members for collaborative development of the information. Only the Assessed By individual can complete the Assessment work flow step and return the Request to the Document Contact for Prioritization and Review, or foward to the Built By person for Release Scheduling. The Assessed By can only be selected by the Document Contact.
• Proposed Change    This 1,800 character field should define the desired new behavior, adjustment or requirements to be implemented to address the issue or problem. In a more complicated change, this section and attribute would typically be defined by the person assigned to assess and estimate the implementation cost and effort. In a simple change, this might be completed by the initiator.
• Risks    This 1,800 character field should define any risks associated with either not addressing the problem; addressing the problem in general; or specifically related to the proposed solution. If additional information is available or required, documents can be attached in the reference section and identified here.
• Dependencies    This 1,800 character field should identify any dependencies related to the development and implementation of the proposed solution. Dependencies considered should include resource, other project, proposals or development efforts required as predecessors, organizational, educational or training impacts or requirements.
• Potential Applications Impacted    The purpose of this multi-selection field (required at Assessment Completion) is to provide an opportunity to notify those in the organization whose technology applications may be impacted by, and therefore need to know about, this proposed change. An automatic notification will be sent to the Contact of Record for each application in the listing. Only applications identified as having a Contact, being generally understood, and potentially impacted by changes, will be maintained on the listing. Please submit additional entries (which must include a person to be alerted) to HP-PPM Support. Applications included in the Applications menu in the Summary section will be automatically added to this list as well.
• Other Potential Impacts    Like the listing above, the purpose of this multi-selection, non-application field (required at Assessment Completion) is to provide an opportunity to notify those in the organization that may be impacted by, and therefore need to know about, this proposed change. An automatic notification will be sent to the Contact of Record for each element in the listing. Only elements identified as having a Contact, being generally understood, and potentially impacted by changes, will be maintained on the listing.


• Step 2 - Assess & Estimate - Status Assessing    The purpose of this step is to assess the issue and provide solution alternatives and estimates for implementing the requested change. Responses should be included for any Risks or Dependencies which are noted. If insufficient information is not provided to craft or determine a solution, the Change Request can be returned to the Document Contact for additonal information. Only the designated Assessed By person can close this work flow step.
• Business Problem    This 200 character required field should define the negative impact of the current condition. It is editable in the Definition and Assessment steps for collaborative Solutioning.
• Assessment Priority    This drop down list reflects the Sponsors sense of urgency relative to gathering the Assessment and Estimation of implmentation costs and efforts, and not for implementing the solution. The available values: Low, Medium and High. This attribute is required prior to Definition Completion and is editable by the Document Contact during Assessment.
• Existing Condition    This 1,800 character field is required and should describe the current problem, behavior or condition which is causing the need for the requested change.This attribute is required prior to Definition Completion and is editable by the Document Contact and Assessed By during Assessment to facilitate collaborative solutioning.
• Priority Rank Order    This is a numeric only field available in all work flow steps to facilitate prioritization of Change Requests.
• Assigned   The Assigned people will always have edit access to the document, based on attribute and work flow controls. In the Assessing step of the Change Request, the Assessed By, Document Contact and the Assigned may re-assign the document to other stakeholders for elaboration. After completion of your contribution, you should delete your name from the assigned list.
• Assessed By    This field designates and identifies the person responsible for gathering and entering all of the Assessment and Estimation information. This field is required at the work flow step completion for Defining the Change and sending the request forward to Assess and Estimate. The Assessed By can assign the request to other team members for collaborative development of the information. Only the Assessed By individual can complete the Assessment work flow step and return the Request to the Document Contact for Prioritization and Review, or foward to the Built By person for Release Scheduling. The Assessed By can only be selected by the Document Contact.
• Built By    This field designates and identifies the person responsible for scheduling and completing the solution implementaiton. This field is required at the work flow step which Releases the CR for Scheduling (either Assessing or Prioritization). The Assessed By or Document Contact can assign the Built By stakeholder. The Built By is the only person who can complete the work flow for Scheduling, Release for Production and Complete.
• Proposed Change    This 1,800 character field should define the desired new behavior, adjustment or requirements to be implemented to address the issue or problem. In a more complicated change, this section and attribute would typically be defined by the person assigned to assess and estimate the implementation cost and effort. This field remains editable by the Document Contact as well as the Assessed By during the Assessment step to facilitate collaborative solutioning.
• Risks    This 1,800 character field should define any risks associated with either not addressing the problem; addressing the problem in general; or specifically related to the proposed solution. This field remains editable by the Document Contact as well as the Assessed By during the Assessment step to facilitate collaborative soltuioning. If additional information is available or required, documents can be attached in the Reference section and identified here.
• Dependencies    This 1,800 character field should identify any dependencies related to the development and implementation of the proposed solution. Dependencies considered should include resource, other project, proposals or development efforts required as predecessors, organizational, educational or training impacts or requirements. This field remains editable by the Document Contact as well as the Assessed By during the Assessment step to facilitate collaborative soltuioning.
• Potential Applications Impacted    The purpose of this multi-selection field (required at Assessment Completion) is to provide an opportunity to notify those in the organization whose technology applications may be impacted by, and therefore need to know about, this proposed change. An automatic notification will be sent to the Contact of Record for each application in the listing. Only applications identified as having a Contact, being generally understood, and potentially impacted by changes, will be maintained on the listing. Please submit additional entries (which must include a person to be alerted) to HP-PPM Support. Applications included in the Applications menu in the Summary section will be automatically added to this list as well.
• Other Potential Impacts    Like the listing above, the purpose of this multi-selection, non-application field (required at Assessment Completion) is to provide an opportunity to notify those in the organization that may be impacted by, and therefore need to know about, this proposed change. An automatic notification will be sent to the Contact of Record for each element in the listing. Only elements identified as having a Contact, being generally understood, and potentially impacted by changes, will be maintained on the listing.
• Estimated Assessment Completion Date    This calendar date selection is required on the first save of the CR by the Assessor, in the Assessing step.
• Estimate Assumptions    Include any Role or Organizaitonal breakdowns that are included in the total Estimated Hours field. All other requirements and\or dependencies should be addressed here. (Not the resolution or management, just what are the assumptions about the dependencies, risks and requisites built into the hours). This field is only editable by the Assessor or his\her Assignees.
• Estimated Hours    This estimate should be the consolidated total for all efforts required through deployement. This value is the work time, not duration, and should be the hours expected and reported through time sheets, if so tracked. A role and organizational breakdown of hours should be included in the Estimate Assumptions field if applicable. This field is locked when the Change Request is released for Build and Deployment. This field is only editable by the Assessor or his\her Assignees.


• Step 3 - Sponsor Review & Prioritization - Status Prioritizing    This step provides a holding and prioritization management queue for the Sponsoring organization. If resources are not available, or other considerations are still unknown, the Document Contact can "Park" the change here for subsequent consideration. Only fields related to change management, scheduling and execution remain editable on the CR form. The Document Contact can release directly to scheduling (depending on Portfolio procedures and authorizations, Close the Change Request out to an HP-PPM Project or HP-PPM Proposal, Cancel the CR or return the CR to Step 1 for rescoping. If the CR is returned to Step 1, all estimation field values are written to the Notes section and then cleared.
• Sponsor Priority    This drop down selection menu in the Change Request includes: Low, Medium, High, Critical and On-Hold. This field is editable in the Entry, Definition, Prioritization & Scheduling steps.
• Desired Date    This calendar date selection reflects the Sponsor's need for the completion of the change implementation.
• Priority Rank Order    This is a numeric only field available in all work flow steps to facilitate prioritization of Change Requests.
• Assigned   The Assigned person will always have edit access to the document, based on attribute and work flow controls. Only Demand License holders are selectable.
• Built By    This field designates and identifies the person responsible for scheduling and completing the solution implementaiton. This field is required at the work flow step which Releases the CR for Scheduling (either Assessing or Prioritization). The Assessed By or Document Contact can assign the Built By stakeholder. The Built By is the only person who can complete the work flow for Scheduling, Release for Production and Complete.
• Potential Applications Impacted    should be reviewed after solutioning to insure that all potentailly impacted parties are notified and have an opportunity to participate in the effort definition and estimation. The Document Contact is responsible for insuring that all collataral impacts are considered and communicated. Email Notifications will be sent to the contacts associated with all new Applications, as added.
• Other Potential Impacts    should be reviewed after solutioning to insure that all potentailly impacted parties are notified and have an opportunity to participate in the effort definition and estimation. The Document Contact is responsible for insuring that all collataral impacts are considered and communicated. Email Notifications will be sent to the contacts associated with all new Impacted Areas as added.


• Step 4 - Pending Release - Status Scheduling    This step provides a bridge and queue for pending Change Requests which have been approved for execution. Prioritization and release is primarily resource constrained but Enterprise priority dependent. Once the Change Request has been Released for Scheduling, only resource constraints should delay release for build. Only the Built By stakeholder can set Estimated Start Date, Target Deployment Date and complete work flow step controls. WARNING: DO NOT ASSIGN RESOURCES OR ESTIMATED DATES UNTIL WORK CAN ACTUALLY BEGIN AS THESE DATES ARE NOT EDITABLE AFTER ASSIGNMENT.
• Priority Rank Order    This is a numeric only field available in all work flow steps to facilitate prioritization of Change Requests.
• Assigned   The Assigned person will always have edit access to the document, based on attribute and work flow controls. Only Demand License holders are selectable. All team members required to contribute to the build and deployment of the Change Request should be assigned at this step by the Built By. They will receive an email Notification of their participation requirement. They will only have access to the Assigned field and the Notes and Reference section of the Change Request.
• Built By    This field designates and identifies the person responsible for scheduling and completing the solution implementaiton. This field is required at the work flow step which Releases the CR for Scheduling (either Assessing or Prioritization). The Assessed By or Document Contact can assign the Built By stakeholder. The Built By is the only person who can complete the work flow for Scheduling, Release for Production and Complete.
• Potential Applications Impacted    This field remains editable by the Document Contact during scheduing.
• Other Potential Impacts    This field remains editable by the Document Contact during scheduing.
• Estimated Start Date    This date is the planned schedule start date and it's primary purpose is to advise the CR Stakeholders of the immenient start. It can only be populated by the Built By and is required on the first SAVE of the CR in this work flow step. If resources can not be identified, the CR should remain in this state without assignment, or Estimated Start Date. If the CR has been Assigned and Released for execution, the expectation is that it is being actively worked. Once the Scheduling work flow step is completed, this field is locked and cannot be updated without going back through the Sponsor and Document Contact.
• Target Production Deployment Date    This calendar selectable date is required when Releasing the CR for execution. It should be based on the Estimated Start Date, estimated hours and other resource commitments. This date represents the planned release date to Production of code or operational implementation of the change. This date is utilized for release planning to determine appropriate packaging and migration activities. Once the Scheduling work flow step is completed, this field is locked and cannot be updated without going back through the Sponsor and Document Contact.


• Step 5 - Build and Deploy - Status Working    Only Built By can Complete or Stop work and Return to Step 3 for Sponsor intervention. Only Priority Rank Order, Assigned To, Notes and Reference sections are available for edit at this step.
• Priority Rank Order    This is a numeric only field available in all work flow steps to facilitate prioritization of Change Requests.
• Assigned   The Assigned person will have edit access to the Assign field, Notes & Reference functions in this work flow step. As time worked against the Change Request may be captured in a Project Work Plan, additional communications and transactions may be required against other HP-PPM objects, depending on Portfolio procedures.


• Step 6 - Complete -   Only Built By can close the work flow to Complete status. This locks all fields and sends a notification to the Sponsor (Requested By) and Document Contact stakeholders.



• Step 7 - Cancel -    The Change Request can be cancelled by the Document Contact from either Step 1, Define Change or Step 3, Sponsor Review. Cancellation requires a Note be added to explain the reson for the cancellaiton. When cancelled, all fields are locked and notifcations are automatically sent to the appropriate stakeholders, depending on which steps have been completed.



• Step 8 - Close to Initiative -    The Document Contact can Close the Change Request to an Initiative. This action would imply that the requested change is too complex or expensive to be executed as a Change Request. A Note entry will be required to identify the associated HP-PPM Proposal or HP-PPM Project into which the desired change has been assimilated. This action locks all fields and sends automatic notifications to the Sponsor (Requested By), and other appropriate stakeholders, depending on which steps have been completed.

A Contingency Plan is a Risk Response which involves the creation of an Action Plan which will be executed should the identified Risk be realized. This response is extremely useful to insure a thorough understanding of the Risk and it's potential impact on the Project, deliverables or business performance. Based on the Risk triggers, there may not be adequate time for planning a response after it is realized, so a Contingency Plan is critical for highly probable Risks or large impact Risks that can not be mitigated. The Risk Record contains a check box which indicates that a Contingency Plan is, or has been prepared. The Contingency Plan should be attached to the Risk Record when finished. See Risk Management Process in the Change Management Glossary for more details.

Cost and Effort is one of the tabs in the Project Type Object View. This tab contains two system functions which can be activated. The first is to enable Use Time Management to track actual effort against this project. The Second is to Enable Financial Management.

The Cost Rate field is set in the Cost Rate Table, and provides an hourly labor cost rate which is applied to Staffing Profiles and Project Work Plans if Financial Management has been enabled. This extremely flexible table enables assigning rates at the global level, or based on the Resource's Role, Organization, Category or individually, as well as Request type or Project, or any combination thereof. The current rates reflect a blended, fully loaded labor rate used for strategic planning purposes, and is set for each Role based on their organizational unit. As we define the project cost function and data flow, the valuation of project task hours may be applied by Great Plains, Hyperion or HP-PPM.

The Created By field identifies the person who initially entered the Request. This attribute is utilized on the Proposal, Project and Change Request objects. In the case of a Change Requst, if the Creator wants to be able to continue editing the Request after initial submission, then he\she must Assign themselves to the Request as the Creator has limited edit access (as the Creator) after submission. This field is populated by the system and is not editable at any time. See Change Request for more details and context.

Critical Path Running Late is one of seven Exception Rules which can be enabled to generate a flag at the task level reflecting a project issue which requires attention. These Rules are enabled in the Project | Settings | Exception Rules tab. This Exception flag indicates that the a predecessor task in this Milestones Organizational Units, which maintained directly in HP-PPM.

The Dependencies field is an 1,800 character attribute that should identify any dependencies related to the development and implementation of the proposed solution. Dependencies considered should include resource, other project, proposals or development efforts required as predecessors, organizational, educational or training impacts or requirements. See Change Request for more details and context.

The Description attribute is a text field utlized to define, in detail, the associated object. It may be utilized in different ways, depending on the object.

• iChange Request Descritption field is a hidden field. It is auto-populated from the Request Name attribute as it is displayed in the Request Header. See Change Request for more details and context.
• Project Task Description field is a text field of 300 characters. Only 64 characters are visible through the one line entry screen from inside the workbench on the Task Details tab. The contents of this field have not been found available from any view on the web application side of the system and in no printed task or project reports.

The Desired Date reflects the wishes of the Change Request Sponsor. Any contractual obligations should be defined in the Risks and Dependencies fields, as appropriate. This field is editable at Entry and during Definition and Prioritization work flow steps. See Change Request for more details and context.

The Detailed Description attribute is included in the Issue, Risk and Change Request Records. It contains the complete definition of the issue, problem or opportunity. This attribute should clearly answer the "what is this about" question. The impact on the business, system, project and implementation should be included in the Business Impact and Implementation Impact attributes, as appropriate.

The Direct Manager attribute is on the Resource Profile General tab and is the only person outside of HP-PPM support that can update many of the Resource Profile attributes, including replacing themselves with a new Direct Manager. Only one Direct Manager can be assigned, and this should be limited to the person responsible for annual performance reviews and Time Sheet Entry compliance for the Resource. The Direct Manager can also audit time sheets, and submit time sheets as a Delegate for anyone they manage directly. The Direct Manager must have a Resource Management License in order to be selected through the Resource Profile Update Request.

The Document Contact is the person who co-ordinates the completion and management of the CR until it is Released for Execution. The Document Contact is typically the Sponsor or sponsor representative, and the only stakeholder who can Cancel, Close to Initiative or complete the Defining work flow steps. In the Defining step, he\she is responsible for Assigning the CR and gathering the information necessary to fully define the problem so that a solution can be crafted and estimated. The Document Contact is required on Entry and can only be changed by the current Document Contact or Requested By in the Defining step. See Change Request for more details and context.

The Task Duration is the number of days from the date the task starts to the date the task completes. This value may reflect partial days. The duration hour starts based on its predecessor finishing time within the day based on the project or resource calendar or the project or resource calendar and the constraint date. A duration field for both Scheduled and Actual is defined:

• Schedule Duration at the task level will drive the task Schedule Finish date. If you change the Duration and then reschedule, the Finish Date and all subsequent dependencies will be adjusted accordingly. If you change the task Finish Date, the task Duration will be adjusted to reflect the change in number of work days based on the project calendar.
• Schedule Duration at the summary task level Is derived from the earliest task Start Date and the latest task Finish Date of any sub-level task.
• Actual Duration is calculated based on the Actual Start Date and the Actual Finish Date of the task.

The Enable Financial Management check box is located on the Cost and Effort tab of Project Settings in the Project Workbench. If checked, two options are available for both Planned Labor Cost and Actual Labor Cost. The options are either to Automatically calculate based on scheduled or Actual effort and rate or to Manually enter the values on tasks and roll up the value to sub-projects and the master project level.

The Escalation Level of an Issue indicates at what organizational level the Issue is being worked for resolution. An Issue at the project level is the responsibility of the Project Manager and is being resolved within the project team. If an issue is beyond the scope or capability of the project team to resolve, then it would be escalated to the Program, IT PMO or Initiatives PMO for resolution. A Task roadblock that can be resolved by the Task owner of the task affected should be entered as Action Items within the project task, for follow-up, and not entered as an Issue.

The Estimate section of the v7.1 Change Request includes those fields which relate to the scheduling, hours and assumptions for the Build and Deployment execution. These fields are editable by the Assessor and those Assigned during the Assessment step. These values are locked following Assessment and are not editable during Build and Deploy. If the Change Request is returned to the Sponsor for Re-scoping, the Estimate values are written to the Notes section and cleared. See Change Request for more details and context.

The Estimate Assumptions field should include any Role or Organizaitonal breakdowns that are included in the total Estimated Hours field. All other requirements and\or dependencies should be addressed here. (Not the resolution or management, just what are the assumptions about the dependencies, risks and requisites built into the hours). See Change Request for more details and context.

The Estimated Assessment Completion Date is a required field at the first SAVE by the Assessed By in the Assess & Estimate work flow step. The primary purpose is to acknowledge receipt and notify the Document Contact and Requestor when they can expect a response. See Change Request for more details and context.

The Estimated Remaining Duration  can be updated to reflect the number of estimated days that it will take to complete all work related to a change request. This number represents calendar days, not days per resource.

The Estimated Finish Date is updated by the task owner to communicate the expected date the task will be completed. The primary function of this field is to communicate a schedule variance in advance or realization. This field can be used in conjunction with the "Late Estimated Finish" Exception Rule. If the Estimated Finish Date is more than the number of days set in the exception, beyond the Scheduled Finish Date, then the exception flag will be set for the task the next time the project file is SAVED. This field has no other functionality and is not updated based on subsequent transactions or events.

The Estimated Hours should be the consolidated total for all efforts required through deployment. This value is the work time, not duration, and should be the hours expected and reported through time sheets, if so tracked. A role and organizational breakdown of hours should be included in the Estimate Assumptions field if applicable. This field is locked when the Change Request is released for Prioritization or Scheduling out of the Assess & Estimate work flow step. If the CR is returned to Step 1, Defining, for ReScoping; the estimated hours and assumptions will be copied to the NOTES field and cleared. Rescoping is assumed to automatically change the solution, and therefore will require re-solutioning and esitmating. See Change Request for more details and context.

The Estimated Remaining Duration  can be updated to reflect the number of days required to complete a task. It must be enabled in the Project | Settings | Project Fields tab and may be restricted from displaying on the Task Assignee's Front Page, making it available only to the Project Manager. The primary function of this field is to communicate a schedule variance in advance or realization. This field can be used in conjunction with the "Not Enough Time Left" Exception Rule. If the current date plus the value of the Estimated Remaining Duration exceed the Scheduled Finish Date by the number of days set for the Exception, then the exception flag will be set for the task the next time the project file is SAVED. This field has no other functionality and is not adjusted based on subsequent transactions or events.

The Estimated Remaining Effort  can be updated to reflect the hours of work remaining to complete a task. It must be enabled in the Project | Settings | Project Fields tab and may be restricted from displaying on the Task Assignee's Front Page, making it available only to the Project Manager.

The Estimated Start Date is required and only editable in the Scheduling work flow step. It must be entered by the Built By on the first SAVE in the step. It should be set based on resource availability. If the portfolio manager wants to populate this date in advance based on forecasted resource availability, they should hold the CR in the Scheduling step until the work can actually begin in order to have an opportunity to update both the Expected Start Date and Target Production Deployment Date. Once the CR moves from Scheduling to Working, neither date is editable. In order to reflect an unplanned delay, the CR must be returned to Prioritization step for re-release. WARNING - The CR should not be released from scheduling until the resources are available to start work. See Change Request for more details and context.

The Estimated Start Date  is a value that is filled in either by the Application Owner or a member of the Application Owner's team. The value in this field will represent the date that work can potentially begin on the Change Request based on the application owner's or team member's initial assessment of the request.

Exception Rules   and associated flags can be set at the project level and are applied to all individual tasks (not summary level). These rules are enabled at the Project | Settings | Exception Rules tab. Exception Flags may be counted and utilized to determine and indicate the Project, phase and summary task level health. An x indicates a configurable (at the project level) parameter. The following Exception Rules may be available, depending upon Project Field and synchronization settings:

• Unassigned Tasks    A task is scheduled to start in x days and has no resource assigned.
• Late Tasks or Milestones   Task or Milestone is not yet "Complete", and the current date is x days past the Scheduled Finish date.
• Tasks Starting Late   Task is not yet "In Progress" (state), and the current date is x days past the Scheduled Finish Date.
• Late Estimated Finish   Estimated Finish Date is more than x days past the scheduled Finish date.
• Not Enough Time Left   Estimated Remaining Duration exceeds the time left between the current date and Scheduled Finish Date by x days .
• Predecessor Has Exception   At least one predecessor currently has an exception
• Critical Path Running Late   Critical path to this milestone is running late

The Executive Summary  is a narrative field on the Weekly Project Status Report that the Project Manager populates on a weekly basis. It should be developed for the project Sponsor, Business Owner and other executive level stakeholders. This field, when populated in the Weekly Status Report also updates the same field contained in the PFM Project record.

The Existing Condition attribute is the current behavior or state of the application, as it relates to the business problem. Use this field to provide a concise description of the application’s current functionality and why this is not meeting the needs of the business or customer. This field may be populated on Entry, but is required in the Definition and Assessment work flow steps. This attribute is locked and uneditable after implementation estimates have been completed. See Change Request for more details and context.

The For Week Ending field identifies Time Sheet periods for both creation and reporting. The work week is defined as starting on Saturday and ending on Friday COB (Close of Business). This convention was defined to coincide with Project Status Reporting requirements. Project Status Reports are due on Monday and are effective as of the prior Friday. This faciliates Project Team members time sheet entry on Fridays and provides analysis and evaluation time for the project managers.

The Dashboard Front Page is the default starting page for a user, once logged into the HP-PPM application. This system data view is highly configurabale by the individual user, and can include a wide range of individual, predefined "portlets". Each portlet is configurable based on the content to filter, sort and select based on dates, projects, etc. A default portlet has been setup for new users based on their project and HP-PPM access role. It typically contains assigned project tasks (past due and scheduled within next 10 workdays), assigned Issues and project gantt charts for projects participating in.

The Project Summary "Health" Indicator is a HP-PPM function which provides a visual reference to a project's overall status. While the field is not named specifically in the Project Schedule file, it is referenced and controlled in the Project Summary section of the Project Settings | Exceptions Rule tab inside the HP-PPM Workbench. It is reflected on the Project Overview and PFM Project Status section where it is referred to as the "Project Health" attribute. A percentage can be set for project exceptions. This indicator then reflects the percentage of open tasks remaining for the project which have any enabled exceptions against them. Completed, Cancelled and Bypassed tasks (status) are not considered in this calculation, therefore, a fewer number of exceptioned tasks will trigger these indications as the project progresses through it's life cycle. See also Project Health for more details.

The Impact attribute of the Risk record is a menu selectable ... See Risk and Risk Management - navigator glossary for more details.

The Implementation Impact attribute is a text field utilized in the Issue and Change Request objects. This field is specifically included to capture the impact of the implementation of the defined and\or selected solution on the project. The objective is to define the metrics to value the impact so that evaluation based on strategic priorities and cost benefit analysis can be completed. Included here should be all specific changes to projects and tasks already in process, as well as any new tasks or deliverables to be added. This data should include the cost in time and dollars (where known) related specifically to the Solution defined in the Solution attribute.

An Issue is a roadbock to project success. The primary purpose of an Issue is to escalate and communicate responsibility for problem resolution and capture unplanned project interferences for future project planning. Issues are the first element of a Lessons Learned process. While an Issue does not represent project work, it may involve additional work in it's resolution. It is typically something that is blocking (including lack of information), or will shortly block, our ability to proceed on schedule. It represents a problem which cannot be handled by the resource responsible for the delivery of the task which is being threatened. Issues are typically resolved by the Project Manager, but may be further escalated to the PMO or another organizational unit. Issues must always be assigned to an inidividual. The assigned individual must be made aware of the assigned responsbility, and is responsble to drive the resolution of the issue to completion, unless the issue is reassigned. See the Issues Management Process model or Project Issues system instructions for additional information. Attributes assoicated with Issues include:

• Issue ID   Issues are a special "Request Type" object in the HP-PPM system. All Request types are created with a system assigned, sequential, unique identification number which enables relationship links between various system objects. An "Issue" might be linked to a Project Task, or be transitioned into a "Scope Change Request" type prior to resolution or closure.
• Due Date should reflect the date on which the Issue will start to negatively impact the Project or Project deliverables.
• Project is a menu dirven search to select the project which will be impacted if the Issue is not resolved in a timely manner.
• Issue Name   A short description for identification. This 40 character field should be readable by non project content knowledgeable employees.
• Created By  automatically populated with the name of the person who initially entered the Issue.
• Date Identified  calendar popup to select the date the Issue was recognized.
• Issue Description   A complete description of the problem and its possible impact on the project or project deliverables.
• Priority   indicates the importance and need for Issue resolution.
• Escalation Level   A menu selection to indicate what level of the Organization is currently working the Issue. The choices will be Project, Program, PMO or Enterprise and determine which Dashboards the Issue is displayed on. Only the Project Manager should have access to escalate Issues.
• Status   Status reflects the following steps: Defining, Solutioning, Implementing, Closed or Cancelled. These value relate to the Workflow steps and reflect same.
• Assigned to   drop down menu to select assignee. This person should receive an automatic notification of their assignment. They are responsible for resolution or contribution. Issues should be addressed by assignee within 24 hours to acknowledge receipt and insure proper assignment quickly.
• Issue Resolution   This field should define the actions to resolve the Issue. Alternative approaches should be defined when known.
• Notes  Any team member can add notes, comments or considerations to this field. The author's name and time are automatically recorded. Each Assignee must contribute to the Issue. If it is assigned in error, and is reassigned, the reason and logic should be recorded in the Notes field. Any questions or queries should be focused on the Issue record. Email conversations outside of the Issue record are inefficient and result in an incomplete history of the Issue resolution and should be discouraged.
• References   Documents can be attached or linked, and URLs can be associated with the Issue. In all cases, the task which is threatened should be linked in the reference field for quick access. If the Issue can be linked from the Project Task Reference field, it should be.

Key Decisions Made  is a narrative field on the Weekly Project Status Report that the Project Manager populates on a weekly basis. This field should include explanations for any schedule changes or redirections made during the current week. Any decisions related to Scope Change Requests should be summarized.

Late Estimated Finish is one of seven Exception Rules which can be enabled to generate a flag at the task level reflecting a project issue which requires attention. These Rules are enabled in the Project | Settings | Exception Rules tab. If the Estimated Finish date is x days beyond the task Scheduled Finish date, then the exception flag is set for the task the next time the project file is SAVED. Exception flags may be utilized to gauge a summary task, phase or project's "health".

Late Tasks or Milestones    This is one of seven Exception Rules which can be enabled to generate a flag at the task level reflecting a project issue which requires attention. These Rules are enabled in the Project | Settings | Exception Rules tab. If the current date is x days beyond the task Scheduled Finish date and the task is not complete, then the exception flag is set for the task the next time the project file is SAVED. Exception flags may be utilized to gauge a summary task, phase or project's "health".

The LDAP interface provides the ability to pull data from other systems to insure data integrity between systems. The Active Directory attributes currently updating HP-PPM attributes on a nightly basis include:

• Last Name - Any new combination of Last Name + First Name will generate a new Profile in HP-PPM. Care should be utilized when creating initial resource profiles in other systems for contractor managment, as later corrections will generate new profiles in HP-PPM which will cause confusion on Time Sheet entry. Neither of these fields (Last Name or First Name) is updated after intial profile creation.
• First name - see note above.
• Email - this is the official company email address for the resource
• Phone Number - this is initially set as 404-568-8000 for IT resources, and is automatically updated once phone assignments have been made
• Department - This attribute, as displayed on the Resource Profile General tab is a drop list and is not updated from Active Directory. The Peoplesoft Department is being updated in the Resource Profile, HP-PPM Support Resource Workbench User Defined Field for reporting. This autoupdate may be integrated in future releases.
• PeopleSoft Name - this attribute is only accessible through the Resource Workbench and custom reports, and is stored in the workbench User Data field #1.
• HR Employee ID - this attribute is only accessible through the Resource Workbench and custom reports, and is stored in the workbench User Data field #2.
• Display name - this attribute is only accessible through the Resource Workbench and custom reports, and is stored in the workbench User Data field #3.
• Cost Center - this attribute is only accessible through the Resource Workbench and custom reports, and is stored in the workbench User Data field #4.
• Department Name - this attribute is only accessible through the Resource Workbench and custom reports, and is stored in the workbench User Data field #5. This attribute was added to the LDAP extract and update after the initial custom validation was established for this field on initial HP-PPM deployment. It will be integrated and update the Resource Profile Department field with the next Modification Release.
• Employee type - this attribute is only accessible through the Resource Workbench and custom reports, and is stored in the workbench User Data field #6. This attribute was added to the LDAP extract and update after the initial HP-PPM deployment. It will be integrated and update the Resource Category field with the next Modification Release.

The Location field in the Resource Profile indicates to which Region the employee or contractor is assigned. The current values are Regions 1 through 5 and HQ. These values have no known behavior or impact on Demand Mangement functionality.

A Mitigation Strategy is the result of a risk assessment, and represents a specific set of actions taken in order to reduce the likelihood that the risk will occur, or reduces the impact on the project, product or business if the risk does occur. This response should include project\task level changes to the project plan or assigned Issues to be executed in direct response to the risk. The indicator on the Risk record indicates whether or not mitigation is warrented. If so indicated, the Mitigation actions should be fully defined in the Mitigation Strategy field or referenced in this field and the associated documents attached in the reference field. Unlike a Contingency Plan which is not executed unless the risk is realized, the Mitigation Strategy is an acitionable plan to reduce the impact of the risk. See Risk Management Process in the Change Management Glossary for more details.

Microsoft Project Synchronization provides the ability to interface HP-PPM with independent MS Project Schedules via three modes.

• HP-PPM Controlled:   In this mode of synchronization, the project work plan is built and maintained in HP-PPM. However, after the export and creation of a Microsoft Project file, all fields maintained in both systems will be updated in the Microsoft Project file from the HP-PPM file. Fields not maintained synchronously (cost rates, text, custom fields) will not be affected. Notes entered into HP-PPM tasks will not appear in the MSP schedule (last validated in v7.0). This is the mode which should be selected in order to optimize our utilization and integration of project information across the enterprise. The primary need for this mode is the utilization of Effort Driven Schedules, as the HP-PPM Project Work Plan can only be duration driven. By exporting to Microsoft Project, it provides the ability to simulate "what if" analysis as well as more robust paper based reporting.
• Microsoft Project Controlled:   In this mode of synchronization, the project is built and maintained in Microsoft Project. After the initial import of the file, subsequent synchronizations update all synchronized fields in the HP-PPM file for the values in the Microsoft file. As this mode requires gathering of actuals in Microsoft Project, it is not available for our deployment. In this mode, all scheduling functionality is disabled as well as the ability to add or update any tasks or dates. In this case all changes must be entered first into MSP, and then synchronized with the HP-PPM work plan.
• HP-PPM Project controls Actuals:   In this mode of synchronization, the project is built and maintained in Microsoft Project. However, actuals are gathered through the HP-PPM Time Sheet entry and then update the MS Project actuals through subsequent synchronization. When selecting this mode, much of the HP-PPM functionality is disabled (all planning and task fields), so all schedule configuration changes must be made in the Microsoft file and then synchronized. Because of the complexity of this mode, many of the desired benefits of exception and notification reporting will be diminished without frequent synchronization. While this mode might be beneficial to transition projects "in flight" at deployment time, its utilization should be discouraged due to the inefficiencies suffered by the Project Manager in maintaining two systems of record. Note: The Final extensive Synchronization Testing was conducted at v7.1, and all material discrepancies had been resolved. However, because the synchronization function occurs at the TASK and not the Resource level, actual hours may spread across daily task hours differently. Utilization of this mode will cause distortions in the Demand Managment Resource Pools. This mode will not be allowed after Demand Management comes on line in late 2007.

The Name attribute of any object type (Project, Task, Risk, Change Request, Issue, etc) is typically a 40 character field which serves as an index for system queries and title for interested stakeholders. The name should be concise and as descriptive as possible. The utilization of acronyms or abbreviations should be discouraged to provide maximum communications benefit. See each record type for specific details. In most cases Names are not allowed to be changed after some point in the work flow to minimize confusion in consolidations and reporting.

Not Accomplished is a narrative field on the Weekly Project Status Report (request) that the Project Manager populates on a weekly basis. Planned Issue resolutions and project Milestones and events planned to be completed during the week, but not finished should be briefly explained.

Not Enough Time Left is one of seven Exception Rules which can be enabled to generate a flag at the task level reflecting a project issue which requires attention. These Rules are enabled in the Project | Settings | Exception Rules tab. The "Estimated Remaining Duration" field must first be enabled in the Project | Settings | Project Fields tab in order to utilize this Exception Rule. If the current date plus the Estimated Remaining Duration exceed the Scheduled Finish Date by the number of days set for the Exception, then the exception flag will be set for the task the next time the project file is SAVED.

The Notes field is included in all Request type records. This field enables the capturing of input from anyone accessing the record and automatically records the author and the date of the comment in the permanent Request Record.

Notifications are automatically triggered e-mails that are delivered through Outlook to the recipient. Recipients can be individuals, members of groups, or specific people listed on the Request or Work Flow. Notifications can also be triggered from Project Work Plans based on Assignments, Scheduled Start and Finish Dates, and changes in assignments. While the messages are standardized, they include specific attribute information included on the Request or Task. E-mails recipients can be selected from any resource included in the HP-PPM directory that have email addresses. An HP-PPM License is not required.

The Other Potential Impacts field is a menu selectable list of non-technology application areas, elements or functions. Each is associated with a Contact person. The intended purpose of this list was to facilitate Notification Alerts to the contact that the Change Request effort or objective may impact, or be impacted by, the proposed change. Any type of element can be added to the list as long as a contact name is included. The name and description should be included in such a way that it is identifiable and understandable to the broadest audience possible, in order to be of the most benefit. Mulitple selections can be made, and this list is a required entry at designated work flow steps. The default is blank, and there is a NONE element in the listing to assure that at least the Change Request Document Contact and the Assessed By managers review the list. The Notification function was not deployed in v2.0 of the Change Request due to delays in development. This attribute is utilized primarily for filtering Change Requests. New entries should be submitted to the Air Traffic Support Team via email to zz.at - HP-PPM. See Change Request for more details and context.

The Organizational Unit is a collection of individual people, or groups of people, with a common operational or planning function. See Type below for more information. The organizational unit field itself is a primary sorting and filtering field throughout the HP-PPM system. Organizations should be defined based on reporting needs, and not necessarily organizational chart relationships for other purposes. Many effort, load and time entry reports can be filtered and\or sorted by organizational unit. This attribute itself has no behavior, while it's association with a corresponding Resource Pool provides the backbone of the resource and capacity planning functions related to Portfolio Management. The Organization is utilized as one of the factors in assigning labor costs to Proposals and Projects. The Organizational model can be viewed via the Resource Management | Organization Model | Browse the Org Model menu selection. Organizational units are maintained by the HP-PPM Support Team. Any organizational changes should be submitted in org chart form through the reporting department manager. Individual organization member re-assignments can be submitted by any Resource or Project Manager via the Resource Profile Update The Organizational Unit Attributes are:

• Name  The name of the team, group or department.
• Department A validation list which should represent the Enterprise departmental structure. This attribute has been hijacked for other uses and will be cleaned up as time permits. The primary utilization is for reporting and filtering of Proposals.
• Type  denotes the purpose of the unit and it's behavior as defined below. This hierarchial structure is very effective for consolidated reporting at any level.
• A Department is associated with a budgeted department as reflected in the Great Plains system. While individuals may be assigned to a Department type Organizational Unit, it is typically a consolidation reporting and analysis entity or level. This is the highest level of the Demand Management hierarchy.
• A Group  is a "phantom" level Organizational Unit which consists of mutliple Teams and\or other groups where the consolided unit is significant for planning and resource management purposes. There are no limits as to the number of Group levels within the configuration.
• A Team  is a collection of individuals with a common Resource Manager. These individuals may have common or related skills. Individuals can only be assigned to one organizational unit, and the assignment is not date sensitivite (i.e.only the current assignment is defined, unlike Resource Pools). All resoruces involed in work delivery (vs. work management) should be included in an Organizational Team.
• Manager identifies the person who should be responsible for organizational reporting. The Organization Manager may be different than the Direct Manager of each of the resources as indicated in their Resource Profile. The organizational manager may also be different than the associated Resource Pool manager.
• Location  is a validation list which currently segregates Atlanta elements from those associated with Sales Regions..
• Budget can be associated with an Organization for KTLO (Keep the Lights On) kinds of organizations vs. project oriented efforts.
• Primary Organizaiton Unit This Yes\No radio button indicates whether the unit is a Primary or Matrix unit. Only a Primary Organization can be linked to a Resource Pool. The Resource Pool function contains the same hierarchial configuration capability as the organizational unit.
• Parent Organization Unit  is selected from a validation list of all other Organizational Units and facilitates consolidated reporting of actual hours, proposals, projects, CRs etc for all child organizations. Teams should have Group or Departmental type parents, Groups can have Group or Departement type parents.
• The Inheriting Region of the organizational unit is not currently utilized.
• Enabled This Yes\No radio button allows for Organizational Units to be dropped from current validation menu's and still maintained for reporting purposes. When disabled, you are unable to specify the Organization in filters or assign anyone to the organization.
• Direct Members  lists members of the organization with a link to their individual resource profiles.
• Linked Security Groups  allows the association on Security Groups to the organizational unit and is not currently utilized.
• Child Organizational Units  allows the selection and of other Organiational Units with a child relationship to this Organizational Unit
• Related Actions includes any pending Staffing Profiles against the organization. This function is not currently utilized as Staffing Profiles reflect demand for a Proposal or Project against a Resource Pool.

Planned Next Week is a narrative field on the Weekly Project Status Report that the Project Manager populates on a weekly basis. Planned Issue resolutions and project events not flagged as reportable milestones in the project schedule should be reflected here.

The Portfolio Management License enables the creation and manipulation of Scenarios. A Scenario is a collection of Proposals and Projects. Both the Staffing Profiles and the budgets (which can include the labor cost of the Staffing Profiles) are consolidated for evaluation and analysis. This virtual cost and work load by ROLE can then be evaluated against a virtual budget (like for the whole year, or a product development initiative) and a virtual resource pool. The objective is to be able to load balance your commitments based on your resource availability and to utilize the resulting budget by period (month) for forecasting purposes. Both of these are critical strategic and tactical planning functions dependent upon accurate staffing profiles with accurate estimates. Access to specific Scenarios, like Projects and Proposals, is controlled based on local document mangement. A Portfolio Management License must be requested by an existing Portfolio licensed Manager via submission of the Resource Profile Update Request.

The Potential Applications Impacted field is a menu selectable list of all technology applications. Each is associated with a Contact person. The intended purpose of this list was to facilitate Notification Alerts to the contact that some effort may impact, or be impacted by, the Proposed Change. The name and description should be included in such a way that it is identifiable and understandable to the broadest audience possible, in order to be of the most benefit. Mulitple selections can be made, and this list is a required entry at designated work flow steps. The default is blank, and there is a NONE element in the listing to assure that at least the Change Request Document Contact and the Assessed By managers review the list. The Notification function was not deployed in v2.0 of the Change Request due to delays in development. This attribute is utilized primarily for filtering Change Requests. New entries should be submitted to the Applications Support Team, from whose list this validation is maintained. See Change Request for more details and context.

The Predecessor is the sequence (number) of a task (row ID) or tasks, which will automatically affect the scheduled dates of the task when scheduling. There are many possible potential relationships between tasks: Start to Start; Finish to Finish; Start to Finish; Finish to Start. NOTE: There is no Automatic Scheduling function in HP-PPM, so dependencies will not be reflected in scheduled dates until you force a Reschedule after you make changes to dependencies, or dates for that matter.

Predecessor Has Exception is one of seven Exception Rules which can be enabled to generate a flag at the task level reflecting a project issue which requires attention. These Rules are enabled in the Project | Settings | Exception Rules tab. If the task has a predecessor task, project or Request, and the predecessor has an exception, and the current date is beyond the Scheduled Start date of the task, the exception flag is set for the task the next time the project file is SAVED. Exception flags may be utilized to gauge a summary task, phase or Project Health indicator.

The Priority Rank Order is a numeric field which can be utilized to prioritize a list of Change Requests for Reporting or Portlet presentation. This field has no access or work flow controls and is, therefore, always available for update by any Demand Management license holder. Please see Change Request for more details and context.

The Probability attribute of the Risk record is a menu selectable ... See Risk or the Risk Management Process in the Change Management Glossary for more details.

The Product Enhancement request is utilized to define small work efforts which can be issued and worked without formal review and authorization. Time can be logged against these requests. Generally the resources required to complete and deliver the work are managed under a single department or portfolio. There can not be additional resources (human or financial) required to deliver the desired change. This request should not be used for large scale work efforts that require multi-discipline participation to deliver as no incremental forecast for the work effort is added to the Demand Management data. The Product Enhancement functionality was implemented under the name of "Change Request" due to organizational history and project management immaturity. Please see the Change Request element for corresponding information as utilized.

A Proficiency Level must be associated with each skill set assigned to a Resource. This Resource Profile setting is a number between 1 -5. To date there has been no definition and\or communication about how this field is utilized or what the proficicency levels signify to the Resource Managers. The Skill attribute was the key Demand Management attribute in v6.0 of the Mercury Product, but has been replaced functionally with the Role attribute in th HP-PPM v7.0 product.

A Program typically defines a large change managment initiative. It may include one or many related projects which have a common or dependent objectives. In HP-PPM, a program entity includes functionality not available at the project level and may be more appropriately managed and reported from the Product, PMO or Business Management level. Program functionality eanbles the consolidation of budgets from many projects for a forecasting or planning perspective. Programs had their own Status Reporting, Issue and Risk data elements in version 6.0. As there was no utilization of the Program Management functionality within HP-PPM, it's version 7.0 enhancments have not been tested or defined.

The Project is actually larger than a technical object as it acts as a "container" into which, and to which, other objects are attached and associated. It results in sets of records related to the project effort. The project, a menu selectable field in many porlets, reports and entry screens, lists all of the Active Projects in the system. The Project is selected for association when creating an Issue, Risk or Project Scope Change Request record. Projects can be automatically created when a Proposal is released for execution. This mode of creation transfers all of the Proposal attributes and objects to the new Project container, and then closes the Proposal. Projects can also be created manually (given the appropriate licenses) by entering a name, project start and end periods, and selecting a Project Type. In this case, all of the other assoicated objects are missing or are blank. The primary objects typically associated with a Project are:

• The Project Request is the collection of attributes which define the business case for the initiative. It is attached, and may be accessed from the Project Overview Page thorugh the "Project Details" tab. The Project Request is indexed by the Project No (ID), which is a 5 digit, sequentially issued control number not visible in the Project Overview Page. As most filters and searches allow for "includes" function on the Project Name, the Project Request Number is less important and significant. See Project Request for more details.
• The Staffing Profile is the labor estimate in hours by month by "Role" required to deliver the initiative. It can be entered in FTEs (Full Time Equivalents) or hours. Initially a strategic estimate, done as part of the business case, contains no individual names. The Resource Pool to supply the manpower is indicated for each Role in order to provide labor forecasts by portfolio. The Staffing Profile can be the driver of a Resource Management, Assignment and Allocation system between the Project and Resource Managers. See Staffing Profile for more details.
• The Budget is a separate system object which contains line item expenditures by month related to the delivery of the initiative. The labor cost associated with the Staffing Profile hours can be configured to roll into the Project budget based on rates established for various Roles, labor types and actual calendar work days in the initiative periods. See Budget for more details.
• The Work Plan is constructed inside of the Project Overview and is synonomous with a Project Schedule. It includes the Phases, Tasks, dependencies, resource assignments, labor estimates and planned dates for the execution of the project. As hours and progress is indicated through Time Sheet transactions, the planned vs. actual hours (and values as an option) are tracked at the task, summary task and phase levels. Milestones can be included and generate automatic notifications to stakeholders upon completion. For more details see the Work Plan section.

The Project Health is a calculated status value (red, yellow or green) based on the number of task exceptions, based on a set percentage, of all open tasks in the project schedule. See Exception Rules for more details. This value is reflected in the Project Overview and Weekly Status Report as the default value. If overridden in the Weekly Status Report, the value will then update the field value reflected in the Project Overview and PFM Project - Status section.

The Project Request contains the textual information that defines the project, it's Scope and it's Status. If the initiative is created via a Proposal, then the final step in the Proposal work flow creates the Project Request and transfers all of the business case information from the Porposal to the Project Request. A Staffing Profile (resource estimates) and Budget may be attached to the Project Request and are also available through a link on the Project Overview page. The Project Request includes a work flow which provides a level of status as well as communication functions. The Project Request, when created, generates a Project "Container", in which the Project Request, Staffing Profile and Budgets are placed, and to which other documents can be attached. The Project (Container) will also include the Project Work Plan (Schedule) and provide a Summary Portlet view including Status, Risks, Issues and Scope Change Requests.: The Project Request can be accessed on the Details tab of the Project Summary page.

The Project Management License provides access to view and edit Project Work Plans based on individual plan access settings. A Demand, Time and Resource Management license is automatically included with the Project Management configuration. Only a Project Manager can assign project team member resources to a Project Work Plan task. A Project Management License must be requested by a Resource Manager through submission of the Resource Profile Update Request

The Project Manager is assigned to a Project at the time it is approved for initiation. Often a Project Manager will be assigned at the PFM Proposal stage to co-ordinate and facilitate the definition of a change management initiative. The Project Manager typically oganizes the project team, builds and manages the project schedule, and is responsible for the successful delivery of the project based on the defined project scope and charter. The resources selectable in this drop selection field is limited to those managers who have been assigned a Project Management License.

The  Project Fields   tab is a Project Settings screen which controls what fields are enabled within HP-PPM and synchronized with Microsoft Project files, and where fields are displayed within HP-PPM. These configurable fields are primarily associated with planning, scheduling and task progress tracking functions [see individual field descriptions for more details]. If the enabled box is checked, the associated field will be displayed in the Project Task list and automatically synchronized with any associated Microsoft Project file upon synchronization. If the enabled box is not checked, then the field is disabled and not displayed in HP-PPM. If the Workbench Only box is checked the associated field is displayed in the Workbench and synchronized, but will not be displayed on the assigned resources Front Page view for update. If the Workbench Only box is unchecked, then the field will be displayed and available for update by the resources assigned to the task. The availability of these fields for configuration is contingent upon Project Synchronization mode selected as well as HP-PPM license and modules installed. Fields which may be configurable are:

Project Phase  is a menu drop down field on the Weekly Project Status Report that the Project Manager selects on a weekly basis. For projects in concurrent phases or mulitple iterations in different Enterprise Project Life Cycle phases, this is a subjective selelction. The phases:   Initiation, Discovery, Definition, Design, Development and Delivery. Project Phase is currently utilized in the Capitalization process and is critical to accurate financial reporting.

Project Status Reporting implemented in May 2006, provides a single point of access for the project manager to update the status of his project for all stakeholders. The Weekly Status Report Request type provides input for narrative status updates as well as health and phase indicators. In conjunction with the associated PFM project information, the Weekly Status Report is distributed to all Project Stakeholders automatically. A printed version of the Report, which combines the Status Report Input with milestone, risk and issue information from the project overview can be created and distributed to non HP-PPM engaged stakeholders.

The Project Type is a configuration file consisting of muliple records which control the optional behavior settings of the Project. The Project Type is seleceted at the time the Project is created, and cannot be changed after creation. The Project Settings button on the Project Summary page can be reviewed to determine the specific settings. There are currently two Project Types established

Project Types
• Standard IT Initiative which should be used for all projects. It's configuration allows the importation from MSP of an initial project schedule, but must be maintained for actual hours reporting and task\schedule changes inside of the HP-PPM system. MSP Synchronization is not enabled using this Project Type.
• MSP Controls Schedule - HP-PPM gathers Actuals is a carryover from version 6.0 when several Project Managers were utilizing MSP to control the schedule and HP-PPM to gather the actual hours from time sheets and synchronizing the schedules. While this was reasonable easy to do, there were minor defects in the synchronization related to remaining effort changes from time sheets. The primary differences between the two scheduling systems is that HP-PPM has no functionality related to effort driven scheduling. The primary reason is that HP-PPM is a Resource Centric, vs. a Schedule Centric system. The second problem with synchronization is that it transfers the scheduling information at the task, not the resource level, so Resource usage in the synchronized MSP schedule does not reflect the actaul hours reported by the individuals doing the work.

Project Type Settings - Category Summaries
• Project Fields can disable certain Planned and Actual attributes. All fields are enabled. These settings are the same in both Project Types.
• Work Plan defines the default Work Plan Template - is blank in both Types.
• Request Types Identifies specific Request Types to be utilized for Projects, Issues, Risks and Scope Change Requests. None have been developed or identified in either Type.
• Scheduling sets utilization of Actual Start Dates when available for scheduling; allows available days in schedule if only one of the task resources is available and enables Schedule Warning Rules.
• Schedule Health defines parameters for issuing task exceptions for unassigned effort, days late in starting, etc. The percentage of tasks with any enabled exceptions determines the project health indicators. The percentages are set here.
• Cost and Effort identifies that the Staffing Profile (vs the work plan) represents the work load against the resource pools. Settings here also define the level of actual hours tracking and disables automatic calculation of scheduled effort based on task duration (i.e. 2 days = 16 hours)
• Cost and Earned Value similar to Schedule Health, these setting determine CPI and SPI health indicator levels.
• Microsoft Project Integration identifies the mode, relationship and behavior between Microsoft and the HP-PPM work plan. This is the only tab settings tht differ between the two types. The MSP Controls Schedule... Project Type is so designated, while the Standard type indicate PPM controls all shared work plan information.
• Staffing Profile Assignments sets a Resource Pool as a default for all Resource Requests. Blank in both types due to constant reorganization.
• Project Health also similar to Schedule Health settings, these weighted scales reflect the relative value to be used between schedule, cost and issues in calcualting overal project health.
• Issue Health allows for weitghting factors to be considered in the Priority settings of Project Issues to determine a Project Issues Health indicator.
• Task Auditing enables individual field selection for inclusion in the work plan audit trail. The Audit Trail is accessible from the top left corner of the Project Summary Page. Currently selected for inclusion: Actual Effort, Actual Finish Date, Estimated Finish Date, Estimated Remaining Effort, Predecessors, Project Manager\Resource, Scheduled Effort, Scheduled Finish Date and Scheduled Start Date.
• Project Security which enables all User to View the Project (requires Project Management License) and enables the same group to view the associated Budget and Cost Information.




Program Management License

Application License Type

HP-PPM Support

3/19/08

The Program Management License enables the creation of Programs. A Program is a collection of Projects and Proposals which have a common customer, application or other inter-related or dependent characteristics. The Program function was reasonably weak other than multi-project budget consolidations and the abiltiy to create Program level Issues and Risks in version 6.0. The ability to create on-line Status Reports which consolidated textual content with associated project milestones was never utilized. The Program Management function has been enhanced in version 7.1, but to date no interest has been expressed in utilization. A Program Management License must be requested by a Resource Manager via submission of the Resource Profile Update Request.

Proposal

Request Type

PMO

11/28/07

The Proposal is a "Request" type object which should reflect all of the known information and considerations for a new product or changes to an existing product or process. It is associated with a corresponding workflow to facilitate processing and communications related to the strategic planning of Initiatives. The last step of the Proposal workflow generates the Project Container for execution and transfers all of it's attributes and values to the Project request. See the Integrated Process Model for additional information. Attributes listed may or may not be displayed in the indicated work flow step based on your licenses, security and access grants. Attributes associated with the Proposal include (see the links to it's element of this data dictionary for more details):

• Step 1 - Idea Detail Entry  Any Demand License holder can initiate a Proposal. The initial objective is to gather as much information as possible about the proposal, it's benefits, impacts and considerations for development. The fields typically populated in this step or the subsequent Sponsor Review step include:
  • Proposal No   System, sequentially assigned unique number when the proposal is initially submitted. A single sequence covers all Request Types
  • Status    Reflects the current state of the associated work flow and is automatially updated as each work flow step is exited.
  • Created By   Automatically populated field based on person making the initial Proposal entry.
  • Proposal Name   A short and concise label by which the initiative can be identified. The Proposal name is a requried field in this step.
  • Driving Process    The Request Type associated with the object. This is not a relevant field and will be hidden in the next Proposal upgrade cycle.
  • Program    This menu selectable attribute enables the association of the proposal to an existng Program for consolidated reporting and analysis.
  • Business Sponsor Organization    This required field identifies the Organization sponsoring the intiative. This attribute provides sorting and filtration for portlets and reports. The control and management of all of the Organizations rests with the PMO.
  • Primary Beneficiary Organization    This required field identifies the Organization which will benefit from the intiative. This attribute provides sorting and filtration for portlets and reports. The control and management of all of the Organizations rests with the PMO.
  • Primary Delivery Partner Organization    This required field identifies the Organization which will actually deliver the initiative and provides sorting and filtration for portlets and reports. The control and management of all of the Organizations rests with the PMO.
  • Purpose    This 1,800 character field defines the business purpose of the initiative and should include success measures and metrics surrounding the benefits to be derived. Additional information and supporting documents can be attached in the Reference section of the document.
  • Major Features\Benefits    This 1,800 character field defines the business benefits to be derived by the implementation of the initiative. Every effort should be made to identfiy measureable objectives that can be gathered during the deployment phase as validation that the desired results have been attained.
  • Assumptions    This 1,800 character field should identify any assumptions made or included in the prior two sections as well as any dependencies between this initiative's success and depndencies upon other initiatives or changes. These dependencies should include not only internal changes or assumptions but any external or market conditions built into the definition or success criteria.
  • In Scope    This 1,800 character field should define all of the specific technology components, processes or groups which will be impacted by the intiative. Every effort should be made to identify and engage all areas, applications, technology and customer groups that will have to participate in order to successfully deploy the initiative.
  • Out of Scope    This 1,800 character field should clearly identify any areas which have been considered as part of the initiative or it's implementation or deployment, and deemed as not impacted or required as an initiative dependency. This and the preceeding In Scope section are the only elements which can be utilized for scope management until a more detailed set of requirements are developed following project intitiation.
  • Data Impacts    This 1,800 character field should identifiy at a high level all existing and new data sources, interfaces, feeds and development required to successfully implement the initiative solution.
  • Business Owner Priority    Drop down selections are High, Normal and Low. This value is used for sorting and filtration in reports and portlets.
  • Application    Single entry drop down menu is to select the application which will be impacted by the initiative. This attribute will be upgraded to include multiple applications which will also send a notification to the application owner in the next Proposal upgrade cycle.
  • Desired Start Date   The date (month & year) that the Sponsor would like the initiative to begin
  • Desired Finish Date    The date (month & year) that the Sponsor would like the initiative to be finished.
  • Expected Start Period    The date (month & year) that the initiative is expected to be started, set at the time the initiative is approved. This date should be set based on both Sponsor and business prioritization as well as resource capability to deliver.
  • Expected Finish Period    The date (month & year) that the initiative is expected to be completed, set at the time the initiative is approved. This date should be set based on both Sponsor and business prioritization as well as resource capability to deliver.
  • Governing Body    This field identifies the required authorizing body for the initiative based on the scope, cost and complexity relative to current approval authorization level.
  • Project Type    This drop down selection indicates the configuration of the Project Work Plan when developed. It is required at the Create Project work flow step. This field does not carryover to the Project Request and should be removed from the Proposal in the next upgrade cycle.
  • Region    Only includes a default selection of Company and is has no behavior associated to functional requirements.
  • Proposal Dependencies    This single entry drop down enables the selection of another Proposal on which this Proposal depends. If both are included in a Scenario, and the sucessor proposal is selected for exclusion, a warning flag will identify it's link and requirement for this Proposal.
  • Primary Benefit    This drop down selection provides a general benefit category for filtering, prioritization and analysis. The options (for Primary and Secondary below) are:
  • Near Term Revenue (rolling 12 months)
  • Near Term Savings\Efficiencies
  • Longer Term Revenue (past 12 months)
  • Longer Term Savings\Efficiencies
  • Secondary Benefit    same options as above.
  • Business Owner    This single person selection menu makes all resources available for designation as the Business owner. The Business Owner should be able to speak to any issues or the current status of the Proposal and is typically the Proposal Sponsor.
  • Program Manager    This resource selection menu lists all resources which currently have a Program Management license issued to them. A program should only be selected by the associated Program Manager.
  • Project Manager    This multi-resource selection menu lists all resources which currently have a Project Management license issued to them. Only the resources selected in this field will have edit access to the Project Work Plan and Access configuration areas of the Project record. The assigned and authorized Project Manager (s) are reflected on the Project Request as well as on the Project Summary Page and in the Project Pariticipants configuration listing.
  • Product Manager    This resource selection menu lists all members of the Product Management Security Group. This is the initial security model implemented with the HP-PPM system and has proven to be unmanageable due to frequent re-organizations. Access to Project Information should be granted and configured by the Project Manager using the Configure Project Participants area off the Project Summary Page. Specific access and edit capabilities can be configured for any HP-PPM resource. Appropriate functional access and capabilites must already be available to the configured resource such as licenses and Security Groups.
  • Planning Group    This is part of the initial and default access and security model deployed with the HP-PPM v6.0 implementation. It requires the establishment and maintenance of security groups with member resources being assigned. Each Security Group is then associated with specific access and grants to data and functions in the work flow process. Due to frequent re-organizations and changes in Roles, this security model is not maintainable. We have adopted a more dynamic security model with version 7.0 based on identified stakeholders in each request with access and grants associated with the named resource in the designated stakeholder role in the document itself. This field is only viewable by system administrators as a debugging aid in access and edit trouble tickets. This field will be eliminated along with the security model concept with the next Proposal upgrade cycle.
• Step 2 Business Case Detail Entry (Opening Estimate)   Following the Sponsor's review of the Proposal as defined, the Proposal is forwarded to the Estimator (typically IT for development proposals) to provide a high level estimate for the "sizing" of the initiative. This additional information enables the sponsor to prioritize the intiative and determine additional information needs as well as authorization requirements. The fields typically added during this step are:
  • Opening Estimate    This drop down menu provides for the selection of a cost range to communcate a high level estimate for further prioritization and planning. The range options are:
  • $1K - $250K
  • $100K - $500K
  • $250K - $750K
  • $500K - $1,000K
  • $750K - $1,250K
  • > $1,000K
  • CapEx Eligibility    This radio button selection is not available until step 6 IT Finance Review and only indicates that the initiative, as currently defined, may be qualified for capital accounting consideration. This determination will be reviewed after initial high level requirements are gathered and presented at project initiation.

The Proposed Change is an 1,800 character field which should define the solution to the defined problem or issue. It should define the desired new behavior, adjustment or requirements to be implemented to address the issue or problem. In a more complicated change, this section and attribute would typically be defined by the person assigned to assess and estimate the implementation cost and effort. In a simple change, this might be completed by the initiator. The level of detail should be commensurate with the complexity of the solution to be executed and support adequate resource planning and direction. See Change Request for more details and context.

The References  section is included in all HP-PPM Request Types. This function provides the ability to link the record to other document locations (URLs) or vice versa, as well as attach related documents to the object type. Any references added are hyperlinked for quick and easy access.

The Requested By person can be anyone in the HP-PPM Directory. They will not necessarily have, and do not require, any HP-PPM access. This person should be the business owner or beneficiary requesting the change. This person is considered the Sponsor of the Request and should be able to articulate the value and need for the requested item. If the Change Request is worked and implemented, the Requested By Sponsor must have the authority to authorize the utilization of the resources based on the estimated time and cost of the work. This field is required in the Defining step and not editable after the completion of the Definition. See Change Request for more details and context.

The Request Name is a concise title (40 character limit) by which the Request will become known, and is utilized in the Proposal, Project and Change Request objects. In the case of Change Requests, this field is required upon Entry and can only be changed by the Document Contact during the initial Definition step. See Change Request for more details and context.

The Request No is a 5 digit control number that is sequentially issued across all Request Types and is utilized as a link to the Request in portlet representations.

The Request Status represents the step of the business process and is determined based on the current work flow step of the Request Type. As the Work Flow steps are executed, the document is delivered to the appropriate next step and Stakeholders may be notified via email. The Request Status should reflect the activity to be executed during the step, and may not reflect the current state or condition of the underlying information, depending on activity taken or still pending in the current work flow step. Work Flow steps and status are uniquely utilized in Proposals, Projects, Change Requests and all other Request Types. See Change Request for more details and context.

A Request Type is a basic system object (data container) which includes attributes common to it's definiton, understanding, processing and management. Each Request Type is unique, includes a defined set of data elements (attributes), and a Work Flow. The Work Flow facilitates enterprise communications, internal controls and operational management of the Information based on the objective of the Request Type

Current Request Types:
• HP-PPM Proposal  is utilized to define, assess, estimate, prioritize and authorize new development initiatives.
• HP-PPM Project  is utilized to manage and integrate the authorizing information, the resource & project planning information and the execution information related to initiatives.
• HP-PPM Change Request is utilized to define, assess and manage information and work associated with a defined work effort that is smaller than a project level initiative.
• Resource Profile Update  to automate updates for organizational and resource management attribute changes to the employee and contractors profile in HP-PPM.
• Issue  to define, communicate and facilitate resolution of roadblocks to success..
• Risk  to define, communicate and facilitate the appropriate response and mitigation of risks to initiative success.
• Project & Program Status Report  is a request type that provides for the integration of subjective, narrative attributes concerning the status of an initiative, and the associated Project or Program work plan information. This Status Report was delivered in version 6.0 but not migrated as it was not being utilized.

Planned Request Types:
• Work Order   to define, assign and facilitate the management of work elements that are less than project level complexity and my be related to maintenance or "Keep the lights on" efforts.
• Product Enhancement   to define and facilitate the managment of ideas related to future product changes. These ideas might later become or be included in a Proposal, or converted to a Work Request to be executed depending on complexity, urgency, cost or other considerations.
• Scope Change   to define, communicate and facilitate the management of changes to an active project's Scope based on the discovery of scope elements, requirements, costs, delays or other changes requiring approval or communication to project stakeholders..

A Resource in HP-PPM is a person. All access to the HP-Project & Portfolio Management application suite is managed based on license keys and access grants assigned to the Resource, so all resources must be defined and profiled prior to any access or utilization in project schedules other than, assignment to tasks. Resources are added to the system automatically from the nightly LDAP\Active Directory feed which will be sourced from the Employee Master in 2008. Only the Resource's Direct Manager has edit access to the Resource Profile, and many fields are only accessible via HP-PPM Support. Resource names in Microsoft Project which do not match the HP-PPM resource names automatically can be mapped on importation.

Included in Resource attributes:
• Calendar for availability planning (Vacation, Training) and affects project scheduling by resource
• Capacity for representing work availability
• Category indicates the type of resource as either Full-time Employee or Contractor. This field will be updated automatically via the LDAP\Active Directory feed, ulitmately from the Employee Master in mid 2008.
• Department will be updated from the LDAP\Active Directory feed from the Employee Master in mid 2008. This attribute is not associated with any behavior or functionality outside of reporting.
• Direct Manager provides filtering capability in Workload Analysis Report and is the only person outside of HP-PPM Support that has edit access to some of the Resource attributes, other than the resource themselves.
• Email address for notifications if automatically populated from the LDAP\Active Directory feed.
• Location Not currently utilized
• Organization is set from the Organizational perspective but reflected here. This is the operating group to which the resource is assigned and is important for filtering and portlet reporting of actual time information captured through the time sheet entry process.
• Region This attribute is not associated with any behavior or functionality outside of reporting. (Calendar may be associated with Regions for Holidays?)
• Resource Pool is the Resource Management Group to which the ROLE and the Resource belong. This association allows the Resource Manager to view all capacity and requirements for the designated ROLE from all Proposals and Projects. Unless a Resource is assigned to a Resource Pool, they can not be assigned to a Project Work Plan task.
• Role is the key Demand Management Role and should be considered as an "Area of Expertise". Role is typically the level of title or job description, and is used for Strategic Planning. Differentiations betweens Roles that are too small to be planned at the Strategic Level (Annual, Product, Program) are more appropriately defined and utilized as Skille for Tactical Planning and Management. Each resource can be assigned only one Role.
• Skill is a specific expertise or experience which can be related to satisfying a development or process requirement. This attribute provides an additional level of detail to the ROLE attribute which is set and maintained for Strategic Purposes. The Skill set could indicate specific skills related to applications, tools or environments not appropriate for strategic planning but critical for tactical planning and resource management. EAch resource can be assigned multiple skills.

The Resource Management License actually refers to inclusion in the Resource Management Security Group. This Group, in combination with the Demand Managment License which is automatically included, provides the abiltiy to run Time Sheet Reports and utilize portlets related to Time Sheets, Resources and Resource Pools. This license provides the Direct Manager the ability to update his direct reports Resource Profiles and assign a Time Sheet Delegate to enter time sheets in the resources absence. This group also has access and update capabilities related to work allocation from Resource Pools into Project Teams. A Resource Management License must be requested by a Resource Manager through submission of the Resource Profile Update Request

The Resource Profile Update request is designed to effectively gather resource profile update information from the initial issuance of a license for the HP-PPM System access through subsequent changes in critical information. While every effort is being made to populate data fields automatically from other data sources, many of the data elements with Change Mangement operational impacts are not contained in other systems. To submit a Resource Profile Update request, you must have a Resource or Project Management License. Under the Demand Management menu in HP-PPM, select Create A Request; then select Resource Profile Update. The form can be submitted for mulitple resources as long as the indicated changes apply to all of the resources included. Once the request is processed, all stakeholders will receive an automatic Notification that the setup has been completed. Please contact a Project Manager in your Portfolio or operational group if you need assistance.

       There is a simple 3 step work flow process associated with this maintenance request. A person in the Resource Management Security Group (all Resource and Project Managers) can enter the Update Request. They select the resource or resources to which the update applies (all new values must be the same for all resources included). The form is submitted and placed in a Pending Status. It will be automatically delivered to the HP-PPM Support Team. This eliminates the need for a magic ticket and ulitmately the need for any human intervention. The HP-PPM Support Team updates the resource profiles. Initially an email acknowledgement will be sent to the requestor and all affected resources. Ultimately this acknowledgement will be automatic and will include the losing and acquiring Organizational, Direct and Resource Managers for each resource changed. Attributes required for initial setup and eligible for subsequent change transations are:

• Direct Manager is the person responsible for Time Sheet Entry Compliance and Profile Accuracy.
• Resources for Update is a multi-select menu which displays all current employees and contractors in the HP-PPM Directory.
• Organizational Unit Assigned represents the group of people that have a common manager who is responsible for time sheet reporting and assignment to project teams (not necessarily Project Work Plan Tasks).
• Role to be Assigned is a critical field that is unique to strategic and tactical planning. It is the basis for estimations of future effort as well as the cost in terms of labor hours and dollars for initiatives in the planning processes.
• Resource Pool Assigned is the collection of Roles and Resources to which this person belongs. The Resource Pool is the primary resource capacity management view of the enterprise across all initiatives. It is a Strategic and Tactical Planning component and is linked too, but different than, the Organizational structure.
• Time Managment License? is required to enter actual hours worked on the weekly time sheet against open project work plan tasks.
• Demand Managment License? is required to access Proposals, Projects, Change Requests and any other Request Types for review or update.
• Resource Managment License? is required to run Time Sheet Reports, assign resources to Project Teams from Resource Pools.
• Project Managment License? is required to access or edit Project Work Plans.
• Program Managment License? is required to create, access or edit Programs.
• Portfolio Managment License? is required to access, create and modify Scenario views.

This Notification is then sent to the New Direct Manager and all affected Resources selected

A Resource Pool Is a collection of Roles which reflect both the capacity available, and work assigned or allocated, to the Resource Pool from any source. Resource Pools are utilized for both strategic capacity planning as well as organization resource management. Roles are associated with each Resource Pool, as are specific real and planned resources (people). As work is defined in Proposals and Projects, those assignments, identified as requiring a specific Role, are automatically forwarded to the Resource Manager of the appropriate Resource Pool. From the Resource Pool an individual Resource can be Soft-booked or Committed to fulfill the request.

     Resources and roles are planned and viewed in FTEs (full time equivalents) or hours, and each Resource Pool is a continuum to enable active tactical, as well as strategic planning, while considering the complete picture looking forward. Load and capacity can be displayed in weeks, months or quarters. Load is represented by Proposal and Project Staffing Profiles.

     Resource Pools are related to the three Organizational Unit types; Department, Group and Team. The Department corresponds to the budgeted departments. The Team corresponds to the group of individual people managed by a common manager, which may or may not contain multile roles and\or skill sets. Each assignable resource must belong to, and can only belong to one Team. The Group represents any intermediate level or collection of Teams which need to be managed, analized, reported or planned as a group. The Organizational hierarchy is reflected in a Resource Pool hierarchy based on Departments and Groups. Group and Department level organizations each have a corresponding resource pool which rolls up and reflects all Teams associated as child resource pools. Department and Group Resource Pools can have no assignable resources. A Team level resource pool can be a child with many parents. Attributes of the Resource Pool are:

RESOURCE POOL HEADER  (Change button from Resource Pool)
• Name will typically be the name of the Organizational Unit responsible for the strategic planning of work effort or assignment of work to individuals for completion (primary - TEAMs only). For non-primary Resource Pools established for analysis purposes and associated with programs, proposals, time frames or other needs, the name should indicate the purpose or objective. (NOTE: All proposal staffing profiles must include only Primary Resource Pools prior to capacity analysis associated with Release Planning, in order to be valid).
• Description is only necessary for Group type resource pools, and should clearly define the purpose, ownership and duration of the pool.
• Pool Manager is the person to whom resource requests are sent. The manager of the Team resource pool, as well as the manager of any parent resource pools, are the only ones who can allocate resources to resource requests (projects and work requests).
• Primary Organization Unit If this is a Resource Pool which will contain assignable resources, then the Organizational unit must be a Team (splitting departments or existing teams). If a Group or Department is selected, as they should have no assignable resources, the results and impacts are questionable. If the purpose is to roll up existing Primary Resource Pools, then it should be designated as Freestanding.
• Region IT Projects should utilize the Corporate default region.
• Parent Resource Pool If this Resource Pool will roll up into a Department or Group Resource Pool, select it from the drop down menu.

MANAGE POOL CAPACITY Section  (left button on Resource Pool)
• Named and Unnamed Resource List From the Manage Pool Capacity button the list of assigned resources can be viewed. Both named and unnamed resources can be added. A resource can only be in one primary resource pool at a time, so in order to add an existing resource to a resource pool, they need to be transferred based on an effective date.
• Role Each resource must be associated with a Role in order to be matched to Demand requirements against the resource pool. The Resource Role is established in the Resource's Profile. Each role will be associated with a rate which is used to estimate the cost and value the effort expended on the project work effort.
• Resource Capacity is reflected in Full Time Equivalents (FTEs) or hours by period for each resource listed. Hours are then allocated from this capacity to work efforts as requested. FTEs are converted to hours based on the Enterprise calendar which eliminates holidays. Individual calendars indicating planned vacation days will also be reflected in the resource capacity.

The Risk attribute in the Change Request is an 1,800 character field utilized to define any risks associated with either not addressing the problem; addressing the problem in general; or specifically related to the proposed solution. If additional information is available or required, documents can be attached in the reference section and identified here. See Risk Management Process in the Change Management Glossary for more details.

A Risk is a defined event which might occur which will have a significant impact on the project deliverable. The event is evaluated based on its probability of occurring and the magnitude of the impact should the event occur. All information concerning a Risk event, it's definition, evaluation and mitigation must be included in the Risk record or it's attached or linked documents. See Risk Management in the Navigator Glossary for additional information. Attributes associated with a Risk record inclulde:

• RIsk ID   Risks are a special "Request Type" object in the HP-PPM system. All Request types are created with a system assigned, sequential, unique identification number which enables relationship links between various system objects. A "Risk" might be linked to a project task for mitigation, or be transitioned into a "Change Request" for contingency planning purposes.
• Name   Short, descriptive name for identification. Limited to 40 characters.
• Detailed Description   A complete description of the risk, it's triggers and indicators. A risk can be either a postive or negative event based on impact to the project.
• Business Impact   A detail description and quantification of the impact of the risk event on the project deliverables, schedules, cost or other attributes affected.
• Probability   Menu selectable indicator set as Low, Medium or High to reflect the probablity that the defined risk will be realized.
• Impact Assessment  Menu selectable indicator set as Low, Medium or High to reflect the potentail impact on the project, objectives and business if the defined risk is realized.
• Risk Response   An assessment of the risk requires a management decsion as to the appropriate actions to be taken. The Risk Response Indicators in the Risk Record indicates which action (s) are to be completed relative to the specific risk. Each of the potential responses should be considered and responses indicated for: Risk Assumption, Transferrence, Mitigation, Contingency Planning and Avoidance. These responses are not mutually exclusive.
• Mitigation Plan   Specific actions to be taken, identified by owner and time frame, to mitigate the risk. Risk mitigation can be directed to reduce the probability that the risk will be realized, or reduce the impact of the risk should it be realized. In either case, Risk Mitigation is an actionable event.
• Contingency Plan  Specific plan of actions to be taken, by whom, should the event triggers fire.
• Status   current state of the Risk event in the Risk life cycle and management process. See the Navigator Glossary for work flow details.
• Priority   menu selection indicates the relative importance of addressing the Risk. The priority is a funciton of the likelihood of the event occurring and the expected impact should the risk occur as well as other subjective evaluations.
• Assigned   drop down menu to select assignee. This person will receive an automatic notification of their assignment. They are responsible for taking the next action in the risk management process. That step should be clearly determinable based on the risk status and the content of the risk record. Risks should be reviewed within 24 hours to acknowledge receipt and insure proper assignment.
• Notes  Any team member can add notes, comments or considerations to this field. The author's name and time are automatically recorded. Each Assignee must contribute to the Risk record. If it is assigned in error, and is reassigned, the reason and logic should be recorded in the Notes field. Any questions or queries should be focused on the Risk record. Email conversations outside of the Risk record are inefficient and result in an incomplete history of the Risk management and should be avoided.
• References   Documents can be attached or linked, and URLs can be associated with the Risk. In all cases, if a specific task is associated with the Risk it should be linked in the reference field for quick access. If the Risk can be linked from the Task Reference field, it should be, as well.

The Role is the primary Resource Management and planning attribute that drives much of the HP-PPM functionality. It is the basis for future work estimation (hours by Role) as well the financial forecasting functions (Role Rates [fully loaded labor rates] are applied to estimated hours) . This future "load" of work by Role provides a method for Customer commitments based on capability and capacity, as well as a forecast of hiring requirements by skill sets. Staffing Profiles are an estimate of the roles required to deliver a defined change. The role is stated in terms of either FTEs (full time equivalent) or work hours by month. Each resource (person) has one role associated with them in their profile. This enables the staffing profile to function as a link between planned work during the early strategic planning process and specific resouces during project planning and execution. Roles are collected in Resource Pools, which are a combination of Resources with different roles that report to a common Resource Manager. The Resource Pool reflects the available work load capacity for each group of resources. The Role can be further elaborated or specified based on an associated Skill identified in either the Resource Profile or Staffing Profile requirement. Roles are currently being evaluated to provide better strategic planning facilitation at the Enterprise level.

Scenario

Virtual Financial & Load Analysis Tool

HP-PPM Support

3/19/08

A Scenario is a collection of Proposals and Projects for the purpose of consolidating and analizng the financial and resource load impact of the consolidated Budget and Staffing Profile. By combining all of the current Projects with the approved Proposals you can create a forecast (or annual plan) by month based on the monthly budgets for all future periods. This combined total can then be compared, and variances reported against, a virtual budget (rolling forecast or annual plan). These same combined Staffing Profiles can be offset against a virtual Resource Pool to provide a capacity management view of resource needs, or a Release Management view to determine the ability to release additional work based on availability by Role. The value of this capability is directly proportional to the accuracy of your estimates. The value of your estimates can not be determined unless compared to your actual experience. This actual to estimate variance analysis is the critical, enabling component of a continuous improvement process and mind set. What gets measured, gets done, and can be improved!

Scheduled Duration   reflects the elapsed calendar days between the start Date\time and Finish Date\time of the task. All tasks are duration driven in HP-PPM, so that given a duration, the Finish Date is calculated based on project and resource calendars, or given a Finish Date, the Duration is calculated. There is no impact on the schedule of the work content of the tasks or the number of resources assigned.

Scheduled Effort attribute reflects the work hours required to complete the task. HP-PPM Project Schedules are Duration driven, so changes to Scheduled Effort do not result in any changes to schedule dates, but are reflected in resource management and load reports. Based on the functionality of the attribute, the sequence for task creation is: Add task to schedule; enter duration of task, assign resources, adjust Scheduled Effort by Resource. Functionality of the Scheduled Effort attribute includes:

• Tasks with no resources assigned default Scheduled Effort based on Duration days x 8 hours per day (default calendar setting).
• An increase in Duration will cause a proportionate (ratio of new duration to old duration) increase in Scheduled Effort for all resources assigned to the task. (i.e. increase from 2 to 2.5 days, Scheduled Effort goes from 10 to 12.5 days).
• If you add additional resources to a task, the new resource is assigned Scheduled Effort equal to the highest content assigned to any other resource on the task.
• Due to the large variance in Project Management experience and the large number of concurrent projects, this function has been reset in the Project Type settings to default to "no automatic calculation of effort" on task creation. Be sure to add your estimated hours after establishing the task duration, and then spreading those hours over the task assigned resources.

Scheduled Finish Date   This field reflects the date the task is planned to complete. It is actively caculated based on task dependencies and predecessors and task duration. This date may change if the project is rescheduled based on task or predecessor actual updates to durations and\or work hours.
NOTE: There is no automatic reschedule in HP-PPM. Rescheduling must be manually triggered using the Reschedule icon.

Scheduled Start Date   This field reflects the date the task is planned to start. It may be actively caculated based on task dependencies and predecessors. Depending on how the task and/or project is configured and being managed, this date may change if the project is rescheduled based on predecessor actual task updates.
NOTE: There is no automatic reschedule in HP-PPM. Rescheduling must be manually triggered using the Reschedule icon.

A Scope Change Request is a HP-PPM system "Request" type object which reflects all of the considerations for changing the scope of an approved, in-process project. It is associated with a corresponding Workflow to facilitate processing and communications. See the Scope Management Process diagram and Navigator Glossary for additional information. NOTE: System and Application functional changes unrelated to a specific, approved project's scope should be entered as "Proposals" or "Enhancements" and not Change Requests. Attributes assoicated with a Change Request include:

• Change Request ID   Change Requests are a special "Request Type" object in the HP-PPM system. All Request types are created with a system assigned, sequential, unique identification number which enables relationship links between various system objects. A "Change Request" might be linked to a Project Task or tasks for implementation, or be transitioned into a "Proposal" request type for prioritization and consideration for inclusion in subsequent project releases.
• Change Request Name   A short description for identification; limited to 40 characters.
• Detailed Description   A complete description of the problem or opportunity and it's ramifications. This section must contain the impact on the project and the business if the Requested Change is not approved and implemented.
• Proposed Solution   This field should contain as many alternative solutions as possible. Estimates should be defined for the implementation of each solution. Once a solution is selected, the tasks to be added or impacted should be defined with work content, duration and resource assignments prior to approval.
• Business Function   We should change this field name to Business Impact and include the impact of not resolving the problem. It should be repositioned to follow the Description and preceed the solution.
• Status   Status reflects the following steps, accomplished in sequence to elaborate the problem or opportunity, it's impact, solution and implementation considerations as follows: New, Defining, Solutioning, Evaluating, Implementing, Closed or Cancelled.
• Priority   indicates the importance and need for Change Request consideration and may be Undetermined, Low, Medium, High or Critical.
• Assigned   is a drop down menu to select the assignee. This person will receive an automatic notification of their assignment. They are responsible for the completion of their contribution to the Definition of the problem, solution or implementation impact. Change Requests should be addressed by assignee within 24 hours to acknowledge receipt and insure proper assignment. If you are assigned a Change Request and it is not clear from the notes or existing information in the record as to why you were assigned, contact the Project Manager immediately.
• Notes  Any team member can add notes, comments or considerations to this field. The author's name and time are automatically recorded. Each Assignee must contribute to the Change. If it is assigned in error, and is reassigned, the reason and logic should be recorded in the Notes field. Any questions or queries should be focused on the Change Request record. Email conversations outside of the Change Request record are inefficient and result in an incomplete history of the considerations and decsions and should be discouraged.
• References   Documents can be attached or linked, and URLs can be associated with the Change Request. In all cases, tasks added or changed in a project schedule based on the approval of the Change Request should reference and link to the Change Request record.

The Secutiry Group is a configuration tool to which a resource is assigned. Each Security Group contains a set of Access Grants. Each Access Grant provides all the members of the Security Group with a specific capability to create, view, edit and\or delete a specific Request Type. Specific functions or attribute access may be further controlled at the Request Type or the associated Work Flow step level within the Request Type. Only a System Administrator can assign a resource to a Security Group

Examples of Security Groups
• Project Team Member
• Project Manager
• Resource Manager
• Program Manager
• Portfolio Manager
• Finance Manager

The skill attribute is a menu driven table which reflects the name of a specific skill or area of expertise. It can be associated with a resource or a task to facilitate the matching of resoruces to project task needs. The skill attribute is a critical sub-filter attribute for resource load analysis reporting. There is also a proficiency level (1-5) which is associated with each skill. This seems to be causing some confusion as no standard or definition has been established or communicated for it's utilization. The Skill attribute was utilized in the v6.0 product as Role is utlized in the current version. While the skill attribute was carried over into the new version, it appears to have no functional behavior.

The Solution attribute of a Change Request or Issue should contain as many alternative solutions as feasible. Estimates should be defined for the implementation of each solution. Once a solution is selected, the project and tasks to be added or updated should be defined with work content, duration and resource assignments prior to approval.

The Sponsor Priority is a menu selectable list which includes values of: Low, Medium, High, Critical and On-Hold. This attribute is editable on the Entry of a Change Request and during the Definition & Prioritization steps of the work flow. The value selected should represent the priority of the Change Request based on the current information, state and other priorities of the intiating Sponsor. The Sponsor of the Change Request is the person reflected in the Requested By attribute. See Change Request for more details and context.

A Staffing Profile is a system object which contains a list of Roles and resources allocated to a defined work effort. It can be attached to either a Proposal or Project. If a Project is created from an approved Proposal, the Staffing Profile will be copied from the Proposal (with a new name) and attached to the spawned Project. It reflects initiative demand for resources in either FTEs (full time equivalents) or hours, by month, for the duration of the initiative. The Staffing Profile is created as part of the initial Proposal definition in order to provide resource cost and planning for strategic and tactical planning. The details are elaborated through the Release process as the definition of the work is further defined. The final approved Staffing Profile is utilzed to establish the initial Project Team and established the baseline for comparison and analysis through Project planning and execution. The ROLES defined can be utilized to drive resource requests to Resource Pools based on configuration and assignment by the Portfolio Planners. The Staffing Profile is considered the IT resource demand for a project and EAC (estimate at completion) forecasting utilizes the Staffing Profile data vs the project work plan (schedule) based on current configuration. Attributes associated with a Staffing Profile include:

     Available through the Change Header button by the manager
• Name The Name should be the same as the associated Proposal or Project.
• Description The Description should define the type of work effort being defined (i.e. Pilot, Feasability, Development, etc.
• Manager Mulitple Managers can be assigned. Managers automatically have edit and updated rights to the staffing profile, contingent upon proposal or project work flow configurations. Access can be granted separately to individuals through the Configure Access button (only available to the defined Managers - see below).Typically the creator of the Staffing Profile for a Proposal is a Portfolio Planner or Business Owner, and for a project the manager would be the Project Manager.
• Start Period Month and Year inherited from the assoicated proposal or project.
• End Period Month and Year defaults to the end period of the proposal or project but can be reset independently
• Status drop down menu with values of In Planning, Active, Complete and , Cancelled
• Region Not Currently utilzed and defaulted to "Company"
• Workload Category Function and controls TBD. Current selectable attribute elements are: Strategic Projects, Legacy Systems, Operatonal Support or Maintenance. This value is redundant based on new proposal and project attributes and should be hidden.
• Work Load radio button should be set to Yes for all Staffing Profiles. This enables the load to be reflected in the identified resource pools. Only Freestanding Staffing Profiles for planning should be considered as none work load.
• Assocoated Request Type This drop down menu includes Freestanding, Proposal or Asset. If Proposal is selected then another drop down menu is added to Select the associated Proposal or Project NOTE: A defect will default this Staffing Profile to Freestanding even though you initiate it from within a Proposal or a Project. It must be set HERE to become attached..
• Default Resource Pool Given our Portfolio organizational structure, this value should not be utilized. A Resource Pool should be selected for every Role added to the Staffing Proifle.
• Synchronized with Budget radio button This is a critical link between the Staffing Profile and the associated initiatives budget. The Budget must already exist, and not have any Staffing Profile associated with it. Only one Staffing Profile can be rolled into a Budget. Once the Budget has been created, return to the header and complete this area by setting the radio button to yes and then selecting the associated Budget.
• Budget Name This search menu will display all Budgets that do not have a Staffing Profile associated with them for selection. The extended value of the hours, by role, from this Staffing Profile will automatically be rolled into the associated Budget
.

     Available through the Configure Access button by the manager:
• Managers selected above will be listed with default Access for Edit Header, Edit Position, Edit Assignment Actuals and Edit Security (this access)
• Add User The Staffing Profile manager can grant access to other users for the purposes of editing the Staffing Profile. For

     Staffing Profile Body:
• Proposal\Project Name with an active link to the associated proposal or project.
• Created On date of creation
• Created by Staffing Profile initiator
• Description Define the purpose of the Staffing Profile
• Initiating Document This hyperlink identifies the associated Request (PFM Proposal), Program, Project or Organization in which this Staffing Profile was created.
• Profile Property - Type Organization Unit, Proposal, Program, Project, Project Plan or Asset. It appears that if none is selected, the type is set as Freestanding.
• Specific Initiative is selected from a query based on the Type property above.
• Actual values are selected as Entered Manually or Automatically Rolled Up from project plan
• Resource Pool default value to be associated with new lines entered can be set from drop down menu
• Capacity Visualizations A checkbox to include the workload in capacity visualizations. The control of this setting will be defined here to insure appropriate inclusion and exclusion for enterprise Resource Planning purposes.
• Staffing Profile Lines are added to include Skills, Resources, Resource Pools and line item comments.
• Notes can be included in the Staffing Profile.

The Stakeholder section of the Change Request includes the named Stakeholders of the effort. Each is defined as one of the specific Roles associated with the processing, authorization, control or execution of the Change Request work flow. All edit access to the Change Request attributes are controlled and managed by the document Stakeholders, based on the assignment to the various Stakeholder Roles. This enables security and access control via each document's participants with no backend security management. This concept will be utilized in future releases of the Proposal, Project and all new Request Types in the future. Please see Change Request for more details and context.

The  Object State reflects the current status of the object based on it's life cycle or phase, as follows:

• In Planning   indicates that the project has not been activated. It will not be displayed in dashboards or portlets, no exceptions can be logged, no notifications triggered and will not be available for time entry against tasks.
• Active   indicates that the project is actively being worked. Exceptions and Notifications are active and project structure can be changed. this is the only state in which the project tasks are visible through the time sheet entry process.
• Completed   indicates that the project is finished. The project is displayed on dashboards but not in My Tasks portlet. Exceptions are not logged and Notificaitons cannot be triggered.
• On Hold   indicates that the project is not active at the current time. The project can be displayed in dashboards and portlets but cannot be edited. Exceptions cannot be logged and notifications cannot be triggered.
• Cancelled   indicates that the project has been stopped. The proejct is displayed on dashboards but not in My Tasks portlet. Exceptions are not logged and Notifications cannot be triggered.

• New   tasks will not be displayed in dashboards or portlets, no exceptions can be logged and no notifications triggered.
• Ready  indicates that the task has no pending predecessors and is available to be worked.
• In Progress  indicates that the task is actively being worked. Exceptions and Notifications are active. This and Completed are the only States available to the resources assigned to the task. This state is automatically updated based on Actual effort being charged by an assigned task resource.
• Active   indicates that a summary task contains tasks that are being worked. This state does not apply to an assignable work level task.
• Completed   indicates that the task is finished. This and the "In Progress" states are the only two available to the Task Assignee for update. If the % complete is set to 100 or the Actual Finish Date is entered, the Task State will change to Completed. If the Task State is set to Completed, the % Complete is automatically set to 100 and the Actual Finish Date is set to the current date if blank. A task is not set to Completed until all resources assigned have been updated to 100% complete.
• Pending Predecessor  indicates that the task is waiting for the completion of a task which must be finished prior to work commencing. This is a soft dependency in that Actual Start Date, % Complete and State change to Completed are allowed from a Pending state.
• Pending Request   indicates that the task is waiting for the completion of a Request (Issue or Scope Change) which must be finished prior to work commencing. This is a soft dependency in that Actual Start Date, % Complete and State change to Completed are allowed from a Pending state.
• Cancelled   indicates that the task has been deemed not necessary. The task is displayed on dashboards but not in My Tasks portlet. Exceptions are not logged (or are cancelled at time state is changed) and Notificatons cannot be triggered once this state is set. % Complete Calculations for higher level summary tasks are not affected by this task effort.
• Bypassed   indicates that the task has been left uncompleted. The task is displayed on dashboards but not in My Tasks portlet. Exceptions are not logged (or are cancelled at time state is changed) and Notificatons cannot be triggered once this state is set. % Complete Calculations for higher level summary tasks are not affected by this task effort.

The Status attribute for most system objects have some functional or security characteristic. Request Type Status is set based on the associated Request type workflow. The Status of other objects may be set automatically based on some triggering event, or manaully based on a business process control. . Each step in a workflow contains an associated step status name, which is reflected as the Request status while the workflow is in that step. The work flow status reflects the current status of the workflow process, and not necessarily the status of the document. See the associated Data Dictionary entry for each of the current objects for specific details:

System objects with a Status
• Proposal Request Type
• Project Request Type
• Change Request, Request Type
• Budget
• Staffing Profile
• Work Plan Task

The Project Status Distribution List  is a menu driven, multi-resource selection field which identifies the Project Stakeholders with access, to whom Status Reports are distributed. This field is accessed and maintained on the Project record and is accessed each week by the distribute workflow step in the Weekly Status Report workflow. Notifications of the Status Report entry are emailed to each stakeholder included in this list.

Summary Status  is a drop down menu on the Weekly Project Status Report and the PFM Project record that is set by the Project Manager on a weekly basis to reflect the overall status of the project. The options are: On Target; Risk of Delay; Risk of Objective; Delayed; Delivery Issue; Complete; On Hold. If updated in the Weekly Staus Report, the value will also update the PFM Project record. The PFM Project Record can also be updated independently.

This report runs with each import or synchronization between a HP-PPM and Microsoft project file. It reflects any errors encountered with synchronizing the data elements. Not all fields are synchronized, regardless of the synchronization method selected. Notes and Text fields are not transferred in either direction. The resource section displays as part of the synchronization process. The last synchronization Report is accessible from the Project Workbench home page. Fields synchronized [actual values in the order listed] are as follows:

• % Complete
• Actual Start
• Actual Finish
• Actual Duration
• Actual Effort
• Estimated Finish
• Remaining Duration
• Remaining Effort
• Assigned Resources - Resources assigned to tasks in HP-PPM will be automatically added in Mircrosoft Project file. Resources added in Microsoft that do not match existing HP-PPM resources will not be added, and will be flagged on the Synchronization Report, in the Unsuccessful Resource Matches section. These resource names can then be mapped to a corresponding name in the HP-PPM Directory.

The Target Production Deployment Date represents the planned release date of a code or operational change to the production environment. This date is utilized for release planning to determine appropriate packaging and migration activities. This date can only be set in the Scheduling work flow step by the Built By stakeholder. If this date is missed, the CR must be returned to the Prioritizing Step and then rescheduled in order to update the new Target Production Deployment Date. The initial date will be cleared upon re-entry to the Scheduling step. WARNING - The CR should not be released from scheduling until the resources are available to start work. See Change Request for more details and context.

A Task represents the smallest unit of assignable responsibility of a project workplan. There are several types of tasks utilized in project management, but any line item of a project schedule is commonly referred to as a task. Technically, a task represents a unit of work, and is scheduled to begin and end, has a duration and work content, and is assignable to a specific person or group. Other task types include milestones, deliverables and summary tasks. A task can be defined as being dependent upon another task within the project, a task in another project work plan, or a "Request Type", currently including "Issues", "Risk" and "Change Requests" anywhere within the Enterprise. Inter-relationships between tasks (dependencies), combined with work content, duration and resource availabiliy to perform the task, is what determines a project's workplan (schedule) for product delivery. Task information is the basic unit of information from which project schedules are built and progress is tracked and reported.

Task Starting Late is one of seven Exception Rules which can be enabled to generate a flag at the task level reflecting a project issue which requires attention. These Rules are enabled in the Project | Settings | Exception Rules tab. If the current date is x days beyond the task Scheduled Start date and the task's Status is not "In Progress", then the exception flag is set for the task the next time the project file is SAVED. Exception flags may be utilized to gauge a summary task, phase or project's "health".

The  Task State  reflects the current availability of the task for execution and includes the following:

• Ready indicates that the task is available for working.
• Active indicates that the summary task has an active task.
• In Progress indicates that work has started and Actual Hours have been entered.
• Completed indicates that the task has been finished.
• Pending Predecessor indicates that a predecessor task or request has not been completed. This state may be associated with exceptions and notifications such that if the predecessor task is not finished within "x" days (configurable) of this tasks Scheduled Starting Date, an exception and\or notification may be generated.
• On Hold indicates that the task has been removed from the authorized work list and should not be worked. The task will not appear in the My Tasks portlet or Time Sheets for update by the project team members.
• Cancelled   indicates that the task has been removed from the authorized work list and cannot be updated by the project SME.
• Bypassed indicates that the task has not been complete, but should no longer be considered as work which must be done. If a task is bypassed, it remains in the schedule but is not considered work remaining for higher level summary task % complete calculations or exception rule processing.

The Time Management License is the only license required in order to enter weekly time sheets. No Request type access is inlcuded. The My Task portlet which display project work plan task information is available to Time Management License holders, but only for those tasks to which they are assigned. A Time Management license must be requested by a Resource Manager through submission of the Resource Profile Update Request.

The Time Sheet object, entry form and process is utilized to capture all actual hours worked in IT. Both Employees and Contractors must enter their hours by day, by task, on a weekly basis. Time Sheets must be submitted by 8:00AM on Monday morning for the weekly period ending Friday at midnight. The work week for Demand Management and Time Sheet period starts at 12:01AM Saturday. Time Sheet Policy as currently configured includes:

• Only one Time Sheet can be submitted for each week. It must include all tasks and time to be accounted for the weekly period.
• You are not required to be assigned to a Project Task in order to charge time against it. However, you should contact the Project Manager to be assigned and update the project scheduled hours and labor forecast for Demand Management.
• Employees must account for all hours associated with their employment. This should include any time away from work such as PTO (Paid Time Off), Jury Duty, Community Service, Holidays, etc
• Contractors must account for all hours worked and will only be paid for those hours submitted via the HP-PPM time sheet. Your time sheet will be approved by your respective Resource and\or Project Manager upon submission. Once Approved, you will receive a Notification that it is ready to print so you can submit it to your parent organization.
• See the Time Entry Guide for more detailed information.

Title is an attribute assigned to each resource. The drop down list currently contains a combination of position names and skill sets. Their is no functional behavior or utilization associated with this field. This attribute will be included in the Active Directory update from Peoplesoft on the next release of the LDAP process.

Unassigned Tasks    This is one of seven Exception Rules which can be enabled to generate a flag at the task level reflecting a project issue which requires attention. These Rules are enabled in the Project | Settings | Exception Rules tab. If the task Scheduled Start date occurs within x days (also set at the Exceptions Rule tab) and there is no Resource assigned, then the exception flag will be set for the task the next time the project file is SAVED. Exception flags may be utilized to gauge a summary task, phase or project's "health".

The Use Time Managememt to track actual effort against this project check box is located on the Cost and Effort tab in Project Settings in the Project Workbench. If checked, one of three options is selectable: Master Project Only; Sub-projects at hierarchy level # (selectable) or All tasks. Standard IT Project Type is set at All Tasks.

Weekly Accomplishment attribute is a narrative field on the Weekly Project Status Report that the Project Manager populates on a weekly basis. This field should briefly define project accomplishments and Issues resolved.

The Weekly Status Report is an On-line Project & Program Status Reporting request type. Implemented in May 2006, it provides a single point of access for the project manager to update the status of his project for all stakeholders. The weekly Status Report request type provides input for narrative status updates as well as health and phase indicators. A printed version of the Report, which combines the Status Report Input with milestone, risks and issues information from the project overview can be created and distributed to non HP-PPM stakeholders. All HP-PPM Reports are in the repository, and are available from the Reports | View Reports menu. Entry fields for the request::

• Project Health - Subjective valuation by the Project Manager. The system calculated "Health" is based on task exceptions which generally help the PM manage by exception but do not reflect Project Status.
• Executive Summary - Short overview of the Project. Perspective is from the Director and above level who may not know much about the project. It should be complete and utilized to reflect any necessary escalations.
• Weekly Accomplishments - As scheduled accomplishments should be reflected in the report Milestones section, this should be used to highlight major accomplishments and define unscheduled event.
• Not Accomplished - Any major milestone delivery dates which have been missed should be reported here with a status, forecast, impact and action plan.
• Planned Next Week - Major Milestones scheduled for completion in the next period and expected progress on those reported above.
• Key Decisions Made - Narrative
• Key Decisions Needed - Narrative which should identify the person responsible for the pending decision.
• Summary Status - Drop down menu selection
• Project Phase

The Work Plan is the Project Schedule and can only exist as part of a Project Request. It is included in the Project "container" as one of many data sets. It includes the detail tasks, dependencies, scheduled dates and assigned resources, and tracks actual progress through updates from actual hours entered via weekly time sheets. A Project Work Plan can be created in one of three ways:

• Manually by adding one task at a time.
• Utilizing a Template based on the type of Project.
• Importing a schedule from Microsoft Project.

Work Plan behavior and functionality is primarily controlled by settings in the Project Type, which is defined at the time the Project Request (not Work Plan) is created; and once set can not be changed. These controls include what fields are available, where enterprise load is reflected, how the product synchronizes or interacts with Microsoft Project Schedules and other optional settings. For an introduction to Project Work Plans view the HP-PPM Project Work Plans Powerpoint presentation.

Workflow

System Function

HP-PPM Support

11/28/07

The Workflow functionality facilitates the communications process for information distribution and IT Governance control via routing electronic documents through the organization. Each Request Type in the HP-PPM System contains a unique workflow which tracks progress and records actions against the workflow. As each step is "Completed" (or other options executed), the person completing the step, as well as the date\time stamp are recorded as part of the permanent workflow record for that particular Request. Notifications can be automatically sent to document stakeholders indicating status change at each workflow step execution. See also Status for related information based on current Request Types.

The Workload Category attribute is a selectable project type utilized for filtering and reporting. The current selectable values are: Strategic Projects, Legacy Systems, Operatonal Support and Maintenance.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Questions, Updates or Corrections, please contact HP-PPM Support at dan.gallagher@CIMpleBS.com or call 678-848-1830