Introduction

We continue our Total Quality Management for Project Management and the PMO.  TQM can help us with the planning of the project giving us some measure of historical performance from which we can learn. However, it is not just the planning that can be aided by TQM, but also the strategy we intend to take with the project.  If there are things we have learned from our past project strategies, that we have taken a measured approach, we can use these to help understand our strategies true rate of ssuccess.

TQM for Project Management- and the PMO

Below is an excerpt from that book. [1]

In the years we have been working, we have seen ample examples of use of hope as a tool for product development and managing project’s in general.  We call it hope, because we make our decisions to produce a certain outcome though we may actually know little about what it may take to be successful.  Even when we do “know” our organization may ignore what is being said to meet this objective. We are not talking about the occasional event where something falls between the cracks.  We are talking about those times when the people around us have been taking measurements to understand the issues and possibilities of that organization.  Instead of building upon this, we summarily dismiss this person that is proving us wrong with this information as not being a team player or just a naysayer with a negative attitude.

A manufacturing engineer will pay attention to the capabilities of his equipment. If, for example, the demanded or needed throughput of product through that piece of equipment is higher than the equipment is capable of producing, some other course of action will be required. It may be possible to adjust the machine – customizing the machine to improve performance. It may be deemed necessary to otherwise upgrade the equipment. Maybe purchase another piece of equipment that meets this new throughput demand.  Maybe the solution is to purchase another piece of equipment and between these two pieces of equipment meet the throughput demands.  The rational engineer will not likely try to force the demanded product through the equipment if the equipment has a throughput limitation and expect all to be well.

Let us consider a product made of a particular type of plastic that has a specific melting point.  It is not likely this product will maintain the features desired or meet the customer’s demands above a certain level of heat stimulus.  It would not seem likely that a sensible person would violate the physical properties of the material and complain about the predictable failure.  The person designing the product would benefit greatly from knowing the attribute of the plastic prior to using the material in a design.

What do these things have in common?  Well, this is exactly the sort of thing that goes on in organizations every day!  This happens in product development and project management.  Many believe that “the old college try” will save us.  Those individuals who point to real data – to show the “reality” are derided as being naysayers; they are not team players.  These people are overly negative.  What does it say for those of the team that ignore the historical record?  The time-honored saying attributed to George Santayana: “Those who cannot remember the past are condemned to repeat it.”

Why TQM Is Important to the Project Manager[2]

Total Quality Management (TQM) involves the application of quality techniques to all segments of the enterprise. We are recommending that TQM be applied to project management also.

Most of the project managers (PMs) we have known have focused first and foremost on the project schedule, next on the project budget, and lastly on the project quality issues. We suspect this approach may even be so topsy-turvy as to be backwards. At no point have we seen project managers applying any sensible quality techniques to their own process. Ultimately, each project we witnessed devolved into a weekly nagging meeting that lasted at least an hour as the PM desperately tried to assert some level of debatable control by doing a futile “time line review.” We know that powerful methods exist to eliminate the flailing usually seen, particularly at the end of the project.

This project flailing may be visible at the end of the project; however, the reasons for the flailing are well before this point, usually in the planning phase.  The TQM tools demonstrated in the following chapters will show how planning that does not derive from past experience is really not planning at all, but going through the motions. TQM and developing a learning organization are tied together.