I recently had a phone call from the acquisition editor at Taylor and Francis, John Wyzalek. He informed me that a book we wrote a couple of years back (Total Quality Management for Project Management), is being used at Manchester Metropolitan University, and gave me the contact information of the lady creating and teaching the class, Maria. I have had a few calls with Maria Kapsali since then that have been very interesting.
We discussed how the Total Quality Management tools can help us avoid deluding ourselves. However, at least equally important if not more so, is having a team come to some common understanding of what is being witnessed. The discussion pointed us to how to evoke ideas of the source of some of the issues being witnessed. For example, we explored starting with the brainstorming tool often associated with Total Quality Management, the Ishikawa Diagram or fishbone diagram. The students had a project associated … Continue reading
Why Statistics and Control Are Important to the Project Manager
More from the TQM and Project Management 
One of the purposes of statistical analysis lies in its ability to discern random variation from non-random (or “controllable”) variation. Random variation is extremely difficult to control, although we have seen situations where variance could be diminished through rigorous use of designed experiments. It is much more common for practitioners to move the mean rather than “fix” the variance.
The TQM project manager will want to understand what factors he or she can control and which factors effectively lie outside the domain of project management. When this awareness manifests, project managers begin to have true control, because they are working with those factors that they can, indeed, influence.
Furthermore, the charts can provide a valuable visual indicator to management about what is really going on during the process. The most difficult part of the statistics and control … Continue reading
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.
Below is an excerpt from that book. 
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 … Continue reading
Standard Time Plans
I post this blog, because I have recently witnessed an organization working to create a standard time plan for their work. This is not necessarily a bad thing, however, by PMI definition, projects are not operations and are unique. Each project can have considerable variation in scope and personnel. This is especially true for product development, which is often exploration and knowledge management type work. The attempts to superimpose a standard time plan will require the use of TQM tools for success. Or these types of projects are misguided at best. The use of standard implies that we have a way of knowing what is typical, and even typical has variation. Standard times are often used in repair scenarios, for example a standard time to replace an alternator. However, replacing that alternator has a well-defined set of steps and tools. The measurements of the time to achieve the replacement are made many times with different people … Continue reading
In our previous post, we have learned the distribution of vehicle preparation time via the visual representation known as the histogram. This does not tell us what causes for the distribution. If we wish to alter this distribution, we will also need to know the causes and take some action to alter. Enter the Ishikawa diagram, also known the fishbone diagram, or cause and effect diagram.
The Ishikawa diagram is a tool that facilitates a collection of potential causes for the variation we are seeing. Brainstorming on its own can be a bit chaotic. We may have ideas flying in from all participants with little rhyme or reasons, and occasionally the ideas connecting.
We will brainstorm to generate the causes of the effect that we are witnessing. In this case we want to answer the question:
Why does vehicle preparation time take so long?
Our first step is to identify those variables that influence our vehicle preparation … Continue reading
The customer is the receiver of the output; the customer can be an internal end customer or an intermediary to the next “chain” of events on the way to the final customer. Ultimately, we are aligning our actions (Suppliers, Inputs, Processes, and Outputs) in a way that provides the biggest benefits for our final customer. The presumption is that satisfying the intermediary customers will improve the probability of ultimately satisfying the final customer’s needs. This stands up to logic. Imagine deliveries to the transitional organization that are such that the organization cannot use. For example, imagine our systems specifications were not written good enough so as to allow for the generation of the software specifications. We now are at risk of delivering something totally errant, or revisit and deliver the specifications yet again. This amounts to a waste of time, talent and resources.
Using SIPOC as a process review, critique or simply uncovering how you work makes it possible to … Continue reading
by Kim H Pries
When we are engaged in prototype development during the early to late middle phases of our new product delivery process, we usually purchase components through maintenance, repairs, and operation (MRO) purchasing. This type of purchasing is managed on an as-needed basis, and often, is not automated. We purchase the parts we need in relatively small quantities because we are not yet in production. At this point in our process, this approach is reasonable and effective. The part cost is high but we are not at risk of having any parts we need to throw away.
As we move through the process, however, we reach a point where we begin to transition from prototypes to sellable products. For these products, we most commonly use manufacturing resource planning (MRP) purchasing, which is nearly always automated. As developers, we have seen huge discontinuities in delivery when shifting from MRO to MRP purchasing. MRP purchasing has some different characteristics:
• … Continue reading
The sooner you move away from project management activities based upon hope, the sooner your organization makes a recovery to the efficient enterprise you desire.
I have noticed a rash of project schedules wherein each task lays end to end as if the prediction of the; task start, progress, and completion times are known without question. When asked how the project team arrives at the schedule, invariably the tasks must fit like this to make the delivery date. Asking what information they have to support the duration estimates, for example, historical record, no one can provide any such information. This method of project management delays disappointment and ultimately is not a recipe for continued success.
Use what you learn as you execute the individual activities within the project. Learn of the possible duration from the previous work history. If you do not have the history because this is a new activity there are other solutions to the “fixed date debacle” … Continue reading