To reduce the chances of going too far down the wrong road, we qualify our projects with some sort of business analysis, for example internal rate of return or return on investment or some other fiduciary measurement.  If we are working from a staged-gate project management system, we will relentlessly review our project condition against […]

Not all risks are associated with technology, processes, or missing resources.    Sometimes an individual assigned to your project can be the riskiest aspect of your entire project.  Technology and processes are predictable by their very nature.  And finding resources may be difficult, but the lead-time and process are well understood.  But humans are, in the […]

To highlight one more time how we often do ourselves more harm than good, we will have one more short case of how we can make an already risky situation even worse. Consider the vehicle manufacturer that is working a project to meet a new and more stringent pollution emissions regulatory target from the government.  […]

There are a number of quality tools that can help to evoke the risks that may be associated with your project. One such tool usually associated with cause and effect is the Ishikawa diagram. We can use this tool to explore risks as well. We will explore what happens (cause) and how it will impact […]

A contingency in project management is a reaction plan to an untoward event; in short, we plan ahead for the failure of a given task. In order for a trigger to “fire,” we must set a threshold value that activates the trigger; otherwise, the trigger should never fire. Thresholds can be set based on financial, […]

Many organizations have a series of activities or processes (design reviews, analyses, verifications, validations, etc.) that they go through to produce the end product or service. The work will start with some kind of development process, which may be a matter of days, months or years, depending on the complexity of the product or service. […]

Another piece of the configuration management pie is the ability to move backward and forward from revision to revision. To demonstrate the importance of this concept I will relate a story. There once was a developer who was writing in assembly language for a new product.  He was incrementally developing the features for the product […]

We take a time out from the configuration management discussion. We see in the news numerous companies with field quality problems and we cannot help but think of the discussions we have had with colleagues about how many organizations handle their product testing. Testing, done right, is a lead indicator of product quality. It is […]

We have seen situations where poor configuration management has led to embarrassing situations with customers. In one case, a supplier shipped parts to a relatively new customer in which neither the hardware revision nor the software version were known. The parts arrived at the customer location for demonstration by a senior sales manager–none of them […]

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 […]