Archive for August, 2016

What we can learn from the show House?

Posted on: August 31st, 2016 by admin No Comments

Not all television is not mind numbing.  I enjoy The History Channel and many other similar channels as these are not exactly learning opportunities but close.  However, my son turned us on to a show called House on Netflix[1] and it is very interesting.

House (also called House, M.D.) is an American television medical drama that originally ran on the Fox network for eight seasons, from November 16, 2004 to May 21, 2012. The series’ main character is Dr. Gregory House (Hugh Laurie), a pain medication-dependent, unconventional, misanthropic medical genius who leads a team of diagnosticians at the fictional Princeton–Plainsboro Teaching Hospital (PPTH) in New Jersey.

Logo for House TV Series

Logo for House TV Series


 All of you engineers, test engineers, and project management people out there could benefit watching this show.  In this show, the premier diagnostician – House works to solve complex physiological and life threatening conundrums with his patients.  He does this by considering the symptoms (failure mode) and then drawing upon a diverse set of inputs from other very talented doctors to theorize a possible diagnosis or range of diagnoses.  He does not assume he knows more than he knows, following the evidence and aggressively working to uncover evidence (biopsies) and treating based upon what he knows.  Even when a contraindication may arise due to the proposed treatment, he presses on and adapts based on what he learns.  For example, there are two possible conditions the patient has, the most probable is selected and that is the prescribed treatment. However, this treatment will either fix the problem or if the second possible diagnosis is really plaguing the patient, then there will be a turn for the worse for the patient.  This essentially is putting the life of the patient at risk.  Both of these outcomes provide more clues as to what is really going on with the patient and the possible solution.  In some instances, the team presses the stimuli to which the patient is to be subjected beyond the limits.

So here is how to apply this approach for testing.  Follow the evidence and do not make the assumption the reported failure symptom is a lie, but more likely an errant description of the situation.  I have personally seen test failures reported that cannot be replicated, and the idea is often to dismiss until more evidence is found.  That does not mean the failure did not happen, but some combination of stimuli or preceding stimuli may have set up the witnessed failure.  These require aggressively seeking the cause pushing the product beyond the limits. To quote from the Spinal Tap movie “turn it up to eleven”[3].

As for project management, we should rely more on metrics that allow us to understand the situation.  If there is no measurement backing up the statement from the team member, we know there is risk associated with the topic under discussion.  To not be duped either intentionally or accidentally (unbridled optimism) we need to remain objective.

[1] “House, M.D.” Wikipedia House TV Series Retrieved August 31, 2016.

[2] The logo for the TV Series House.

[3] Retrieved August 31, 2016

My First Five Jobs

Posted on: August 26th, 2016 by admin No Comments

I was what was referred to later as a latch key kid.  I was not aware of this term until long after I was through high school.   My dad was in the Special Forces during the Vietnam War and stationed all over the United States.  Any army dependent will tell you this is how it works, a couple of years here, a few years there.  My mom worked outside of the home at a variety of manufacturing jobs.

My first job was cutting the grass on the sides of the roads within the Anderson Creek Trailer Park.  In those days it was largely wooded with abundant pine trees and I think now it is golf course area.  By the way, I was not out of high school when I had this job.

My second job was working in the tobacco fields for Odell (I remember his last name but would not want to use it without permission). I topped and suckered the plants.  For you that have not worked in the fields, that is removing the blooms (topping) and the extra leaf growth that would sap the growth from the primary leaves (suckering).   Then, later in the season it was priming (picking) the tobacco, walking down the rows and pulling the appropriate leaves (ready for harvesting) from the bottom of the plant.  Once you have an arm-load of leaves, you would walk back to the tractor and place the load in a specific orientation on the trailer behind the tractor.  Then go back to priming the next section of that row.  I have also worked in the barn hanging the tobacco leaves that were stitched onto a stick that would be passed to us to hang inside the barn.  Over time, the tobacco was cured, back into the barn to remove the dried product pack it up and take it to market.  I did this also while I was still in high school – it was mostly a summer job. –

