Archive for November, 2012

Organization and Commitment

Posted on: November 20th, 2012 by admin No Comments

By Jon M Quigley

In our previous blog post, we discussed PPAP and objectivity or the check the box mentality. What happens when we communicate in an overly optimistic way?  Below is an exchange between a supplier project management as well as the customer project management and a line manager responsible for verification.

Chief Project Manager Supplier: you must be completed with your integration testing no later than 2 weeks

Verification Line Manager at the Customer:   There are more than 3000 systems level test cases, none of which are automated.  This is not a two week test but probably more like 4-6 weeks

Verification Line Manager at the Customer:    There is no way the testing is going to happen in the two week desired, too few people and resources for that to happen at this late of a request date. We will likely be through 10% in that time.

Chief Project Manager Supplier:    I insist that your testing can and must be completed no later than 2 weeks. That way we can deliver the product to the field test personnel.

Verification Line Manager at the Customer:       There is no way the testing is going to happen in the two week desired. It is not likely this can happen in that time.

Chief Project Manager Customer:        We will do our best to meet your two week deadline

The meeting disbands.  The line manager walks away thinking the rest of the organization wants and believes the testing will be completed in 2 weeks. Two weeks come and go, and the testing is not completed. The testing goes on to take 6 weeks.  Now, this same organization laments that keeping their scheduled commitments is very difficult.  In this exchange, perhaps we see some clue as to why that may be the case.

Project management discipline includes expectation management.  The project manager is one conduit for resolving communications difficulties and keeps the team pushing in the same direction.  This includes understand the expectations upon each team member (performed one way via a Resource Allocation Matrix).  This identifies who owns what part of the project and the authorities and responsibilities in their area.  So why is this important? Well the CPM at the supplier has made a demand and the exchange above could suggest that they could in fact expect the verification activities concluded in the time he demanded, though the verification group manager asserts this to not be possible.  We have prepared this CPM for the news that we have achieved the goal of completing the systems verification by the date he desires….and we have professional experience and area of responsible person indicating that is not possible.

In discussions with other project managers, they confided that the above exchange was an easy way to diffuse the situation.  A promise of doing our best did not accept (or exclude) the possibility of meeting the demanded duration from the supplier. As such, the stress or confrontation was averted. That may be true, on the other hand, it could easily be construed that the CPM at the supplier interpreted this exchange as we had in fact accepted the challenge. Imagine their surprise two weeks later, when the activities were not completed. We have failed to meet our commitment.

Is it better to avoid “conflict” than to explicitly indicate or state the facts?  It sure looks like we averted the confrontation, but at what cost. In hindsight, the line manager had a good understanding of the work and the amount of time it would take to accomplish the job, and it was not the duration that the CPM at the supplier had wished.  We averted any escalation to meet the un-meet-able, but in an organization that professes to have a problem with commitment and delivery; one can only wonder how much of that problem is self-inflicted. Accepting such a diffusion approach as necessary rather than rock the boat with facts, professional responsibility and experienced perspective set the level of expectation that we are very confident we will not reach.

Is it better to delay the “bad news” day?  At some point, in this case two weeks later, we will hear from the CPM at the supplier.  What happens when we fail to meet the target of two weeks? Is it really a target?  Is it really a failure to deliver and is this a source of a reputation of inability to deliver?

Truth or Obfuscation

Posted on: November 18th, 2012 by admin 3 Comments

by: Jon M Quigley and Wally Stegall
In the last blog post, we discussed how PPAP should be the quality system, although it is not in many cases.  One reason PPAP drops off the map after the start of production, it may have never been a concern during the design is the check box mentality.  Check box mentality can be an indicator of calcification of process and lack of passion. This check box mentality is independent of quality system, and difficult to say the reason. A few that come to mind are:

  • Lack of competence or insufficient detail regarding the activity objective
  • Self-preservation (I don’t want to look bad)
  • Overly optimistic
  • Political (my boss does not want to look bad)
  • Lack of focus on the details (time and passion issue as opposed to competence)

Too often, the process becomes more important than the program.  Check the box.  Ship it if it works or not – or do not even look.  Check the box.  Approve it or ignore it but check the box.  Cut and paste a technical report.  Check the box. The check box becomes the all-important metric.  Perhaps we are dealing with a competency issue.  The check box is the product.  Sometimes we have people checking these boxes with insufficient knowledge of the objective of the box, what constitutes success. For example, we had a design review, with two people, no advanced review of the document, 150 pages in 10 minutes. Check the box.

Sometimes it is not about passion or knowledge.  The check box mentality creeps in when we are more interested in not looking bad.  Do not look to closely, just check the box.  It can be difficult to tell if this is the desire not to look bad, or if this is the result of rampant or unwarranted optimism.  We have been in meetings where we see green smiley faces for critical development activities that we know are not in a great or even good state. We sat across from another manager as the project manager painted a pretty picture of project.  Sometimes it is not an employee with this optimism. We have seen management and even executives that seem to hold the truth (or objectivity) of little value, only exacerbating the problem.

PPAP and other process are necessary for manufacturing and design discipline but an organization/people must be flexible and agile in applying physics, technology, and logic to the rigorous processes.  We believe the ability to be both strong and adaptable with a process comes from passion for the product, and knowing the rules of product development. When one of us was a metal bass player in the olden days, we was struck be an artist (Billy Sheehan) that said you must know the rules and understand the consequences before you break the rules.  I think the same true for effective product development and processes.

Top-level management has a responsibility here. The management that values “to seem rather than to be” promotes this culture of obfuscation, self-preservation or contrived optimism.  The culture that will be, as one vice-president put it, “like a cancer for the organization”.  If the management does not see the value in training programs, and make sure there are non-billable hours to account for this training, they are indeed responsible for the results.  If there is insufficient stomach for the objective truth, the organization will never be much better than mediocre.

At the end of the day, you need excited objective people.  The dry dead check box mentality is not an organization that has a long future but relies on luck or will be in business in spite of itself.   Leaders and managers must allow and bring out the passion of employees to wield processes like PPAP dynamically and professionally.

Single Sign On provided by vBSSO