Archive for June, 2014

Concurrent Engineering

Posted on: June 28th, 2014 by admin 3 Comments

What is concurrent engineering?

Concurrent engineering is when activities are paralleled that could be sequenced. Concurrent engineering can help us deliver the product earlier since we have compressed the schedule by overlapping the various development activities.  There are certain risks associated with this way of working. To be successful and not incur massive rework, it is necessary to keep the entire team in step, essentially plenty of communicating and synchronizing the design direction. This requires constant attention to the design interactions and dependencies, specifically, the links between the design areas.  For example, if we are developing a new vehicle, we will need to coordinate the structural, hydraulic and pneumatic, as well as the electrical design.  Continuous reviews and a well-defined configuration and change management process can help to keep the team in step.

Concurrent Engineering Failures

There can be a down side to concurrent engineering.  Done poorly, there will be an abundance of rework.  We “detect” problems when the physical parts come together in a bundle of parts that cannot be assembled.  We do not help our situation any when we have a variety tools for each of these areas. For example, consider a company that uses Pro E for some of the CAD work, and Catia for other design elements. Sharing of the various digital models that will eventually comprise the system is necessary. The ability to view shared digital mock ups (DMU) ensures we are constantly aware of the design direction.  We know the other system elements design state. This is a key component to successful design.  Additionally, the construction of models in one tool will make the assembling of those modules into the final product will in advance of the construction of the system via prototype parts. This is one of the key benefits of building DMU of the system to provide a virtual construct of the product.  A design that fits together in CAD may be a design that will work in reality.  With this disjointed or inconsistent use of tools, building a virtual representation of the product will not be possible or will require human manipulation which will consume time and adds an opportunity for a mistake to creep into the design.

Concurrent Engineering Summary

Concurrent engineering is not as easy as it may sound.  To be sure, if you proceed with a measure of diligence, sharing of the design data and good communication, we can be successful. If we are unwilling to take this approach, expect concurrent engineering to produce rework, and waste – and only occasionally successful.

Project Scheduling

Posted on: June 27th, 2014 by admin 1 Comment

Project Schedule

I have been thinking on project scheduling since invitation to speak at a Wake Forest MBA class.  Schedule management is much more than Microsoft Project, though an appropriate tool can help the project manager and the team to visualize how the project activities map to success, however, we must have performed sufficient diligence.  Putting poor information into a suitable tool will probably produce poor results.

Oops, I missed it again

Projects are not production.  On the other hand, there is often a recurring theme or methodology associated with industry and event specific company.  Automotive projects are managed a particular way, as are embedded product projects. Our organization may have functional areas that are responsible for specific aspects of the project (such as a verification group).  Perhaps our organizational structure is by product or project (all discipline areas included in one group).  In either event, we should know the primary steps that are typical in our work even while we explore variations due to the project scope peculiarities.  Learn this rhythm. We start learning this rhythm by performing a decomposition of the objectives to specific tasks and that is the Work Breakdown Structure. We then link that to areas of responsibility.  Recycling what is common can help us avoid missing steps, however recycling without thinking, may mean repeating the previous project problems.


Part of understanding the rhythm is knowledge of the interdependencies of the machinations of the project.  Whether you are a project manager or a person working within a project, fundamentals of project management are necessary for project success. We offer a class we call Working within a Project. This class is directed at facilitating understand of the interconnectedness of the individuals with their areas of responsibility for achieving the project objectives.  Ultimately, the parts must metaphorically fit together while everything is moving to achieve the successful end of the project.

Problem with Pragmatic

Posted on: June 20th, 2014 by admin 1 Comment

Recently, on twitter, I had an occasion to express my discontent for the word Pragmatic.  My spontaneous outburst so amazed me that I decided to explore this further.  The definition on[1] is:

  1. Of or pertaining to a practical point of view or practical considerations
  2. Philosophy of or pertaining to pragmatism
  3. Of or pertaining to pragmatics
  4. Treating historical phenomena with special reference to their causes, antecedent conditions, and results
  5. Of or pertaining to the affairs of state or community