My third job was working as the outside man at a fast food restaurant.  I would spend a few years here.  The outside man cleaned everything, trimmed weeds, and took out the trash and many similar jobs.  The outside man worked nearly every day, only for 4-5 hours as I remember.  Still, every day getting up at 0500 to get to work on time, this was in Lillington North Carolina from Anderson Creek.  There were times my car was out of service and I would sometimes bike to work.  Good thing I had that job working in the fields as I was very fit for this.  I held a number of jobs here, promoted from outside man to cook, and on to cashier.  I learned everything about the working at the restaurant that I could.  It is my nature to work to understand.  I will count these numerous jobs a one though that is not exactly true.

My fourth job, was at U-Haul while I was getting an undergraduate degree.  I was what we affectionately called a yard dog.  We installed the equipment on the customer vehicle, put hitches on customer cars, and prepare the vehicles for the customer.  Eventually, this moved to moving vehicles across the state.

My fifth job was my first post-undergraduate degree working at a small industrial product development firm.  There were few engineers and I was put into a position to learn nearly everything.  It was a little overwhelming, but the people that worked there and associated with the company (consultants) were more than willing to share what they knew.  I was an embedded product development engineer, I would design the embedded hardware (example: 805x and PIC controllers) and support circuitry.  Once this was done, I would wire-wrap a prototype (did this a couple of times to learn) or a technician would build the prototype while I would begin building the software.

I have had many jobs and positions in my life.  All of these were things from which I could and did learn.  All of these have made me what I am today and I am grateful for these opportunities.

Scrum, System Development and Multiple Suppliers

Posted on: August 24th, 2016 by admin No Comments



There are a number of challenges when developing products or systems using multiple suppliers.  My experience mirrors that of those of the Defense & Aerospace Group on LinkedIn that many systems are developed with more than one supplier, each with a sub-assembly or sub-system constituent of the entire system assigned to a multiplicity of suppliers.  Agile can work here also; however, there are a number of challenges with communication and coordination of the work. One of these, the coordination, is not as difficult.

Systems Development and Scrum of Scrum

Consider the product backlog, arguably the starting point of any agile project.  Now also suppose we are working on a system or collection of components that comprise a subsystem.  To be able to assign these packages to different suppliers we will need to have the system already described so we are back to post concept.  Our product backlog can be structured to reflect the systems expectations; we will call it the systems backlog.  We will need our teams to be collocated as we pull items off of the prioritized systems backlog for execution by the various scrum teams.  In this way, we coordinate the work required to meet the system backlog expectations.  If one part of the system is delivered but the other part of the function has not been delivered, then the backlog item will not be met.

Coordinating the system backlog, each supplier will take on their respective portion of the system. This will be that supplier’s sprint backlog.  This will focus the development effort on delivering an iteration of the system that has a well defined and prioritized content, and this specific sprint will focus on immediate system expectations.

Scrum of Scrum

We will, of course, have the individual sprint daily meetings, but we will also need to have a short meeting at the systems level as we are working within a scrum of scrums.  This is where we will manage the coordination of the work from the systems perspective.  As we learn the individual scrum team results, we can adjust the system along the way in the same way we would adjust the specific sprint items and backlog.

My Department, Our Organization

Posted on: August 23rd, 2016 by admin No Comments

LO / OD Application

by Shawn P. Quigley and Jon M Quigley

We will need to start this discussion with a question: “What have you ever done that did not teach you something?” It is by the nature of any activity especially those that require coordination and preplanning either learning or development occurs. Most commonly both will occur. This is either by plan or through pain. In our previous post: learning through mistakes, we eluded to this fact.

While there are many organizations that have people who specialize in Organization Development and the Learning Organization, these people are not always used to their fullest. These people are commonly used for post mortems on a project or specialty projects. While this does provide some benefits it is leaving the majority of what could be gained from these philosophies off the table.  To put it more clearly, our solutions will often be to lock the barn after the horse has left. This type of application of these disciplines is common to organizations that are very compartmentalized.  This is probably a function of one area manager thinking that they have no control or input into another area. This thought is directly counter to one of the primary tenets of a learning organization, Systems Thinking. In fact, we venture a guess based upon experience that many companies out there are losing millions of dollars due to this myopic or impaired approach. Fixing only intradepartmental issues, of the organization while the whole hemorrhages profusely will not improve the company at large.

