Skip to main content

As a living, breathing program, the PSM elements and associated activities such as audits, PHAs, Incident Investigations, etc. that occur on a regular and continual basis, inevitably result in the creation of recommendations or action items that need to be addressed properly and in a timely manner. Those recommendations also inevitably result in some potential rescheduling or some budgetary or resource changes. Therefore, action item tracking is a core PSM function and should be a fundamental piece to any PSM software solution. In this entry, we will provide some details on the tools available within the APSM software to manage due dates from Audits, PHAs, and Incident Investigations.

Initial Due Date Assignments

Any time an activity is documented and an assignment or task is made within APSM, users have the ability to assign a due date for that particular action item. The timeframe for that due date will correspond to various factors such as severity of the risk, resource availability, the type of recommendation that is being made, etc. Within APSM you can structure your recommendations so that the initial due date allowance meets the parameters of your particular company or plant policy. As an example, high priority items may need to be completed within 30 days, medium priority items within 90 days, and low priority items may be completed within 180 days, or maybe it’s 3 months, 6 months, and 1 year. This structure can be utilized with APSM to guide the selection of appropriate due dates based on the priority and severity of the recommendation itself, which does not allow a due date outside of the appropriate timeframe for that particular level of risk, meaning a high priority item could not have a due date outside of a 30 day or 3 month timeframe.

Below is a screenshot where the furthest available due date is auto populated by the selection of the priority (Medium):

Due Date Changes

As we all know, there will be times when a due date does indeed need to be changed, but what should be avoided is the user option to simply change a due date with no review process, no approvals, and no accountability just to avoid that item going “overdue”. Therefore, once a due date has been selected based on the risk parameters above, changing that due date to be outside of that original risk-based parameter should require an approval.

Within APSM, anytime you attempt to change due date, it prompts the user to provide a “Change Reason” which will go to a designated individual for review and either approval or rejection. This field is required if the due date tracking has been activated within your company portal and you’ve defined your priority levels and corresponding time limits.1

This due date change request then sends an immediate email to the designated approver with the “Change Reason” as well as the original due date, the propsed new due date, and the original source of the recommendation (see below).

Due Date Change Approvals

While this date change request is pending, the due date for the task will remain as the original date until an approval is given, but it does show the change request as part of the recommendation history. This allows for complete control in documenting progress, delays, etc. In the event of approval or rejection, the supervisor making the approval/rejection is required to include comments as well which will be displayed on the change request (see below).

Once the approval has been made, the due date changes, and all of the communication is visible within the recommendation so that you can provide details to an inspector or a manager as to why things are different now than the original due dates. There is no limit to the number of changes that can be made, since all of them require a new change request and new approval.

This feature is critical to facilities as they manage their open recommendations and can prove invaluable to managers and corporate personnel as they stay on top of multiple recommendations from facilities, studies, etc. and to maintain the transparency and accountability that is paramount to a functional PSM program.


1 If you don’t see this feature turned on and would like it to be activated, please contact