I have been very fortunate in my career, and that really means very lucky. Upon graduating from the University of North Carolina at Charlotte, I had two job offers after sending my resume to more than 100 companies. That is not a very good yield, but it would be good enough. I selected the smaller company, but I selected that company because they created new things. The company I started at developed embedded industrial control systems. It also turns out the people with which I would be fortunate enough to work, were very friendly, and as I would say, were a hoot to be around. Some of my other blog posts describes shenanigans. To this day we still have secret words, that mean something to us but nothing to anybody else (R4).
What drives me
My interest or objective has never been one thing when it comes to product development. In the beginning, I was interested … Continue reading
Models are not new, and neither models in the employ of product development. Product development has always had some basis in discovery and always will. If everything had such a high degree of certainty, likely the product or endeavor has already been done. Developing new things ceaselessly brings questions. To be effective, we want to answer these questions as quickly and as certainly as possible. Continue reading
We have our requirements, our iterative packages and content defined, and now the developers are producing the iterations. During this time, the verification and test folks have been creating the test cases or details on how we intend to confirm the product performance.
Our requirements provide the fodder for our testing. For each requirement there must be a way to confirm that requirement has been delivered, fulfilled or otherwise met. Confirmation the need is satiated is also part of the project closing activities. We do not counsel testing only to the requirements, however this blog series is on requirements and we want to show the link between the requirements and product verification. How else will are you to know the product meets the desired outcome? These test cases should be traced all the way back to the project scope via the product requirements (see the table below).
Scope Systems Requirement Component Requirement Test Case Prod_Req_1.1 Systems_Req_1.1 Req_ECU1_1.1 TC_ECU1_1.1 Systems Req. … Continue reading
There is a saying: “if you change form, fit or function, you change the part number.” On the surface this seems like a good saying. People use this saying as rule of thumb to determine if a new part number is required. Taking out new part numbers cost the company some administrative time and effort (also known as “money”), and it can be good to eliminate that burden. However there is more to this than the typical form, fit or function evaluation method.
Some companies use part numbers to track the quality of the product. In fact, many or most do. They monitor the parts returned by part numbers for signs that their quality is eroding. Not changing part numbers makes distinguishing the failure and cause or even an improvement in quality and cause difficult. For example, perhaps we make a small change to our manufacturing process. This change has no implication on form fit or function of the product. … Continue reading
Configuration control is generally, what first comes to mind when somebody brings up the topic of configuration management (CM). While it lies at the heart of the system, all the components of a CM system are critical. The purpose of this component is to:
Maintain and control configuration baselines (known and defined states) Document and control change and variance Limit approved changes to those which are either required or offer important benefits Ensure the variances lie within defined boundaries Include the customer Control product interfaces (interface control document) Verifying that change proposals manage the effect of the change Control cascading changes Control coordinated changes (multiples happening simultaneously) Only approved product are affected
The key word is clearly “control.” In most cases, we will automate the process to allow computer software to help us control these changes, although we have seen usable low-technology CM systems that worked fine for small organizations. In general, we will follow a pattern:
Identify the need … Continue reading
One of the principal roles of configuration management (CM) is to protect us from ourselves. In so doing, we also protect our suppliers and our customers. When high school or college students first encounter bills of materials, they experience shock and awe. An automotive wire harness with 368 leads must have a bill of materials with at least 368 components (some will be common, but we must still account for their presence), associated connectors, solder, anti-fretting compound, and so on. Every possible component falls under CM.
When we don’t practice good CM, we end up in situations where we ship products to a customer without knowing what we are shipping. At every given slice in time, we have a configuration, parts of which we decide to control. Some items that are truly CM are:
Raw material inventory Material released to the floor Production equipment Development equipment Support equipment Utility pipes, wires, etc. Labels Colors Paint Plastic Packaging Drawings Records of … Continue reading
by Jon M Quigley and Wally Stegall
This post is a flashback to the earlier series about prototypes (http://www.valuetransform.com/planning-prototype-parts). A recent event reminded me of one other area we did not cover in this series. Such is the way of the blog.
Consider the organization that decides to limit the number of prototype parts to be used for the assorted verification activities as a cost saving measure. This is not a bad idea, however, there is merit in the saying “penny wise and pound foolish” and hence this blog post. If you take the above approach, it is prudent to address the risks associated.
An organization is working a development project with limited attention and control to the prototype handling and testing. They start the prototype test with a harsh Bulk Current Injection stimulus. Upon conclusion of one of the test, we find the product is no longer functional. Thus the start of the testing of … Continue reading
by Kim H. Pries
Some people find terms such as configuration management and change management to be confusing and they are unsure what they mean and what the difference could be. We consider change management to be a higher order concept that includes the idea of configuration management. Let’s discuss configuration management first!
Classical configuration management in the mode of the U.S. Department of Defense breaks down into configuration identification, configuration control, configuration status accounting, and configuration auditing. Configuration identification occurs when we specify a product or component sufficiently that can be distinguished from other parts and components; we also usually use a well-specified nomenclature to avoid confusion. Configuration control occurs when we can modify what we have identified in a rational way (change of part number, change of nomenclature, change of drawings) such that we always know what we have. With hardware, configuration identification and control will also include labeling the product to avoid improper installation or ignorant deployment. … 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
by Jon M Quigley
Simulation activities can help evoke the requirements for a product without actually having to build the product first to learn something. Simulation need not be highly technical, though it can be. I have seen simulation of screens for an instrument cluster human machine interface (HMI) that made use of excel links to illustrate the appearance and show how the navigation worked. This was a cheap and quick way of learning how the product should work. There are more complicated ways, however, that typically employ sophisticated software and hardware. We can develop complex systems of components to simulate our product. We can use these tools to develop our requirements by testing our concepts before we build the prototype parts. We can refine our algorithms by exercising the subassembly within the context of a simulated system. We will need to confirm our models for the simulation, in fact represent the real world stimuli expected. To do that we … Continue reading