- Resources have booked time in the past week (validation needed)
- Inactive Resources with ETCs still on the project
- Tasks past their Finish Date but not completed
- Task Role Assignments in the past
-
“PM Stalker – Project Validations & Issues” executes various queries against the Clarity database and sends an email to all PMs who have one or more projects with any of the following conditions: -
“PM Stalker – Project Validations & Issues” executes various queries against the Clarity database and sends an email to all PMs who have one or more projects with any of the following conditions:
- Resources have booked time in the past week (validation needed)
- Inactive Resources with ETCs still on the project
- Tasks past their Finish Date but not completed
- Task Role Assignments in the past
-
A process that:- is a weekly email to a project manager. All of the content will be for where the person getting the email is the PM
- shows aggregate data for all of their projects
- sends the PM a reminder email at the end of each week showing the items that the PM needs to do. Maybe call it Weekly PM reminder.
- Shows the mentioned data in sections as follows:
- Past Due issues
- Only active projects
- Only open issues – not resolved or closed
- Show project name, project ID, issue name, issue priority, target resolution date, color (only red or yellow)
- Logic for Yellow = where target resolution is within the next week
- Logic for Red = target resolution date is in the past
- URL LINK: to that issue
- Past Due Risks
- Only active projects
- Only open risks – not resolved or closed
- Show project name, project ID, risk name, risk priority, target resolution date, color (only red or yellow)
- Logic for Yellow = where target resolution is within the next week
- Logic for Red = target resolution date is in the past
- URL LINK: to that risk
- Past Due Status Report
- Only active projects
- Show project name, project ID, report date, most recent overall status, color (only red or yellow)
- Only 1 line per project – show even if there is no status report
- Logic for Yellow = where latest status report date > 7 days ago
- Logic for Red = latest status report date is > 14 days ago
- URL LINK: to status report list
- Past Due Milestones
- Only active projects
- Only open milestones
- Show project name, project ID, task name, task finish date, color (only red or yellow)
- Logic for Yellow = where finish is within the next week
- Logic for Red = finish date is in the past
- URL LINK: to that milestone
- Past Due Forecast
- Only active projects
- Show project name, project ID, last updated date, most recent total plan of record amount, color (only red or yellow)
- Only 1 line per project – show even if there is no finish plan
- Logic for Yellow = where last updated date of the plan of record > 14 days ago
- Logic for Red = where last updated date of the plan of record > 30 days ago
- URL LINK: to cost plan
- Allocation Summary for the Project Team
- Past Due issues
- Unfilled Roles that need to be staffed
- Resources Actuals +/- 25% of Allocation
- Resource ETC +/- 25% of Allocation
- Pending Change Controls / Approval Status
- In addition to the Past Due Milestones, upcoming milestones
- Budget Summary
- Actual vs. Planned
- Burndown estimate
-
A process that:
- is a weekly email to a project manager. All of the content will be for where the person getting the email is the PM
- shows aggregate data for all of their projects
- sends the PM a reminder email at the end of each week showing the items that the PM needs to do. Maybe call it Weekly PM reminder.
- Shows the mentioned data in sections as follows:
- Past Due issues
- Only active projects
- Only open issues – not resolved or closed
- Show project name, project ID, issue name, issue priority, target resolution date, color (only red or yellow)
- Logic for Yellow = where target resolution is within the next week
- Logic for Red = target resolution date is in the past
- URL LINK: to that issue
- Past Due Risks
- Only active projects
- Only open risks – not resolved or closed
- Show project name, project ID, risk name, risk priority, target resolution date, color (only red or yellow)
- Logic for Yellow = where target resolution is within the next week
- Logic for Red = target resolution date is in the past
- URL LINK: to that risk
- Past Due Status Report
- Only active projects
- Show project name, project ID, report date, most recent overall status, color (only red or yellow)
- Only 1 line per project – show even if there is no status report
- Logic for Yellow = where latest status report date > 7 days ago
- Logic for Red = latest status report date is > 14 days ago
- URL LINK: to status report list
- Past Due Milestones
- Only active projects
- Only open milestones
- Show project name, project ID, task name, task finish date, color (only red or yellow)
- Logic for Yellow = where finish is within the next week
- Logic for Red = finish date is in the past
- URL LINK: to that milestone
- Past Due Forecast
- Only active projects
- Show project name, project ID, last updated date, most recent total plan of record amount, color (only red or yellow)
- Only 1 line per project – show even if there is no finish plan
- Logic for Yellow = where last updated date of the plan of record > 14 days ago
- Logic for Red = where last updated date of the plan of record > 30 days ago
- URL LINK: to cost plan
- Allocation Summary for the Project Team
- Past Due issues
- Unfilled Roles that need to be staffed
- Resources Actuals +/- 25% of Allocation
- Resource ETC +/- 25% of Allocation
- Pending Change Controls / Approval Status
- In addition to the Past Due Milestones, upcoming milestones
- Budget Summary
- Actual vs. Planned
- Burndown estimate
-
A process that:
- is a weekly email to a project manager. All of the content will be for where the person getting the email is the PM
- shows aggregate data for all of their projects
- sends the PM a reminder email at the end of each week showing the items that the PM needs to do. Maybe call it Weekly PM reminder.
- Shows the mentioned data in sections as follows:
- Past Due issues
- Only active projects
- Only open issues – not resolved or closed
- Show project name, project ID, issue name, issue priority, target resolution date, color (only red or yellow)
- Logic for Yellow = where target resolution is within the next week
- Logic for Red = target resolution date is in the past
- URL LINK: to that issue
- Past Due Risks
- Only active projects
- Only open risks – not resolved or closed
- Show project name, project ID, risk name, risk priority, target resolution date, color (only red or yellow)
- Logic for Yellow = where target resolution is within the next week
- Logic for Red = target resolution date is in the past
- URL LINK: to that risk
- Past Due Status Report
- Only active projects
- Show project name, project ID, report date, most recent overall status, color (only red or yellow)
- Only 1 line per project – show even if there is no status report
- Logic for Yellow = where latest status report date > 7 days ago
- Logic for Red = latest status report date is > 14 days ago
- URL LINK: to status report list
- Past Due Milestones
- Only active projects
- Only open milestones
- Show project name, project ID, task name, task finish date, color (only red or yellow)
- Logic for Yellow = where finish is within the next week
- Logic for Red = finish date is in the past
- URL LINK: to that milestone
- Past Due Forecast
- Only active projects
- Show project name, project ID, last updated date, most recent total plan of record amount, color (only red or yellow)
- Only 1 line per project – show even if there is no finish plan
- Logic for Yellow = where last updated date of the plan of record > 14 days ago
- Logic for Red = where last updated date of the plan of record > 30 days ago
- URL LINK: to cost plan
- Allocation Summary for the Project Team
- Past Due issues
- Unfilled Roles that need to be staffed
- Resources Actuals +/- 25% of Allocation
- Resource ETC +/- 25% of Allocation
- Pending Change Controls / Approval Status
- In addition to the Past Due Milestones, upcoming milestones
- Budget Summary
- Actual vs. Planned
- Burndown estimate
-
A process that removes all the group assignments for inactive users after execution of process. The following are removed for all inactive users:- Group assignments
- Instance rights
- Global rights
-
A process that removes all the group assignments for inactive users after execution of process. The following are removed for all inactive users:
- Group assignments
- Instance rights
- Global rights
-
The interface runs using a MS Excel template called Project Allocation Upload that will be distributed to users.- Configuration
- A master object called Allocation Upload Files will be created. The object will contain a required attachment field on the create page that will receive the Project Allocation Upload MS Excel file.
- A new sub-object called Allocation Upload Records will be created. This object will contain the fields necessary to receive the data rows from the Project Allocation Upload template.
- The master object will store the file level data while the sub-object will store the rows that belong to the file.
- Users must be granted security to view and edit the master and sub-objects in order to run the upload process.
- Project Allocation Upload Template
- The Project Allocation Upload template must remain static. Any changes other than creating additional time periods or additional rows will cause the process to error.
- Only the Project Allocation Upload template can be used to load records to the new objects.
- The Project Allocation Upload will only accept months across the x-axis in the format DD/MM/YYYY. The month headers must appear in the first row of the template and contain the first day of the month.
- The template must be distributed to the users that will be using the upload functionality.
- Users will be required to enter an Investment ID and Resource ID so the process can correctly identify investments and resources to upload the allocation hours against.
- A Staff OBS is not required but can be populated by users to have the data uploaded into CA PPM.
- The owner of the Project Allocation Upload template is responsible for providing users a valid list of Staff OBS Units.
- Investments will not be created through the interface. As such a valid Investment ID must be provided.
- Resources can be added to the investment team through the interface. If a valid Resource ID is provided the resource’s allocation will be updated if the resource already exists on the investment. If the resource does not already exist on the investment the resource will be added to the team along with the allocation hours.
- The Project Allocation Upload template will accept hours, not allocation percentages. Because CA PPM stores allocations as percentages of a resource’s availability the upload process must convert hours to a percentage. As a result small rounding errors may occur in the neighborhood of .01 hours per month.
- Resources cannot be removed from investment teams through the interface.
- The Project Allocation Upload template will support allocation uploads to different instances of the same role on the same investment as long as different Staff OBS units are provided.
- If multiple instances of the same role are assigned to the investment with the same Staff OBS the process will not know which instance of the role to upload the hours to. In these cases the process will consider these records as invalid. The PM will need to manually remove one of the instances or upload the hours manually..
- If multiple instances of the same role with the same Staff OBS unit are assigned to the same investment in the upload template the monthly hours will be totaled by investment, by role, by Staff OBS.
- The allocation template will follow the format in the screenshot area.
- Process
- To initiate the Allocation Interface a user will create a new Allocation Upload File instance, attach the Project Allocation Upload Template, and save the record. The file attachment field is an “enter-once” field, meaning that once a value has been set it cannot be changed. If a user wishes to upload another field they will create a new record.
- After the file has been attached the user will be presented with two check box fields, one to Validate and one to Validate and Upload. Checking either or both options will initiate the process.
- The process will first determine if any sub-object instances exist for the file. In other words, do any records already exist in the Allocation Upload Records sub-object pertaining to the newly uploaded file. If there are no records in the sub-object the process will use the uploaded file and read its contents into the sub-object. If errors are encountered during the file read they will be written to the process console, the process will throw an error, and end.
- Next, records will be validated. Only the sub-object instances that belong to the master object will be validated. Records belonging to other master object instances will not be validated or processed. All records in a status of Ready for Processing, Failed Validation, or Xog Load Error will be validated. Records will fail validation if an investment is not found corresponding to the investment ID provided, a resource is not found corresponding to the resource ID provided, or the date provided is not valid, or a provided Staff OBS does not yield a match. Records that fail validation will be flagged as invalid along with a description as to why they failed validation. Records that pass validation will be flagged as Ready for Processing and locked. The sub-object instances can be exported to excel if further analysis is required. If the Validate & Upload option was not selected the process will end here.
- Regarding the Staff OBS. Only one OBS can be designed as the OBS that the interface will use to validate the Staff OBS records.
- The Staff OBS value from the template must match against the name of an OBS node in the designed Staff OBS.
- If the Staff OBS value matches against multiple nodes in the Staff OBS the record will be flagged as invalid as the process will not know which node to use.
- If the Validate & Upload option was selected the process will continue and any valid records will be xog’ed into the investment team. The xog will be executed as the user that initiated the process so any security rules enforced by xog will be respected by the process.
- Successful records will be flagged as Processed Successfully in the sub-object and remain locked. Records that did not load successfully, due to a xog error or security limitation will be flagged as Xog Load Error, unlocked, and updated with a description containing the full xog output.
- Records that failed validation or failed the xog load can be manually edited and revalidated, and attempt to be uploaded again. Subsequent runs of the process will not read in data from the file, but rather process only sub-object instances that currently exist.
- Configuration
-
The interface runs using a MS Excel template called Project Allocation Upload that will be distributed to users.
- Configuration
- A master object called Allocation Upload Files will be created. The object will contain a required attachment field on the create page that will receive the Project Allocation Upload MS Excel file.
- A new sub-object called Allocation Upload Records will be created. This object will contain the fields necessary to receive the data rows from the Project Allocation Upload template.
- The master object will store the file level data while the sub-object will store the rows that belong to the file.
- Users must be granted security to view and edit the master and sub-objects in order to run the upload process.
- Project Allocation Upload Template
- The Project Allocation Upload template must remain static. Any changes other than creating additional time periods or additional rows will cause the process to error.
- Only the Project Allocation Upload template can be used to load records to the new objects.
- The Project Allocation Upload will only accept months across the x-axis in the format DD/MM/YYYY. The month headers must appear in the first row of the template and contain the first day of the month.
- The template must be distributed to the users that will be using the upload functionality.
- Users will be required to enter an Investment ID and Resource ID so the process can correctly identify investments and resources to upload the allocation hours against.
- A Staff OBS is not required but can be populated by users to have the data uploaded into CA PPM.
- The owner of the Project Allocation Upload template is responsible for providing users a valid list of Staff OBS Units.
- Investments will not be created through the interface. As such a valid Investment ID must be provided.
- Resources can be added to the investment team through the interface. If a valid Resource ID is provided the resource’s allocation will be updated if the resource already exists on the investment. If the resource does not already exist on the investment the resource will be added to the team along with the allocation hours.
- The Project Allocation Upload template will accept hours, not allocation percentages. Because CA PPM stores allocations as percentages of a resource’s availability the upload process must convert hours to a percentage. As a result small rounding errors may occur in the neighborhood of .01 hours per month.
- Resources cannot be removed from investment teams through the interface.
- The Project Allocation Upload template will support allocation uploads to different instances of the same role on the same investment as long as different Staff OBS units are provided.
- If multiple instances of the same role are assigned to the investment with the same Staff OBS the process will not know which instance of the role to upload the hours to. In these cases the process will consider these records as invalid. The PM will need to manually remove one of the instances or upload the hours manually..
- If multiple instances of the same role with the same Staff OBS unit are assigned to the same investment in the upload template the monthly hours will be totaled by investment, by role, by Staff OBS.
- The allocation template will follow the format in the screenshot area.
- Process
- To initiate the Allocation Interface a user will create a new Allocation Upload File instance, attach the Project Allocation Upload Template, and save the record. The file attachment field is an “enter-once” field, meaning that once a value has been set it cannot be changed. If a user wishes to upload another field they will create a new record.
- After the file has been attached the user will be presented with two check box fields, one to Validate and one to Validate and Upload. Checking either or both options will initiate the process.
- The process will first determine if any sub-object instances exist for the file. In other words, do any records already exist in the Allocation Upload Records sub-object pertaining to the newly uploaded file. If there are no records in the sub-object the process will use the uploaded file and read its contents into the sub-object. If errors are encountered during the file read they will be written to the process console, the process will throw an error, and end.
- Next, records will be validated. Only the sub-object instances that belong to the master object will be validated. Records belonging to other master object instances will not be validated or processed. All records in a status of Ready for Processing, Failed Validation, or Xog Load Error will be validated. Records will fail validation if an investment is not found corresponding to the investment ID provided, a resource is not found corresponding to the resource ID provided, or the date provided is not valid, or a provided Staff OBS does not yield a match. Records that fail validation will be flagged as invalid along with a description as to why they failed validation. Records that pass validation will be flagged as Ready for Processing and locked. The sub-object instances can be exported to excel if further analysis is required. If the Validate & Upload option was not selected the process will end here.
- Regarding the Staff OBS. Only one OBS can be designed as the OBS that the interface will use to validate the Staff OBS records.
- The Staff OBS value from the template must match against the name of an OBS node in the designed Staff OBS.
- If the Staff OBS value matches against multiple nodes in the Staff OBS the record will be flagged as invalid as the process will not know which node to use.
- If the Validate & Upload option was selected the process will continue and any valid records will be xog’ed into the investment team. The xog will be executed as the user that initiated the process so any security rules enforced by xog will be respected by the process.
- Successful records will be flagged as Processed Successfully in the sub-object and remain locked. Records that did not load successfully, due to a xog error or security limitation will be flagged as Xog Load Error, unlocked, and updated with a description containing the full xog output.
- Records that failed validation or failed the xog load can be manually edited and revalidated, and attempt to be uploaded again. Subsequent runs of the process will not read in data from the file, but rather process only sub-object instances that currently exist.
- Configuration
-
This process workflow with gel script forces billable hours on timesheet down to 40 hours, and sets overtime hours to non-billable. Timesheets with 40 or fewer hours are not touched. Process kicks off upon submission of timesheet. Steps are:- Determine if timesheet has > 40 hours. If so, proceed.
- Create a SPLIT row for each timesheet row, with Input Type Code = Non-Bill.
- Divide 40 by total timesheet ours. Store this value.
- Multiply each timesheet cell by the stored value, and enter the result into that cell.
- Take the difference (original cell value – new cell value), and enter in same cell on Split row.
- The end result will be 40 hours total on Billable rows, and overtime hours on Non-Billable rows.
-
This process workflow with gel script forces billable hours on timesheet down to 40 hours, and sets overtime hours to non-billable. Timesheets with 40 or fewer hours are not touched. Process kicks off upon submission of timesheet. Steps are:
- Determine if timesheet has > 40 hours. If so, proceed.
- Create a SPLIT row for each timesheet row, with Input Type Code = Non-Bill.
- Divide 40 by total timesheet ours. Store this value.
- Multiply each timesheet cell by the stored value, and enter the result into that cell.
- Take the difference (original cell value – new cell value), and enter in same cell on Split row.
- The end result will be 40 hours total on Billable rows, and overtime hours on Non-Billable rows.
-
This process must be run using the “Execute a Process” job. Job may be scheduled or run on-demand. Process pulls Availability Rate from the Availability blob for each resource, where blob is not null. Then it populates this value into a custom Daily Availability attribute (Number field with 2 decimals) on the Resource object. This field does not have to be displayed to be used for reporting. Because the OOB Availability Rate field is stored only in a blob, it is difficult to include in portlet or report output. The use of this custom attribute makes the value easily reportable.
