Archive for May, 2015

Value Transformation Training Areas

Posted on: May 26th, 2015 by admin No Comments

 

Value Transformation training areas from cradle to grave, a product and project management. We offer training and consulting on the many challenges that come with developing products and complex systems.

 

Poka Yoke Revisited

Posted on: May 15th, 2015 by admin No Comments

We continue the exploration of the Poka Yoke post.  In the last post we discovered in building the product (late iteration) we have found that building the product has some undue complexity.  Upon further exploration we find that the design engineers suggested spending some time to Poka Yoke these devices.  The project hierarchy decided to not spend the time and money.  So…….

Now it has become apparent that building this product in customer volumes, in a manufacturing facility with strict time constraints to build and revulsion of rework required some alteration.  It is too late to “add” this scope to the project, so instead, another project is spawned to adjust the design to address this easy to build incorrect concern.  This subsequent project will not be available at the start of production.

How is this solution better than addressing the issue in the original project?  There will likely be miss builds of the product that will require dis-assembly to fix, just as this early system  required.  It should not be that we must see the failure –some of these things are able to be predicted? In this case it was.  Proof of failure is not always the best way to approach these problems. Perhaps we should thoughtfully consider the risks and take appropriate actions.  

In this case we did not have time to do it right, but we had time to do it twice.

 

The PMO and Project Culture

Posted on: May 14th, 2015 by admin No Comments

file000162678218

I would like thank the Chapter Meeting of PMI Southwest Virginia for allowing me to present, the event was fun, the interaction and engagement (and the meal) were well worth the 5 hour drive.

20150512_173439

I have been thinking on the interactions from the presentation and I feel compelled to writing something that I think will help sum it up and perhaps be helpful.  While the event was from the trench perspective, it was clear that many of the concerns we discussed went far beyond the front lines or the project manager.  Though the topic was more on individual project tactics, ground work for the project manager; the audience pointed out many aspects that are greatly influenced by the PMO, since this entity establishes the operating environment.  For example, one question posed was on early estimates in a stage gate project organization.  Early estimates are uncertain, often the scope is uncertain – and therefore the cost of the project is uncertain, for example.  One of the reasons for a stage gate is to review back and project forward based upon what we have learned in the last phase.  This learning will impact our original estimates and typically each of the subsequent gates provides a further refinement of the cost estimates.  At some point (gate) we should expect a final estimate to be generated defining the amount for the entire project.  This type of asymptotically approach to the cost of the project is the sort of defined expectation and operating methods set by the PMO and upper level management.

If these structures, rules or guidelines are incomplete or poorly done (or does not exist), the subsequent or detailed work, not matter how hard and smart the project manager and team work, will be subjected to the risks associated with this undefined or poorly defined operating method.  That seemed to be a recurring theme in the discourse, not only for estimates, but the schedule as well, and my guess is more than that which was articulated by the group.  These rules or guidelines are part of establishing the corporate culture and the PMO must set the tone for the management of projects.  This includes tool uses, attitudes about trade-offs (for example cost and quality).

Poka Yoke

Posted on: May 12th, 2015 by admin 1 Comment

There is nothing like a real life story for demonstration.  This is a true story on product design, and a technique called Poka Yoke. In this case, the product is a complicated set of vehicle systems.  There are a number of pressure sensing elements, all the same type of sensor and distributed in a relatively common space.  Each of these sensors is connected electrically to other parts of the system and enables certain sets of features.  The wires are connected to each of these sensors discretely, that is, there are separate connectors and wires going to each of these sensors.

During the prototype development the entirety of the system is produced. The numerous subsystems are put together to make the functioning end product.  This system entirety will then be tested to assess the capability of the design. In the late phases of the project and product, these prototypes builds transition from engineering related to more manufacturing skills.  It is during this transfer that problems in the assembly are witnessed.  We have malfunctions on one of the end products that require engineers to investigate the cause of the problem.  This required numerous engineers of both pneumatic and electrical disciplines to find the source of the problem.  Waste of time and talent.

It turns out that each of the sensors did unique things in the system; all were similar looking and performed a similar but different function.  The pressure transducers convert pneumatic pressure to an electronic signal. This signal was routed to a variety of control units to make decisions based the state. These different functions required the connecting wires to be routed or connected to specific locations. There are six of these sensors, each with a discrete connector, and all six of the electrical connections likewise look alike.  To make the situation even more difficult, all of these sensors reside in a common area. It is very easy to put any of the electrical connections to any of the sensors.

