Archive for January, 2018

Drop in Replacement

Posted on: January 31st, 2018 by admin No Comments

Today we discuss interchangeability of parts.  This may sound trivial, but you probably would not even consider replacing your food processor blade with your lawnmower blade.  It would be obvious that these are not interchangeable.  However, there are times when a part needs to be replaced or design is reworked altering the composition, that is the constituent parts of the product or design.

Let’s take an example and walked through it.  Consider the ignition key switch to your car.  It has a specific shape, mounts and attached with specific mechanisms, and performs or initiates many actions of the vehicle.  This is often referred to as form, fit and function.  Let’s consider the old ignition switch is going out of production from your supplier.  We would need to find another solution.  As an engineer we would explore alternative or replacement parts.  If we want to minimize costs, we would look for another ignition switch that forms, fits and functions identically to the previous one as this saves time to sort out the differences and modify either the switch the interfaces or the system.

For a truly dropping replacement we would require no change to the part, the interfacing parts, and the ability of the product to meet the system requirements.  The old part or the new part would meet the requirements of the system.  But there is much more to this than just form, fit and function.

There’s more to this function than the contact being made or broken based upon the key switch position or the next position in dickey place.  Specifically, the new switch may have subtle differences which will impact the performance, and certainly the new switches manufacturing processes are likely different.  When parts are assumed to be interchangeable we will likely also assume them to react identical to stimuli.  This assumption can be costly and even dangerous.

Let’s move on to discuss other parts of the function of the key switch.  Let’s consider that the switch we will call old, will support or hold a certain amount of force we will call N.  This means that the key switch requires a force greater than N to move the switch from one detent or switch position to another.  The new switch is not so stiff, it takes a force less than the old switch to move from one detent to another.  Are these switches equal?  No, they’re not, but that may not matter.  It is up to the engineer under the auspices of configuration manager to understand the impact of these different forces and these two ignition switches.  The switch with the greater force requirement is also able to better handle the key load variation especially the higher mass loads.  Meaning when put in a position the key in the ignition switch will tend to stay in that position because it takes more force to move it from that position.  Knowing this enables an informed decision regarding drop in replacement.  In this situation it would behoove the engineer, configuration management, and the organization at large to understand the implications on the system of an ignition switch what requires less force to transition from one detent to another.  The way to understand this would be to perform testing on this new switch to identify the impact of this reduced force on the entire system.  So, this drop-in replacement, at this point does not appear to in fact be a drop-in replacement. However, it is possible this difference means nothing, and the new part can supersede the old.  To determine the impact of this seemingly minor difference can be determined with simulation, calculations and testing. However, it cannot be accomplished by assumptions.

Requirements and Project Success

Posted on: January 27th, 2018 by admin No Comments

We have written much on requirements in other blog posts.  We have been maintaining this blog for years, admittedly sometimes more fervently than others.  We have created a schedule for our blog posts and other events by Value Transformation personnel available either on the event location on the website or as a downloadable from the website.

There seems to be a myth that “waterfall” development requires ALL of one step in the delivery sequence before the next step can begin.  For example, all requirements must be written before work commences on the development work.  I have worked in what I would call traditional development approaches that some would refer to as waterfall, and at no time did we believe or act as if all requirements must be known and documented before we moved to the next stage, the actual development.  Even PMI recognizes the need work with the level of detail that can be known from where the position presently, often referred to as progressive elaboration. That is, as we learn more about what needs to happen either product or project, we take the requisite action.

To illustrate some of what is known about requirements and project success, benefits from an introduce function point.  A function point is a unit of measure regarding functionality of a product or system. The larger the number, the more functional content in the product.  From this information, a correlation between functional content and cost and time can be derived, only if these things are recorded and tracked.  For more information on function points, please visit the International Function Point Users Group.

In a large sample study by Capers Jones[1], the data shows as function points increase, so too does the rate of project cancellation. For example, 40% of 10,000 function point projects are cancelled and 65% of 100,000 function points are cancelled.  In another larger scale study, we see that as function points increase, requirements volatility increases[2].  Requirements volatility amounts to numerous change requests which is a type of rework and can often be considered waste.

Those that think a conventional approach to product development often referred to as waterfall, requires all the requirements up front are probably setting their endeavor up for failure.  Studies and experience more than suggest an incremental and iterative approach responding to what is learned during doing the work.  This is an advantage to taking an agile approach in which there is not even a hint that all of the requirements must be known before doing the development work.



[1] Jones, C. 1996. Patterns of Software Systems Failure and Success. International Thomson Press.

[2] Jones, C. 1997 Applied Software Measurement.  McGraw Hill.






Independent Test and Verification

Posted on: January 23rd, 2018 by admin No Comments

Testing of Complex and Embedded Systems

Testing of Complex and Embedded Systems

Independent Test and Verification

We are composing a glossary of testing terms and we take one from that work today and discuss here.   We welcome any and all that would like to contribute.