For me the definitions of interest are numbers 1 and 4.  Practical consideration as it pertains specifically to project management and product development.  Too often this seems to be an excuse for our altering what should happen to what can be made to happen.  My experience suggests often the “what can be made to happen” is entirely inadequate or as my dad used to say “half-assed”.  Observation suggests this is one of the reasons for poor product quality.  In the name of pragmatism, we justify taking actions that are reckless and irresponsible.

As a specific example, imagine the development of a product to a fixed delivery date.  That development work has taken longer than expected; the downstream work will be impacted (dependencies).  For whatever reason, our launch date remains the same.  To say our next set of work (perhaps testing) will delay the launch is unacceptable.  Whip out our pragmatic crowbar “do what you can in the few hours you have”, no matter how ridiculous the miss match of time available to scope of work may be.  I have witnessed this specific testing implication on numerous occasions, and most of you test folks can likewise attest to that.

If the historical record indicates this sort of situation happens frequently, would it not be prudent and pragmatic to plan our response differently?  For example, knowing the above situation happens frequently, that test phase activities are routinely crunched in favor of the launch, our plan should identify actions early enough in the development work to alter the outcome.  For example, choose some metric that allows us the possibility to prognosticate the probable completion date of the prior items in our dependency chain.  Knowing the gap between our desired or wished date and probable date will permit us to adjust our project scope or schedule accordingly.  Once it looks like that date is compromised, we reduce the scope of the development work, or add resources (last resort) to ensure we make the date of delivery to the downstream dependency.  A second pragmatic solution could be to integrate our testing with our development throughout the development process.  Small builds, constantly or continuously tested iterations allows us to accomplish both the development and testing objectives, thus giving our team a fighting chance to successfully deliver a quality product.

Consider the situation in which our organization does not have a comprehensive approach to configuration management. We can interject into our project management planning and activities to mitigate or reduce the risk.

Generally, these pragmatic solutions are not attempted.  Rather, we use the battering ram “you are not being pragmatic” and trash any rational approach as “being by the book” as if a text book execution is synonymous with mythical or inadequate. In football, by way of comparison, text book execution is usually referred to in a positive light.

My disagreement with the word was perhaps a mistake. My real disagreement is the word’s use in coercion or as doublespeak (political speak, management spin etc.).  I call it coercion because in the sense we are accepting that which probably should not be accepted – a remedial and reckless solution, and as such you are not being a “team player”.

I agree with this definition practical considerations are necessary as aspiring to the ideal is difficult and often seemingly not possible.  I do not believe the word pragmatic describes the earlier mentioned reckless and irresponsible behavior – though the word is frequently used in that context.

Test Cases

Posted on: June 11th, 2014 by admin 1 Comment

Test cases in and of themselves may not be the most important thing when it comes to testing.  However, neither is test case and requirements test coverage a trivial or inconsequential aspect of product quality. In earlier posts we discussed a multiple perspective approach to product testing and that included exploratory testing, combinatorial testing and stress testing.  Test cases are often associated with the product requirements.  The execution of those test cases confirms or refutes the achieving of those requirements.  From a project management perspective, it is arguable that the execution of these test cases fills the role of scope confirmation which is part of the closing activities for the project.  Not that this testing necessarily happens only at project closure (testing should be all along the development path in incremental builds) or solely used for project closure.

Test coverage as a percentage of the total test cases is only a part of the story.  Since this may only include the requirements testing (not the exploratory or the stress tests) defining test coverage total as just the tests conducted toward requirements is inaccurate. However, what can be an interesting metric is the percentage of test cases conducted compared to the number and severity of the faults found.  For example, let us say that we are 30% through our test cases.  Let us also say in that testing we found 10 failures of a moderate severity and 6 catastrophic failures. What we can extrapolate from that, is that our product is not fit for production and there are likely a few more failures perhaps twice as many as we presently see or even more.

We track the test case rate of execution and over lay that with the rate of problems found.

We track the test case rate of execution and over lay that with the rate of problems found.

As test cases are typically mapped to product documented specifications, the test case coverage is part of our project closure activities, specifically, the contract closure.  Contract closure requires confirmation that the customer’s contractual expectations are met. We demonstrate that we have fulfilled our contractual obligations by knowing the test case coverage and the passing or failing of those test cases.  Those areas we do not have test cases mapped, we will take other actions to ensure we have met the contract requirements (reviews and evaluations).