While specialization provides a higher level of skill with the subject area and numerous associated improvements, it often comes at the cost of the ability to see the entire forest.  This division of an organization can: and commonly does, fosters an atmosphere in which each part of the organization only focuses on their issues. These organizations are often referred to as silo organization and communication across silos can be difficult to non-existing.  Commonly to the point where the whole picture is not even a thought due to a feeling that each area (department) can only change or better itself and has little to no effect on the other areas (departments). We have personally seen businesses focus on solving a problem to the tune of a few thousand dollars because it was departmental while neglecting a few millions of dollar problem because it is organizational. That is no way to run a business.  If this were not the case then more organizations would have the discipline of organizational development and the learning organization embedded into their planning phases of their projects vice being mainly in the post-mortems.

As we have discussed in our article LO/OD and Project management when these disciplines are applied in the planning phase and throughout the organization then the improvement is not only easier but is commonly sought. This desire for constant improvement of people and processes is personal mastery and the understanding how one part affects another is systems thinking. If these two of the five disciplines are employed the remaining three will begin to develop themselves. This cycle when actually promoted by an organization will sustain itself, but it cannot be done through anything less than complete and true support.  It requires more than hand waving, specifically, we will need management to recognize the importance of this way of working and support it.

How does adding these disciplines to the beginning of a project help?

Agile and Post Conceptual Design

Posted on: August 22nd, 2016 by admin No Comments

 From what I have learned over my life thus far, is that we need not think of things as either-or, at least not all of the time.  Heavy metal guitar player’s use pick slides to make interesting screeching sounds, but bass players can also use this contrivance – to make a different yet similar if not so eerie sound.  This applies to much more than just to music.

We posted a discussion on LinkedIn at the Defense and Aerospace group about using the same techniques we use for generating a WBS in conventional projects, to generate the sprint backlog from the product backlog in scrum.  In both the case of creating our sprint backlog, and breaking down our conventional project scope, we are disaggregating a higher level of abstraction to a level upon which we can take action.  This is not the only place we can employ conventional techniques in an agile project, or the contrary, agile techniques in conventional projects.  We have applied these agile approaches within conventional projects and even the line management function with great success.  But this brings up other questions, for example:

  • How can these practices fit into the larger product development process?
  • Are there limits to when we can either use agile / scrum to product development?
  • Should we focus on employing specific agile philosophy into our conventional approach or find ways to move toward agile entirely?  Does our industry allow this transition (high risk or legally regulated)?

With quick prototype hardware techniques and approaches, we can build iterations or mock-ups along the way even when it comes to articulating the system level concept.  I have used an agile approach at the front end of the project to create detailed specifications and have them reviewed and delivered just in time for the software developing group.  At this point, the system was largely known and prototype hardware iterations would be available.  However, the details of the system interaction were being developed in these detailed specifications.  Sub-system engineers wrote the specifications with reviews from systems engineering before being sent to the software group that developed.  I was part of the specification writing team, and what could arguably be referred to as the scrum master for the software development team.  The specifications were listed, prioritized, and then written and delivered in blocks according to this prioritization.  After 2 weeks, a batch was delivered and the software development commenced.  The specification writing would continue, delivering a portion from the prioritized list in each increment.  

All of this agile or scrum-like activities happened inside a conventionally ran project following APQP type approach.  I am not sure how close to the start of the project we can employ these agile approaches, but I know we can learn considerably from experimentation and observation.

Work Breakdown Structure – Decomposition

Posted on: August 19th, 2016 by admin No Comments

In an earlier blog post, we compared the WBS Dictionary to the Agile Definition of Done. However, we never reviewed any connection between conventional project management Work Breakdown Structure (WBS) and the decomposition of the product backlog to produce the sprint backlog.  Before we can describe what completion of the item looks like, we must first identify those things that we will need to produce either in this portion of our conventional projects or in our sprint.