Today we discuss development and independent test and verification.  A development organization can be structured in many ways. The development and testing can be essentially one department under one management structure, or these two areas, development and testing can be separated each with a respective hierarchy.  Like most things, there are benefits and drawbacks for each approach.  The trick is to map the biggest benefit to your organization, or reduce the negative effects on your organization.  All of this means the selection for organizational structure is likely not best left to an arbitrary decision.


I am sure we see the obvious benefit of having the test personnel integrated with the development staff.  Those who have been in development for awhile no doubt understand the communications challenges that can come with separating groups when interaction between those groups is paramount for project success.  So, the benefit of these two disciplines is one less barrier to communication. However, there is more to it than that.  For example, consider a company that develops manufactures sells and supports the product after launch, like perhaps an automobile.  When communication between the development group and the test group takes on a more informal approach (verbal) we lose some of the ability to propagate the details of the product.  In my experience, the veracity of the documentation has a big impact on the depending activities of such an organization. For example, design documentation can serve as the core for service and troubleshooting of the customer’s product.  I have personally witnessed where an increased or sole reliance upon informal communication rather than technical documentation, meant the technical documentation was not promptly (or ever) updated to meet the actual product when informal communication is largely or solely the vehicle for this exchange. Those that get the formal documentation, are receiving outdated and errant information from which aftermarket product documentation and troubleshooting manuals may be derived.  In an instance like this, we exchange the improve quick interactions between the developers and the testing group, but it can come with consequences to those downstream.

Familiarity – not via Communication

Integration of the development and the testing groups comes with another potential downside.  We are all on the same team, we can suffer from group think. That is, we do not see the blind spots. We are on the same team, the level of critique from the testing group may suffer.  This relationship between the developers should be cordial, but not so familiar that the testing is soft on the product for fear the developers will take the feedback poorly.  I liken it to yin and yang or offense and defense in a sport (football).   I have seen the level of formalism descend to the occasional excel sheet tracking what is found and those depending activities – product documentation and service information will be built upon design documentation that has only a modicum of relation with the actual design incarnate.  The customer suffers and moreover, understanding the way our product works moves toward word of mouth, and therefore depends upon who you talk to for the answer.

Specialty Division

Creating both a development team and a testing team provides time, space and focus for specialization.  That is, the test team can develop their processes, tools and talents to meet the specific demands, and so too can the development group. We do not have development personnel burdened or distracted by the test activities within the group and vice versa for the test group.

Fault Reports and Escalation

Testing finds defects or non-conformance’s in the product.  The splitting of the development from the testing can put both disciplines on an equal playing field.  For example, consider the development manager that has test personnel also within the staff.  During a project, decisions must be made regarding the product suitability for launch.  The launch of the product is approaching, and testing finds some things pending evaluation but really has not concluded their work.  The manager will likely feel compelled to launch the product and there is no entity designated to defend an alternative viewpoint.  What do you think the probability of launching the product is, when the only person to make that decision is responsible for both the development and the testing in their hands?  With another hierarchical structure in place, there is a counter argument and discussion that can take place regarding any latent reliability and perhaps legal risks that may come our way.


There are many things to consider when structuring your organization.  The organization’s culture, the level of risk toleration based upon the product, company and industry and many other nuances.  It is not as easy as just keep the existing structure or “spin” off the testing from the development.

Task Dependencies and Probability

Posted on: January 19th, 2018 by admin No Comments

Flip a coin, heads or tails. The probability that it will come up heads is 50%, after all there are only two sides.  Flip that same coin again, the same probability, 50%.  However, if we say that success is two successive heads (or tails) that is different. The probability of two consecutive heads, is the product of the two coin tosses (50% x 50%) or 25%.

I’m sure we understand task dependencies.  This is fundamental to project management and schedule.  Dependencies are the connections between tasks for example, I must put socks on before I put my shoes on (assuming I wear socks, which I generally do).  Of course, this is not the only type of dependency (finish-start). There are four actually;

  1. Finish-start
  2. Start-start
  3. Start-finish
  4. Finish-finish




Let us focus on finish-start for a bit. Specifically, lets talk about a portion of the resulting schedule and the task consequences on the entire project.

Each task has been assessed to have a 90% probability of being successfully completed.  Both tasks are to be completed to be successful, and success is defined as accomplishing the attributes of the task, that is objective, cost, and schedule.


The probability of successful completion of the tasks at 90% may sound pretty good, that is until you use some math.  Let’s say these tasks are also unique, that is one task has no bearing on the probability of the other’s success, either depending or predecessor.  So the probability of these two tasks actually successfully being completed is 81%.

90% x 90% = 81%

A probability of 81% success may not sound horrible until you realize there are very few projects that consist of two depending tasks, or that have a task probability of success being 90%.

If your project plan does not have any slack, you are on what my friend Kim Pries refers to as a death march.  Planning long term projects, that is project aspects that are way in the future, will especially suffer from this malady.  This is one of the benefits of agile approach where planning has a clear short-term focus, which is contrary to the frequent approach to conventional projects.