Percent coverage of test cases is not as helpful by itself as it often excludes the exploratory and combinatorial testing volume. However, testing percent coverage, number of faults, arrival rate and severity of defect is more than a little bit of a clue as to what the remaining product quality may be.  The use of test cases (juxtaposed) to requirements is not only necessary for the product development engineers but for the project management discipline as well. This information about conformance or congruence with the project scope is necessary. It will be part of the assuring we meet the quality targets for the product / project as well as serving as proof of delivery for contract closure.

3D Printing – Recovery of Heritage Design via CM

Posted on: June 10th, 2014 by admin 1 Comment

By Kim Robertson and Jon M. Quigley

Leveraged Innovation Logistics

Mike and Akio had been invited to one of the Genesis Test Equipment logistic repair depot by Lina Hendrik, the facility manager to discuss an idea she had regarding retrofit of a discontinued product line still widely used in an automotive niche market segment.

As they walked to the back storage bay she began discussing the situation.

“We are still providing logistics support to over 1,900 fielded units. These cycle through the depot about 150 units per month for recalibration and upgrade to the last design  improvement we made which was some 10 years ago. Most of the units are now with their third or fourth owner. These are generally small specialty repair and diagnostic shops catering to owners of European cars from the 60’s through the 90’s.


We are seeing some interesting metal fatigue in the same supports and bell housings throughout the product line in addition to the normal logistics issues of hard use and ageing electronics.”

Mike was silent for a moment, “Didn’t we do one last production run of housings and brackets for stock before ending our official support of the product about 18 months ago?”

“Yes, that’s right. We did a short run of 300 units but have very few of the items remaining in stock and still have a very high demand for depot level support. It really isn’t profitable for Genesis but we have met the demand despite diminished margins. My team has been kicking this problem around for about a month and we think we have an idea and direction that will still provide the support the current GDG 1500 series owners need while encouraging leveraged innovation with a Genesis funded start-up. I’ll let Lonzo explain what we have in mind. I think you’ll like it.”

They entered the area conference room and after looking at examples of the fatigued parts, the short meeting began.

“I believe that with a slight redesign of the housing and a new set of electronics a steady bread and butter type revenue stream exists for at least another 10 years on the GDG 1500 series. We suggest an outsourcing of logistics support to another firm. This focuses Genesis on our new technologies but retains the good will of the market segment.

Mike nodded, “So instead of planned obsolesce we facilitate planned transitional support.”

That’s correct,” Lonzo replied. “I’ve run the numbers based on the electronic design recommendations we just made assuming we would have to reverse engineer our own mechanical designs for the brackets and housing.”

Akio’s eyebrows shot up, “Reverse engineer?”

Lina chimed in, “Unfortunately that is correct. Before turning the records retention function over to configuration management Genesis facilities made an uninformed decision to dispose of all engineering three years after end of product manufacture. Facilities convinced IT that the electronic CAD files should be purged as well. We’ve had engineering looking at our remote sites and we have nothing on file. All of this was prior to our starting up our PLM system.”

Akio stepped out of the meeting to make a few calls. He returned to the meeting, his normally expressive face was wearing an expression seldom seen. It was almost radiant.

He announced. “Mike, I think this is just the project we have been looking for to prove out our thoughts on additive manufacturing! I’ve set up a meeting with a friend of mine for Monday. Let’s see what he can do with 3D scanning.”

Human Heritage

Jason gave three quick raps on Mike’s closed door, waited a minute, opened the door and said, “He’s here.”

They snagged Akio on the way to the cafeteria. The sound of laughter grew louder as they rounded the corner and were greeted with cries of, “Here’s Mike and Akio! You’ve got to do Mike and Akio!”

Leptig Varonick looked up from his laptop.

Mike smiled at the slightly built archeologist turned engineer and laughed, “I’m game.”

Jason motioned to the empty chair, “Sit in the chair so he can take some photos.”

Leptig walked slowly around Mike with his iPhone snapping away. He then sat down in front of his laptop made some image manipulations and pulled up a 3D picture image of the Genesis Test Equipment CEO.