Poka Yoke is often referred to as goof proofing but really means error proofing.  This technique is part of building in quality of the product and reduces inspection time and time to troubleshoot what should never have been a problem.  In this specific case, the sensors common appearance, the connection point common appearance made it easy to connect the incorrect wires to any of the given sensors.  The problem was found in a small build,  the system was not yet at full factory production, and that was fortunate. However, to find the root cause of why the system performed erratically required engineers climbing on the vehicle and disassembling various panels and parts to to determine the problem, and amounted to a waste of time and talent.

There are a number of ways this problem could have been avoided, for example, the sensors could have been color coded with corresponding color code applied to the connectors providing a readily visible correlation between the sensor and the connecting wires.  The connectors could have been “keyed” to only allow the appropriate harness to connect to the appropriate sensor.  We will not go into an exhaustive list of ways the accomplish (contact Value Transformation if you need help in this regard.  This sort of issue should have been identified in the Design for Manufacturing and Assembly (DFMA).  Doing this up front and deliberately can reduce these inefficiencies and time consuming activities that add no value.

 

When Projects get Stalled..

Posted on: May 7th, 2015 by admin No Comments

I have witnessed a recurring theme in projects that causes me to recall a scene from the 1970 movie Patton, with George C Scott.

As this scene is depicted in the movie, Patton becomes enraged upon discovering that a column of American troops, tanks, and vehicles has been held up and exposed to enemy fire because two mules hitched to an Italian peddler’s cart are blocking a narrow bridge. The bellicose general angrily turns on the soldiers who have been trying, ineffectively, to pull the stubborn animals off the bridge, shouting at them: “Jackasses? You let a whole column get stalled and strafed on account of a couple of jackasses?  What the hell’s the matter with you?” [1]

So how can this possibly remind me of any project problem?  Simple, in the event above, the troops and material are subjected to risk and injury while the obstacle, the mules, remain to be convinced to leave the bridge.

Obstacle

Obstacle

In project management the same event occurs, though the stakes are not so high.  In your experience, how many times has a project decision or resolution of a conflict languished, consuming precious project time?  If your answer is this seldom happens our experiences are very dissimilar.  While the marketing people delay providing direction on the scope or objectives of the project, the clock is ticking.  If your schedule or methods of working do not account for this, your project schedule can be severely impacted.  This is especially true for fixed date delivery projects such as meeting a legal requirement.  Some examples are:

  • Marketing / product planning input late or insufficient
  • Design or system alternatives not resolved quickly
  • Specifications late or missing
  • Design work extends well past expected delivery date
  • Many more

These conflicts and indecision often come to roost for the test and verification work as short cuts, reduction of scope of what should be tested, or teams working long, uncompensated hours and sometimes over the holidays (for example vehicle emissions compliance often if not always starts in January).

Understand how the parts are connected. It is possible to work with less than perfect information to allow for some progress, however you need to know the consequences of such a course of action.  If the fundamentals are missing escalate until these are resolved. The last thing you can afford, is to have your project held up, making no progress while the clock is ticking.

Deviations versus Change Requests

Posted on: May 4th, 2015 by admin No Comments

by Jon M Quigley and Kim L. Robertson

Change Management Recall

In our previous blog, we discussed the differences of waivers, deviations and engineering change requests in the context of Configuration Management.  We were in the midst of a project that had just released requirements to a supplier to build prototype parts.  The prototypes will take 8-10 weeks to manufacture. During fabrication the customer is modifying the requirements.

Deviation as a Decided Course of Action

The customer decides  to use deviations to address changes that happen while a prototype part is being developed. The deviation does not originate from the supplier. The change to requirements is permanent.  The manufactured prototype may or may not have all of the deviations.  Additionally, there is no mechanism for approval of the change or formally updating specifications and drawings. This violates change management one of the key principles of configuration management.

The customer should have issued a directed change to the supplier with a request for proposal and negotiated the cost and scope impact after the fact rather than using a deviation.  This change mechanism will also ensure the required design documentation are also updated.

Subscribe to our Newsletter

Subscribe to our Newsletter
Name
Email *
Single Sign On provided by vBSSO