Archive for January, 2014

We would like to revisit our blog post May 2013 and tell the complete story over the course of a few blogs. I realized the importance of showing the use of the variety of tools after giving an ITMPI webinar based upon our book Total Quality Management for Project Management. At the end of the demonstration of the variety of techniques, I was asked how to apply them. I realized then, that I had failed. So to try to improve that failure, I will use the next few blogs to demonstrate how the TQM tools can be used explore and address a specific problem.

The area we chose to explore was around our verification activities. This company is a vehicle design and manufacturer. The vehicle system integration and verification activities take longer than they would like. Anecdotal evidence suggests preparation time to be considerable. The management digs through the historical record, new projects the metric of vehicle preparation time is identified and added to the verification group’s list of metrics.

Now let us discuss the histogram is some detail. The histogram is a graphical representation of a data distribution. We breakdown the range of the distribution into discrete non-overlapping segments (bins) to which we will tabulate the number of incidents falling within that range or bin. The first things we need to calculate – the number of bins needed. We can start by counting the number of data points we have and take the square root of that number and round up to a whole number. That is a good estimate for the Number_of_Bins that will be required.

Next, we want to know the range for the bins to cover. To calculate the range:

Range_of_Value = Maximum Value – Minimum Value

Now we need to know the width of each of these bins. The width for each bin, is calculated by dividing the Range_of_Value by the Number_of_Bins. Now we have discrete segments that will ultimately total our range of possibilities. We then populate each bin with the number of occurrences for that bin, ultimately giving us a visual representation of the distribution.

Vehicle Preparation Time for Systems Testing

We learn a little from this exercise. We know that we should not expect testing to start on day one or day two of the vehicle availability. In fact, we must consider that we may not be able to start the testing for up to 16 days after the arrival of the test vehicle. Anything shorter than the longest time shown in the graphic above (16 days) may mean our test schedule is impacted.

Sometimes it is difficult to speak up when you know you have problems. Not many people want to be the person who is perceived as holding up progress, probably a self-preservation mechanism. However, when it comes to project work and teamwork, we can ill afford to play such games. Enter the game I call “product development chicken”. Since this phenomenon is not likely restricted to product development, though that is where I see the ubiquitous application, perhaps a better name would be project management chicken.

I noticed this affliction years ago when I worked as a tier one supplier to the automotive industry. I will confess right here, I do not play this game. I have never been one to believe in hiding but actively pursue uncovering the facts. Actually, I err on the side of disclosure quickly even when we may not know if we are really at risk. However, the game works like this. The project is underway, working with multiple entities. Each part of the team has their own set of deliveries, risks and challenges. These may even all be cataloged in a risk register, though often it is not. As the project progresses, our team constituents may notice some risks coming to fruition that will likely affect the project achieving the objective. For example, we may start to suspect that we will not meet our specific delivery date. Rather than articulate this to the project quickly, promptly – where we can manage expectations or devise action taken to reduce the likelihood of being late, the team member hides the problem. They hide the problem, waiting for somebody else’s risks to come to fruition. Once the project is late or over cost and in the midst of a “firefight”, their issue becomes less of a concern. The project never marks or notices them. Upon somebody else’s trauma coming to the fore, they breathe a sigh of relief. Then they quickly and quietly set about cleaning up their area of trauma in the hope of having the situation resolved before the solution to the present problem.

So why do I call this product development chicken? It is like the bicycle game (or as my brother and I used to do on motorcycles) where nobody wants to change the heading until they absolutely must, and somebody will likely have to “fess up” to a problem. This may make you feel better, but it does not help the project to achieve the end results desired. We can solve these types of issues with well defined metrics, constant follow up, and a good communications plan.