TQM, Project Management and Risk
We take a brief turn from our previous agile posting and divert to Total Quality Management tools applied to conventional Project Management with an excerpt from our book by that title.
Consider our company has outsourced a significant portion of our project to a supplier, and in our evaluation of the risks via our Risk FMEA tool. We believe that should this event come to pass, it will have significant impact on our project success, particularly the delivery. We then pick a metric to monitor over the course of the project that will help us to know what is going on and when we may need to intervene, and we pick Schedule Performance Index. All part of this is part of risk monitoring and control. We demonstrate how this monitoring and control can take place using a visual approach much like that of a control chart.
TQM for Project Management- and the PMO
We may choose to sort our table on financial risk rather than severity to highlight significant financial challenges. The sum of all the financial risks is the contingency risk for the total project.
The trigger is a new concept to those acquainted with the FMEA approach to problem elimination. We could use, for example, the Schedule Performance Indicator as an index showing the efficiency of the time utilized on the project, as compared to the estimates for the project. Schedule performance indicator can be calculated using the following formula:
SPI = Earned Value (EV) /Planned Value (PV)
SPI = BCWP / BCWS
The formula mentioned above gives the efficiency of the project team in using the time allocated for the project.
SPI > 1 indicates project team is very efficient in using time allocated to project.
SPI < 1 indicates project team is less efficient in using time allocated to project.
When we know the performance expected from our supplier to meet the needs of our project, we can monitor that performance against the needs. When the supplier’s performance starts to move outside the zone that our project deems acceptable, we can start mitigating actions. The figure illustrates our tracking a supplier’s performance against the project’s operating expectation. These expectation levels are identified as the upper and lower risk levels in the graphic above. We monitor the SPI<1 because this will mean our project / supplier is executing below what is needed to achieve the project expectation portending a cost over-run.
That addresses the reason for the lower SPI limit but what about the upper limit? Why would we worry about a project that provides a great deal more efficiency than planned (SPI>1)? We can suggest a few reasons. The first reason—we may question the validity of the estimates upon which the SPI calculation is based. Maybe the estimates were unduly padded. It could also be that some of the activities that went into the estimation are being neglected—essentially cutting corners from what we expected. We can ask questions to determine if this is in fact the case. It could also be that the numbers have undergone some tampering. In any of these events, follow on questions and exploration will help determine if there is a reason for concern. We are surprised that tactics such as establishing control limits on a supplier’s SPI or CPI do not seem to be very common in industry. Then again, we wonder why we infrequently see such things as tracking Gantt charts of the supplier.
 Pries, K., & Quigley, J. (2012). Chapter7 Process Control and Metrics. In Total Quality Management for Project Management (pp. 150-151). Boca Raton, FL: Taylor & Francis.