3D Scanning in Progress



“This is done using one-two-three D Catch from Autodesk,” Leptig smiled.

He handed the laptop to Mike so he could rotate the image.

After lunch Lina and Lonzo joined Leptig, and Akio in Mike’s office

“I would very much appreciate a run down on how your project is going,” said Mike after taking a sip of his now suitably cold coffee. “It is called AC LLC isn’t it?”

“That’s right … AC stands for Artifact Capture. one-two-three D Catch is the kind of technology that helped propel me to start the non-profit corporation,” Leptig said. “That was two years ago and now I’m involved in one of the largest artifact 3D image capture projects in the United States.”

The discussions lasted well into the evening.

Two Months Later

It was time for the mid-year celebration at Genesis and as Mike walked to the podium he motioned Leptig to join him.

“I’d like to thank each of you for a great first half this year. We have seen the introduction of product into two new market segments as well as innovations in all our other segments. Thanks to recommendations from our logistics support group we have also started up a new additive manufacturing group and were able to spin off some of their activities to provide new opportunities to a disadvantaged community. Critical to this was our partnering with AC LLC, this year’s recipient of the Genesis Cultural Heritage Grant. It is my great pleasure to introduce Dr. Leptig Varonick, AC LLC’s founder.”

Leptig smiled at the assembly.

“One of the worst things that can befall mankind is the loss of any portion of its collective cultural heritage. Every artifact destroyed and every lesson learned along the way from antiquity to the present is the loss of a precious thing. AC LLC was created to prevent this loss from happening and to assure cross-cultural access to artifacts via identical copies using non-potentially destructive technologies. Copies offer the advantage of studied without harming what may be the only item in existence. They can also be used for people to acquire the skills necessary to properly handle in situ finds in the field.

If you truly understand configuration management, you know it is all around you. It might be said to be part of the human condition. As evidence, I’ll simply offer that cross bow firing mechanisms found at the Terracotta Warrior site in China had interchangeable parts. Those parts were also interchangeable with firing mechanisms found over 2,000 miles from the site and this is circa 210 BCE. I am personally convinced that for interchangeability to be so abundantly evident it had to have existed in some form at a much earlier date. Perhaps even predating the helve hammer mills in China say around 1050 BCE.

In a similar way, one of the worse things that can befall a company is the loss of its intellectual property. Part of this IP includes a product’s design heritage. Artifacts can be mislaid and be buried for thousands of years only to resurface again. Intellectual property once gone can be recreated through reverse engineering but that is expensive, and despite opportunities that may present themselves may prove too costly simply due to the non-recurring costs and passed by. But that is no longer the case.”

He paused for a moment before continuing.

“I have been reading up on your company’s history and was impressed by the nearly contemporary look and feel of the GDG 1500 series. Would it surprise you to know that all of the engineering for it was destroyed years ago?

3D scan

That is where the association between Genesis and AC LLC started. The same technologies being employed at the Smithsonian to digitally capture its 137 million-piece collection with high-tech scanners was used on critical components of the GDG 1500 series. Rather than reverse engineering your lost engineering, we were able to capture 3D scans of the items, modify the results to beef up weak areas and then use additive manufacturing to produce the parts needed to perform logistics operations such as returning fielded units to factory specification at a fraction of the cost of making the same item on CNC machines. One of the updated parts can be seen on the screen behind me.”

Leptig paused for a question from the audience.

Palo Wolffe scoffed, “So why was this important on a product line that hasn’t been built for years? I mean who really cares. Why don’t we make them buy new? Isn’t this just like my smart phone? Every two to three years I throw away the old one and buy something more powerful.”

Akio smiled and said, “I’ll take this one. The simple answer is because there is no equipment on the market today that does what the GDG 1500 series does and we have no plans to make a new model. It is in a way part of our collective cultural heritage as the equipment primarily runs diagnostics on classic European sports cars. I for one can’t imagine we would abandon a market where we are building the test equipment for their modern equivalents.