In conventional projects, we start with the scope and identify all of the things we will need to do to be able to produce the scope objectives.  Often this decomposition is performed on the entirety of the scope, though this is not a requirement. That is, at the beginning of the project we are decomposing all we know about the project often through to the end of the project. We identify the list of all the work to produce the scope.  The breakdown will often be associated with parts of the organization and each will have an allocated budget for the project based on the results of the WBS and estimates that are generated.  To evoke the work items and build the WBS we will:

  • identify the deliverables per iteration
  • decompose the deliverables to specific components
    • brainstorming / collaboration
    • interviews
    • historical record
    • process documentation
    • subject matter experts
    • external influences (legal and regulatory)
    • logical ad technical dependencies

For our agile work, we make no attempt to be able to predict work that is too far out.  However, we will still need to decompose the highest priority product backlog items (whatever we can fit into our sprint duration).  So the only real difference between these two is the time horizon and perhaps the level of formality via documentation.  If that is true, then we can use many of the same techniques or disaggregating the work.

The difference between agile and conventional project management is not as large as many people would have you believe.  The time horizon for conventional projects is not a hard rule of project management. In fact, the PMI phrase is progressive elaboration which accounts for this uncertainty.  The estimating techniques you would employ for conventional projects can easily be used for the other and vice versa.  We not be shackled to either conventional nor agile approaches but map our approach to the situation, and employing whatever approach, no matter the origin to the situation in ways the reduce risk and improve the probability of success.

Waterfall is not Agile. So What?

Posted on: August 17th, 2016 by admin No Comments

I was exploring twitter as I sometimes do in the morning when I came upon this interesting post.  It is true, to paraphrase Rudyard Kipling, waterfall is waterfall and agile is agile, and never the twain shall meet[1].  So?


Agile is not warerfall

Agile is not waterfall

The goal of any project is to successfully deliver the objectives of that project and the customer (sponsor).  Does it matter that adding stand-ups and increasing the iterations does not make a conventional approach to product development agile? Agile is not the end itself.  In other words, we do not adopt agile because the goal is to adopt agile. We adopt an approach to our project endeavors that we believe will achieve the goals of our project endeavors.

There are times when an agile approach adds more risk to the project success then improves the odds of success.  Other considerations such as project scope, regulation, risks, industry type, organization structure and probably a host of others that must be considered when determining the approach.  Those that say the agile approach is the only way; are essentially saying I can use a hammer to unscrew a Phillips head screw.


When you nee a hammer....

When you nee a hammer….


The truth is there are many ways to accomplish the goals of the project and it requires an understanding of the risks associated with the product as well as the environment in which the project operates.  This includes, but is not limited to the available talent for the project.  Defective implementation of an agile project will produce poor also so agile is not a panacea for product development.  However, there are aspects of agile that can help any project approach, and two of those are iterations and communication.  There are many studies (for example, Standish Group and Capers Jones) that show an incremental and iterative approach helps improve our likelihood of success.  The same is true for quick recurring communications with the team.  This is where the project manager understands the rate of actual progress and is able to compare to the planned progress (Earned Value Management) and can take immediate action to either improve the situation or manage expectations of the sponsors for the project.

Okay, so adding more increments and improving the communications and monitoring in our conventional projects do not make our conventional projects agile.  Why does that matter anyway?  The goal is not to adopt agile. The goal is to successfully deliver and reduce risks.

[1] The Ballad of East and West by Rudyard Kipling

That’s No Way to Treat Our Supplier Partner

Posted on: August 16th, 2016 by admin No Comments

This may or may not be a true story, but I promise it happens every year.  We start with the customer organization and a supplier that the customer refers to as a partner supplier. This “partner” supplier collaborates with the customer to develop custom components for a larger system the customer sells to their customers.

This supplier provides a rather complex product and had worked with the customer to develop, and in fact, had amortized some of the development costs into the product cost (per the customer’s desire) to keep the development costs down.  All were in agreement at the start of the development and some of the development costs are to be amortized in the product cost.  This amortization was based upon a volume of product sold per year until the development money was recouped at which time the price would be reduced to the customer. 

Then, due to other changes in the customer organization, the customer decides to change suppliers and develop a new product and replace the present supplier’s product in two to three years.  This cut the present suppliers contract roughly in half.  The supplier does the only thing they can do; raise their price on the remaining production volume to cover the amortized development expenses.  It is simple math.

