Risk Management Process Example Business

A risk management process example for business is described in the published article titled ″High Vantage Point: Report-outs to reduce the Risk of Organizational Problems″ written by Forrest Breyfogle.

A PDF of this article below describes how an organization typically views its safety and other infrequent occurring events as lagging indicators. With this traditional risk management approach, each event is often discussed in isolation with the intent that changes be made to avoid re-occurrence.  However, an effective time-series data analysis of the time-between safety violations (for example) often indicates that nothing has changed. Another alternative reporting methodology is needed that tracks these infrequent failure-events from a process output point of view. Continue reading Risk Management Process Example Business

Project to reduce the maintenance backlog.

I have a student who has a project to reduce the backlog of maintenance requests.  They are failing to complete the preventive maintenance (PM) and corrective maintenance (CM) requests.  Their leadership is upset and wants it fixed.  Of course they must do it without staffing up.  Can it be done?  Yes.

The focus of this posting is how the selection of the project metric is a key factor in the student’s ability to make improvements.  I recommended managing the project on metrics other than the backlog count.  But he said that is my leadership directive!

When running a project you must always keep the 30,000-foot-level metric that the project was chartered to improve in your focus, but not necessarily the as the primary metric to measure change and improvements against.  Why is that?  Well if they wanted to evaluate an improvement, they could implement it and then they would need to wait to see if the backlog started going down, which could take months, since it goes down on some days and up on some days depending on what is scheduled.  You would need a long span of days to see if it is consistently going down.  By the way, backlog is an attribute, which, using my thumb rule, will require 100x more data than if we use a continuous measure.

What would be continuous?  I discussed with the student a few ideas.  One is to track the time per maintenance action vs. the standard time.  If we are spending more time than planned, there will be jobs added to the backlog, if faster, they will come off.  If a change is made, then they should work faster and you will know it long before you wait for a few hundred activities to complete.  Another could be tracking hrs spent of maintenance, if the problem is not allocating enough time.  Higher hours should mean more work.

If you do not like the continuous options, change to tracking the daily accomplishment count.  Look at the daily accomplishments vs. plan.  Beat it and the backlog will come off.  This metric has an advantage if you find evidence that the problem is due to an entitlement feeling of the workforce.  If they get the scheduled work done early they stop working.  On slow days they fall short but go home on time.  In the end you will add to the backlog and never take anything off.

The message is that the business knows what they look at in their high level score card.  If you are told to change that metric, well you should do it.  It does not mean that you must use that metric for your project, as long as your chosen metric improvement will end up will end up improving the business metric.  This is no different than being told to reduce defects, and your project drills down to a single defect type and just improves it.   or if you are told to reduce the time to process a transaction and you find that most of the problems are found in step 5.  Change your metric to the defect rate of the chosen type or to the lead time in step 5.  You know fixing it will fix the overall metric.  It is OK.

Enhanced by Zemanta