While it is no longer profitable for Genesis to continue logistics support, a steady revenue stream did exist for a small company to continue GDG 1500 series logistics support if the obsolete electronics were updated and mechanical fatigue issues could be resolved. After fatigue patterns were analyzed, the structural weak points were modified and an on demand additive manufacturing capability was set up. From project inception to finished product, this saved over 200 hours of engineering per part and a reduced production cost of 80 percent. The capability of 3D scanning and additive manufacturing will allow us to do some very amazing things in the future including exact fit replacement upgrades to onboard diagnostic equipment originally designed by others. Before 3D scanning there was no way to tell exactly the volumetrics of the area with which we had to work. Now that space can be determined by the 3D scan along with exact placement of all interfaces.”

Mike asked, “Leptig, what do you see as the greatest single issue involving digitized images and how can Genesis and others in industry help resolve it?”

“One unresolved issue involving digitized images regardless of end use is that of configuration management. Traditionally engineering was represented in drawing format. In the 1980’s we introduced paper space renderings from CAD programs, thermal and structural models, Software Code and now in the case of precision 3D scanning bit clouds. For some 3D scanning projects the bit cloud is married to a CT scan or MRI capturing internal as well as external features adding a degree of Configuration management complication not currently addressed in the ISO or EIA standards. Eventually additive manufacturing resolutions will be equal to our present scanning capabilities. 3D printing to the sub-micron level will be not only possible but commonplace. Our challenge today is to creatively manage and preserve these precious scans in our PLM systems as the definitive representation of the objects they represent. The ability to always preserver the scan as a cultural product baseline is imperative.

These artifact scans represent the greatest masterpieces of human achievement. They also evidence all the ravages of time. The urge to start manipulating the data clouds to remove this damage prior to printing will be at times uncontrollable. Without proper configuration management, baseline reversibility as well as iteration management of cloned bit clouds, the source data could be compromised or lost forever.

Imagine if you will, a masterpiece subjected to a poor restoration process. The restoration is what it is. You can’t undo it and go back. The starting place is lost forever. Now imagine always being able to go back. That is what we envision. We need to manage the data so we can always go back to the source 3D images if the original artifact is severely compromised or destroyed.

We look to Genesis and those in other market segments using additive manufacturing to create the international CM standards for 3D image capture and model control. You are on the forefront of these technologies and archeology will rely on those new standards you create as we put the case forward to preserve artifacts across the globe via 3D scanning.”

Configuration Management and Product Critique

Posted on: June 2nd, 2014 by admin 1 Comment

I received the email below shortly after an ITMPI Webinar I delivered earlier this month on the role of Configuration Management in Successful Product Critique that he attended. Mr. Aliev has graciously allowed us to publicly display his questions and our response. Thank you very much Mr. Aliev.

Hello Jon,

Thank you for presenting today on the webinar: “Configuration Management and Successful Product Critique”.

As per ITIL definition, “Configuration Management is the Process responsible for maintaining information about Configuration Items required to deliver an IT Service, including their Relationships. This information is managed throughout the life cycle of the configuration items. Configuration Management is part of an overall Service Asset and Configuration Management Process.”

During your presentation you didn’t mention or I missed something related to this definition or a role of Configuration Management in the service transition. Similarly, in project management the Configuration Management is mostly responsible for version control of such project items as documents, computing code, data, parts, etc.

I also didn’t get the idea about “Successful Product Critique” – what do you mean by that?

Could you please correct me if I am wrong. You mentioned about some useful templates on your website – could you please send me a link.

Thank you for your time!

Best regards,
Ramiz Aliev, PMP


Historical Background

You are correct; I did not use those explicit words. The ITIL definition needs to be understood in context. Until 1980 the fields of IT management and SW CM and Knowledge management did not exist. The largest split took place in 1991 when the term Knowledge Management was coined.

Below is a summary of the CM landscape at that time

U.S. DOD Requirements 1985 CE

This resulted in the following areas of responsibilities for all CM and can for our purposes be considered the CM fundamentals.

CM as seen by U. S. DOD 1985 CE

While the above may be somewhat hardware centric, items like the indentured parts list are directly translatable as an indentured CSCI list. Instead of assemblies, subassemblies and detail parts you have SW branching and twigs.

Present Application

