TQM for Project Management
Below is an excerpt from our book, Total Quality Management for Project Management[1]
Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it. In the first stage of life the mind is frivolous and easily distracted, it misses progress by failing in consecutiveness and persistence. This is the condition of children and barbarians, in which instinct has learned nothing from experience.
The Life of Reason, Volume 1
George Santayana
1905
TQM for Project Management- and the PMO
Product development is becoming increasingly complex. Technology is advancing. Projects are often populated by a diversity of people in a plurality of locations. Effectively managing these complex projects requires attention to details. When we understand the range of possibilities for our project’s execution we minimize the risk associated with that project. We can make plans that meet our typical performance. Thus we minimize the schedule risks associated with a project that has dates based upon hope and want with little or no basis in reality. When we drive our people to a schedule that they are aware is a death march, we set them up for failure.
Consider the company management the coach of the team. Certainly like any coach, we will want to push our people to perform better every day. However, a coach does not push the team to boundaries that the coach knows are not possible. For example, you will not hear a football coach ask his wide receiver to fly in the air for 50 yards. That is not a possible task. He may, however, see how fast that athlete is, and believe he can get him to run a fifty-yard dash in fewer seconds. Imagine what we do to the employee morale when we ask them to do what they know is not possible. Additionally, like a coach, we cannot show our team where we can improve if we do not know how that team presently performs. Further, our game strategy hinges upon what we have for a team. Is our team fast? Is it slow and strong? We have to either plan our strategy for our organization’s goals, or we have to adapt our present team and playbook to the team we need to achieve our goals. To do so, we must know what we have for a playbook and team. To know what we have for a playbook and team requires measurements and analysis.
This book is about applying those Total Quality Management tools to both the line functions in your project as well as the project management discipline. You must study your organization to know what really can be achieved. A fist pound on a conference table with an arbitrarily set date that has no basis in reality may not motivate many people. While the world is plenty uncertain, we can learn something from the activities our organization performs. We may find out many of the things we assumed valid are not really true. We may find areas of the organization where a little effort will produce great performance improvements. We will have to study these things to find that out and TQM tools are key instruments in achieving that understanding.
The genesis of this book is in part serendipity. We were setting up a class that merged the discipline of Total Quality Management with Project Management. We realized we have never seen a book that applies these tools beyond the manufacturing realm. The more we thought on this, the more we realized while projects are unique, in each organization there are similarities between projects that could help “read the runes” as it were, to improve project future success. In the text below, we discuss the organization as a project factory bringing the TQM tools into the project management and line management function’s of an organization. We treat each area in the organization as if it were a station in our manufacturing facility. An organization’s process can help move the project from “every time is like the first time” to something that is not entirely unique every time. For example, consider a test department in a company that designs systems composed of embedded (software and hardware) and electrical components. That department may employ similar tools and will have some set of processes to accomplish the test and verification tasks at hand. We can critique our past and present to improve the future execution of our projects. At a very bare minimum, we will at least see the range of possible outcomes for the tasks we are monitoring within our organization. We can use this information to help with the future estimating of projects tasks, while considering that variation that we have seen in those processes and tasks.
[1] Pries, K., & Quigley, J. (2012). Preface. In Total quality management for project management (pp. Xxi-xxii). Boca Raton, FL: Taylor & Francis.