The customer does not like this “unexpected” increase in product cost and begins to pressure the supplier to reduce the cost.  The supplier continues to explain the situation, justifying their increase in the cost, but the customer organization disagrees, and then work to promptly extricate from the present supplier.  After much cajoling from a contingent internal to the customer, and hand wringing the customer concedes and agrees but only after generating much tumult at both the supplier and customer organizations.

If the customer had succeeded, the supplier (previously referred to as partner supplier) would have taken a great loss. This is not how we should treat our partner suppliers. They have as much right to be in business as we do.  This situation was not so difficult to understand, the math is really elementary.  A company that does not respond rationally based upon the facts, but rather opts for behavior that attempts to extort as a way to renege on a contractual obligation, is acting more like a misbehaving child than a reputable company.

The Perpetual Cost Reduction

Posted on: August 13th, 2016 by admin No Comments

Cost improvement activities are part of many if not all organizations.  In the automotive industry, these cost improvement targets can have an annual schedule. That is, we can expect pressure from the customer to reduce the cost of the product to them every year.  Immediately after launch we are able to hit these targets.  We can improve our production processes with the things that we have learned over the year since the start of production.  If we have a continuous improvement mentality at our company, we perhaps find this not so difficult a challenge.  However, as we continue to provide the product to the customer this annual cost reduction can seriously erode our ability to make the product and remain profitable. After 5 years, at 6% annual reduction in cost, we can expect to have more than 20% reduction in the product cost to the customer.  The margins from the start of the product are often not so high that would allow this cost reduction and for the organization to remain profitable.


Reducing Process Cost with Lean, Six Sigma, and Value Engineering Techniques

Reducing Process Cost with Lean, Six Sigma, and Value Engineering Techniques

There are things we can to stave off our running at a loss for the product.  We can explore the manufacturing and assembly processes to produce the product. We can review the design for small but beneficial adjustments that can be made without compromising the integrity of the product.  Of course, any changes to the produce or product must be carefully considered for any risks associated that may call for another round of product testing which may defeat any beneficial cost decrease.  For example, in the automotive world, we may have to again perform the PPAP (Production Part Approval Process) activities and submission.  A full PPAP can be expensive but experience suggests that we may not have to redo the entire submission but focus on the areas that would be at risk as a consequence of the cost improvement work.  At any rate, it is prudent to reassign a new part number for the product when it is either built from a different manufacturing, assembly or incorporates design changes to reduce the cost.  In this way, it is possible to discern any unanticipated and subsequent product quality impact from the previous line of the product.

There may be limits to what can be done to improve the product cost structure.  We will not know until we start doing the work.  If this is our supplier, we as the customer must understand that there may be limits and at some point, we may not be able to reduce the cost as the supplier is also in business and losses do not work for them either.

Requirements, Benchmarking and Teardowns

Posted on: August 10th, 2016 by admin No Comments

Requirements and Benchmarking

One of the things we can do to understand and develop our own requirements is to explore other products that are similar to our proposed product or that solve the same or similar customer problem.  Where there are similar needs met, benchmarking is a way for us to understand how other suppliers have met the specific challenge, or more importantly, how we can develop the product in an even better way.   Benchmarking can provide us with performance metrics for the product.  Knowing this, we can establish the performance expectations from our product which will show up in the requirements for the product.

Requirements and Teardowns

Teardowns are also useful when it comes to requirements generation.  We can learn what drives the cost in at least one incarnation of the product, which is how the competition has chosen to meet the customer demand.  We then are able to gain some measure of understanding of at least one possible incarnation of the solution (product) helping us to understand trade offs that were made in developing the design.  We are then able to bring our creativity to the table using this implementation for critique.  There is a slippery slope, however, in that we must not infringe upon any intellectual property lest we pay the price at some later date in litigation.


We need not go into the requirements gathering and understanding of the new product blindly. We can learn a great deal by exploring the existing product environment.  Experience suggests, when we use these approaches, we find other ways to accomplish the objective.  We can learn from others, which can keep us from burning our hand on the metaphorical stove, as well as giving our team and talent a starting point for brainstorming other ways to achieve the goal.

Single Sign On provided by vBSSO