The current guidance document applicable to IT, KM and SW Cm and CM in general generally list 5 distinct aspects of CM.

  • Planning and Management
  • Configuration Identification
  • Configuration Change Management
  • Configuration Status Accounting
  • Configuration Verification and Audit

For your purposes these can be expanded to:

  • Configuration identification
  • Baseline management
  • Change control
  • Library control
  • Status accounting
  • Reviews
  • Audits
  • Release processing

If you read and synthesize all of the prevailing guidance and add them to the ITIL definition you get a larger view of what CM really is:

  • ANSI-EIA 649-B-2011, CM Standard
  • ANSI-EIA 836-B-2010, CM Data Exchange and Interoperability
  • ANSI-IEEE 1042_1987, SW CM
  • GEIA-859, Data Management
  • GEIA-HB-649, Implementation Guide for CM
  • IEEE Standard 828-2012, Configuration Management in Systems and Software
  • IEEE Standard 12207-2008, Systems and SW Engineering – SW Life Cycle Processes
  • ISO 10007-2003, Guidelines for CM
  • ISO 15289-2011, Systems and Software Engineering
  • ISO-IEC TR 15846-1998, SW Lifecycle Processes CM
  • Mil_STANDARD-31000A, Technical Data Packages

You will find that it has not really changed much except for the acronyms used from the previous image of CM fundamentals. The tools may have changed but the principles have not.

Further Extension of Configuration Management

Your statement, “…in project management the Configuration Management is mostly responsible for version control of such project items as documents, computing code, data, parts, etc.” is correct. That is the change management part of CM. But CM also involves the management of the development environment, simulations, software licenses and versions as well as any table loads used to configure the test environment and the development environment tool configured settings.

Looking at CM from just the perspective of ANSI-IEEE 1042, SW CM two major aspects stand out

  • Planning
  • Implementation

Configuration Management and Specification Development

Specification development and iterative testing regardless of its environment are centric to the discussion you attended. They can be viewed as a combination of planning and implementation and form what is known as the establishment of the Functional Baseline with required functionality being allocated downward to various elements of the implementation (Allocated Baseline).

Configuration Management and Reviews

In the case of our specifications, inspections or reviews prior to releasing to configuration management can help ferret out the problems at the specification level before we start physically experimenting with the possibilities and making the product.  These specifications are developed using an iterative approach, meaning we only put into the specification what we are immediately attempting to learn and put that under configuration control. Recall I mentioned a Harvard Business Review on the Six Myths of Product Development.  We are specifically working with item six on that list.   We will periodically produce development baseline(s) depending upon the concepts we are exploring. This baseline may be a tangible incarnation of the product or via models and simulation (also falling under configuration management controls).  When we learn from that baseline, we will once again open the specifications up, add or alter content for the next iteration, review and then put this into our configuration management system. This is now fodder for our next iteration of the baseline to build and critique.

The specifications under CM are reviewed prior to locking them down with a release into the CM system. We plan our testing and evaluations on each of these packages as defined in our CM work.  All along this iterative growing baseline development we use CM to control the iterations and map the iterations to things like reviews, testing, inspections and evaluations, and adapt the next iteration from the learning of the prior.

The project organization should use the Configuration Management process to script the project and product growth – instead of just the version control.  In this way the product content is adjusted formally from the learning that should have happened in the prior work.  I would agree that project management shows more interest in the change management (if we are lucky) aspects of configuration management. However, the real power from CM is in the orchestration, coordination or facilitation of learning about the product.  Configuration Management can help us focus on the important aspects of the development work.

Configuration Management Summary

I chose the title carefully. A successful product critique does not happen as some may suggest via testing, neither is it at the end of the product development lifecycle. The product critique is more than the quality of the product to specifications (often associated with specifications), but the ability of the product to meet the customer needs (validation and evaluation methods) as well as reliability (quality of the product over time).  To perform this critique requires approaches similar to the top level identified in TIEMPO (Testing, Inspections, and Evaluations) all through the development process.  Critique in this context is appraisal – and what we want to know….. is the product what we need it to be for our customers and our company.

The first 30 seconds of this YouTube video may give additional insight:

I hope this helps,

Jon M Quigley and Kim Robertson

Subscribe to our Newsletter

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