We can learn much about the overall project by looking at the individual tasks. It is certain that sometimes identifying the probability of the individual tasks potential success is more of a subjective exercise. However, there are also times when subject matter experts, those that do the work, or perhaps some available process measurements add some credibility to the assessment.

Saving The Day

Posted on: January 16th, 2018 by admin No Comments

Saving the Day

What is it about running in and saving the day like the old westerns that companies enjoy.  Why is it we value the Herculean effort to correct or fix the result of poor strategy, poor decision, insufficiently staffed, or poor execution? Could we agree that generally is better to get things correct the first time where possible?  It is not the idea of not taking risks (calculated) that I am referring.  These calculated experiments that are undertaking with the goal of learning and not the source of our failure of which I am referring.  Rather it is the poorly calculated or evaluating approach to the work, for example, cutting corners in the development work to save time or money or perhaps it is the poor project or product strategy, or too little time vetting either broke both.  Or maybe my favorite the understaffed endeavor.

Is it really a Gain

These events often take considerable effort from our staff to either carry the day from the start or some select people from the group to come in and save the day.  This effort, often through uncompensated overtime, takes employees away from their families and otherwise disrupts their lives.  Sometimes it may come with some reward such as verbal recognition, or some time off or a gift card.  What of those projects or plans that go through uneventful either through well thought out plans, sufficient staffing levels, well executed and adapting work, or perhaps just plain luck? These events often slip blindly by unnoticed.

  • What signal does this send to our employees?
  • What if anything does this do for the rest of the team?
  • For those that are the ones who frequently must pull the fat from the fire?
  • What about those projects they go off without problems where there is no need for a firefighter?
  • Do those employees feel valued when no fuss is made because decisions taken were good guesses or well calculated and effective?
  • How does this influence our organization’s culture?

CES 2018 Event

Posted on: January 13th, 2018 by admin No Comments

CES 2018 Event

I have never gone to CES 2018 Event (Consumer Electronics Show) and was taken aback by the size of the event.  There was considerable to see, even with the minor discomfort of periodic electrical blackouts at various parts of the show.  I have a great enthusiasm for creating new things (I have ceded 7 US patents and other country patents to the companies at which I have worked).  I wonder about who things are created, where do these ideas originate and the level of productivity of the group that create these things.

It was in warm, even if wet and sometimes flooding Las Vegas.  Walking through one of the casinos I saw this flood outside the window.  There were a number of accidents and getting around was a little difficult (traffic).


Flooding down in Vegas (a nod to Stevie Ray Vaughn – Texas Flood)

I had fun on the Sony virtual ride, where I felt like I was going over a cliff at times, at other times it felt like I was in a Tron game, or skiing in the snow.  I have heard of these systems but had never sat in one of them or experienced the virtual ride before (the seat moved around, leaned forward (belted in) so it felt like I was standing on my face.


I spent considerable time with the vehicles at the CES 2018 event, I am an automotive guy after all.  I especially enjoyed the Mercedes Project One car seriously nice ride.  I think it was 1600 cc’s roughly the size of my old Vulcan motorcycle, cranking out nearly 1000 HP, the propulsion is electric.  The vehicle could go more than 100 miles per hour in 6 seconds!  I would really have liked to take a ride in this vehicle.

Project One

Project One

Hyundai Hydrogen

My favorite had to be the Hyundai Hydrogen fuel cell car.  I frequently have discussions with my son about battery vehicles.  He believes batteries and electric vehicles are the best solution.  Batteries require digging up elements from the earth and disposal of the battery after wearing out.  In addition to these toxic environment impacts, there is the range issue, as well as the time to recharge.  Recharging the battery takes time and the range is limited.  I cannot help but think the hydrogen fuel cell is potentially better, as the range limit is erased, and it may be less toxic on the environment (water in, and water out).


Hyundai Hydrogen Car

Hyundai Hydrogen Car

Freemont Street

It has been years since I have been to Las Vegas, saw many interesting sites outside of the show on Freemont Street.  I watched the light show while listening to The Who and many of the street musicians playing on the platforms that line the street.  There was plenty to do with any remaining energy you may have had after the CES 2018 event ended for the day.


The rainy day walking out on the street was not so interesting, however, the second day, after the rain had stopped and the weather was warmer, and it was fun and interesting indeed.  People from all over the world walking down the street, no trauma, all behaving well after the CES 2018 event.




I had a wonderful dinner at Carmines, we had an 8 pm reservation and ended up finally sitting down to dinner after 9 pm, this probably should have been anticipated since it has been reported that 170,000 people attended the CES 2018 event. A table full of guys could not clear the plates! Great seafood and pasta dishes with a range of sauces. We capped it off with a Tiramisu.




There is considerable to see at these events providing opportunities for ideas to come forth and create different products or apply existing products in new ways.  These new and exciting products provide opportunity for idea generation and discussions which can build extent technology and creativity yet further.

On another topic, if you go to the event, bring very good shoes or multiple pairs to rotate.  By the end of the third day, I was wishing I could walk around without shoes.

Subscribe to our Newsletter

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