Part 8 – It’s the Destination – Not the Journey

An earlier article (“Lets Gather a Few Good Friends”) pointed out that early and continued focus on a specific design created by a “founder” of a design effort can lead to significant problems and lack of quality in a final manufactured product.  We made the argument for using a cross functional team early in the requirements definition / design process because doing so is an excellent way to reduce the probability of “latching on” to a low-quality design.  This does not mean that the original “founder’s” concept may not have been truly excellent – the team simply cannot know until they work it through.

On the other hand, arguably the most important objective of a design project is its own completion, including delivery of a high-quality product.  For this reason, the arguments of “Lets Gather a Few Good Friends” are not meant to imply that the design team should ponder for prolonged periods the project’s requirements, scope, or design decisions.  Once the design objectives, scope, and requirements are defined, there is great power in focusing on and adhering to those definitions.  Doing so sharpens the clarity of roles, responsibilities, and objectives for the entire team.  Conversely, continuously second-guessing decisions, changing objectives, or adding scope causes lack of focus, delay, and additional cost.  The team should at all times be highly focused on completion of a clearly defined project.

This is what we mean by the title of this section: “It’s the destination, not the journey.”

Why are the risks of lack of project focus so great?  From the technical and quality side, re-visiting old decisions opens wide the door to low quality designs.  Often, such “revisions” arise very late in the game, are made in a rushed manner, and involve people who were not part of the original decision.  As such, the information and perspective regarding quality used to support the original decision may not be taken in to account, and the rushed manner of the later decision may not allow for recovery of those perspectives.  In addition, doing so opens the door to the team’s losing track of what is truly important (and thus what leads to quality) in the design.  Finally, project time is lost:  often a lot of time.  We saw this situation play out in the vignette posed in our first article “Setting the Stage and Initial Thoughts.”  In that vignette, the team had ill-defined design objectives, and started arguing about them and redefining them as they went.

Lack of project focus has many ramifications.  The loss of time alone has financial implications (salaries are still paid, additional delay in getting to market results in lost revenue).  Trying out new design options is not free: there is additional cost in obtaining, prototyping, and testing new components and parts and attempting to integrate them in to the “old” design.  The additional requirements and gold plating[1] on the final design incur cost that may not be offset by increased sales price, etc.  With the current fast pace in lifecycle in other industries whose components and assemblies we may rely on, there is a very real risk any delay will see parts and components discontinued or obsoleted by suppliers.  This then requires more resources to identify, incorporate, and test replacements.  From a quality perspective, the increase in requirements and gold plating increases the “target area” within which low quality in the design can rear its head, especially if the decisions and resulting implementations are rushed.  Replacement of discontinued or obsoleted parts also presents a quality risk, as their integration in to the “old” design may not be seamless from a systems engineering perspective.

From a Regulatory perspective, even though a product may not yet be approved, there is a  (compliance) obligation to track design changes.  A constantly-changing design is very hard to document and defend: this creates audit risks for findings in the design process if the confusing “story” of how the design unfolded is not clear to the reviewer[2].

Those of you who have been fortunate to work with a focused, responsible team can attest to the differences and advantages when unwavering focus is involved.  There is excitement, camaraderie, cohesion, and individual responsibility within the team.  This produces thoughtful, productive discussion and debate within the team, along with rapid progress towards the team’s objectives.  It is, unfortunately, somewhat rare for people to experience working on such a “high performing team.”

The point here is one that everyone, senior management, middle management, established senior technical people, and newly graduated technical people must understand at a gut level: our biggest challenges to achieving high quality in our project and design objectives are not technical.

The biggest risks are the “soft” things – social, interpersonal, and team dynamics issues.  Specifically, the issues that frequently cause projects to fail to achieve their goals are lack of true group cohesion and buy-in on the direction, objective, and method of execution of the program, along with lack of true group agreement on domains of responsibility (and accountability for deliverables).  This is why investors and venture capital firms should, and often do, ask and look for execution by the team, not whether the objective is technically feasible.

Because of this, a sub-title of this section might well be, “The Softer Side of Engineering.”  Why and how do you take a design team and drive them to focus on adhering to requirements, scope, and design decisions that have already been made?  Doing so is neither engineering, nor is it in the dominion of the quality system.  Maintaining this focus is effective project management at its core – and requires those “soft skills,” not technical skills.

But what does that mean?

We have already written about bringing to bear multiple perspectives and scopes of experience and drawing on these to yield the best solutions – especially during the creation of requirements and initial design stages.  But this must not be “management by committee.”  Adopting that approach is a recipe for stalemate, and for team members failing to take individual responsibility for their roles and deliverables.

There must always be someone with the responsibility to make decisions – but those decisions must draw on the wisdom of the team.  We have never recommended that the team should be driven to the “best” decision.  Someone can always argue “If we delay this decision we will know more and make a better decision.”  But that will always be the case at any point of time.  Trying to hit the bull’s eye 100% of the time is neither cost nor time effective:  if you perpetually leave the door open to ongoing changes, you will either never reach any objective, or you will end up being rushed and make panicked decisions (either in schedule or design) that produce low-quality product.

The person responsible for making decisions should expeditiously draw out the wisdom of the team.  That same leader should strive to have the team say “this is our conclusion – this is our stake in the ground and we will stick with it.”  This is very different from telling the team what to do.  Rather, it is facilitating the decision making of the team and enforcing their decision.

So make those decisions with the team (i.e. define the project’s destination), trust those decisions as sufficient to the needs at hand … and stick to them (i.e. don’t change the destination and don’t sight-see along the journey).  Don’t add to them, and don’t change them (unless later evidence is overwhelming that they were wrong).  Doing this requires soft skills (i.e. interpersonal skills and facilitation skills), not technical skills.  We discuss these skills further in the sections below.

“Make the decisions with the team:” 

What goes wrong in team dynamics?  Frequently, different members just want different objectives and are not open to listening to alternate objectives.  Equally often team members will argue about how an objective should be reached, not what the objective is.  Surprisingly often the team will actually agree, but argue vehemently about the words used to describe either methods or objectives (author Hamlen likes the description of this as “being in violent agreement”).

There are a number of methods to bring a team to consensus.  We have already mentioned that many of the “tools” taught in Six Sigma and Design for Six Sigma are really disguised methodologies for arriving at consensus within a team.  If these are used well, they are powerful.  Instill these methodologies within your organization and use them.  If you find it challenging to achieve that level of consensus within your organization, bring in a trained facilitator to assist you.

One powerful practice that works at any time to build understanding and acceptance of multiple perspectives is “active listening.”  Active listening helps overcome the unconscious cognitive “filters” with which we all operate[3].  What a person says is not necessarily what they are thinking; what a person hears is not necessarily what another person said; what another person responds with is not necessarily directly related to what they heard, and so on.  This is the core source of the garbling of messages or stories always found in the “telephone” game[4].  Often it is these unconscious filters that drive the occurrence of “violent agreement” mentioned above.

Executed correctly, active listening is a mechanical practice, but is striking in its effect.  To practice it, do this: as a listener, listen to the other person with the intent to say back to them what you thought you heard.  Don’t respond, don’t argue, don’t judge.  Then say back to them what you thought you heard.  Say something like “what I heard you say is …. “  If you get it wrong, they will let you know!  Keep trying.  Have the first person re-phrase what they said – and concentrate on trying to re-phrase your interpretation of what they said.  Eventually you will “connect” with true understanding.  You will know when you have hit that point because you both will experience a physical reaction: a sigh of relief, a sense of a “punch in the gut” or something similar.  Combined with this is an emotional feeling of “oh my … I get it” (or “they get it”).

This is powerful for two reasons.  First, it drives a real sense of “feeling understood” on the part of the person who is trying to get their point across.  Paradoxically, their “feeling truly understood” opens the door to their acceptance of an alternate viewpoint.  Second, it drives a real sense of “understanding” on the part of the second person (the listener).  Again, this sense of “truly understanding” drives more acceptance of the first person’s alternate viewpoint.  All this when the two might have started out vehemently disagreeing with each other.  Better than yelling and pounding on the table … no??

By using this and other decision-making methods, the team is involved.  That involvement creates their buy-in and commitment to the decisions and objectives.  That buy-in breeds team energy, involvement, and ownership of the objectives by the team.

“… trust those decisions as sufficient to the needs at hand:”

There is no magic formula here, simply the faith that your people are good – and the clear majority are.  Their experience and perspectives are real and have worth.  Lean has a practice … “the wisdom of the team” … that explicitly recognizes this.  Also, the entire team needs to accept and recognize that they are not after a “best” or “optimum” or “fastest” solution (or set of requirements).  They are after a solution that is sufficient to meet the objectives of the program, and which they can execute.

“… and stick to them” (the decisions):

All team members, especially the leader, need to reinforce to each other (and to all comers from the “outside” including incoming new members of the team) that previous decisions have already been made.  They cannot be altered.  To revisit and to debate old decisions takes time and dilutes the focus of the team (whose members need to be meeting objectives).  To remain so focused takes integrity, commitment, and a certain amount of courage on the part of the team members and the leader – but the alternative is unacceptable:  increased cost, project delays, project cancellation, and loss of a high-quality final product. (Again, an exception to this occurs if overwhelming evidence of a need to change direction arises).

In conclusion, because it is so important to truly understand and act upon, we reiterate the following point: our biggest challenges to achieving high quality in our project and design objectives are not technical.  Truly recognizing this, using the methods discussed above (and others) to achieve team cohesion and focus, then consistently and consciously resisting changes to that focus is one of the most powerful things a team can do to complete a design project resulting in high-quality product.

© 2017 DPMInsight, LLC all rights reserved.

About the Authors:

Cushing Hamlen

Over 27 years of experience in industry, including 20 years with Medtronic, where he worked and consulted with many organizational functions, including research, systems engineering, product design, process design, manufacturing, and vendor management.  He has also worked with development, regulatory submission, and clinical trials of combination products using the pharma (IND) regulatory pathway.  He has been extensively involved with quality system (FDA and ISO) use and design, and is particularly concerned about effective understanding and use of product requirements and design controls.  He has formally taught elements of systems engineering, design for six sigma, Lean, and six sigma.  Cushing has degrees in chemistry and chemical engineering, is certified as a Project Management Professional, is certified as a Master Black Belt in Lean Sigma, and is the owner/member of DPMInsight, LLC (www.dpmillc.com).

Bob Parsons

Over 26 years of experience in leading Quality Assurance, Validation and remediation efforts in FDA regulated Medical Device and Pharmaceutical industry. Experience includes product development life cycle management from initial VOC through New Product Introductions (NPI), sustainable manufacturing, and end of life product management.  Technical expertise in quality system gap assessment, system enhancement, alignment and implementation of all quality elements including design controls, risk management, purchasing controls, change control and post-market surveillance.  Regulatory experience includes; ISO 13485, 9001 and 14971 certification, providing guidance for FDA PMA/510K and CE clearance, designated Management Representative, company representative and lead during FDA and ISO audits, 483 and warning letter resolution with experience working within consent-decree environments.  Bob currently supports various organizations in remediation and compliance projects through Raland Compliance Partners (RCP) www.raland.com .

Michael B. Falkow

Michael Falkow is a Quality Specialist with Raland Compliance Partners. He has served as a regulatory compliance and quality assurance executive with multi-facility/international companies and was an FDA Compliance Officer and Senior Investigator/Drug Specialist.  Michael has subject matter expertise for quality and regulatory compliance, quality auditing, quality assurance, quality control, supplier evaluation and certification, and compliance remediation.  He has been approved by FDA as a GMP certifying authority and is qualified to provide Expert Witness testimony for GMPs.  Currently – Adjunct Professor at Mercer County Community College – teaching courses on Clinical Development for Certificate Program in Clinical Research as part of Drexel University’s Masters Degree in Clinical Development.

 

[1] “Gold plating” is a wonderfully descriptive term used in project management to describe functions or features added to a design that are not linked to a product requirement.  They are extraneous to achieving the objective of the design – adding cost and complexity.

[2] A later planned article in this series, “Its All in the Story” will cover the issues around documentation of the design process.

[3] We seem to prefer to think of ourselves as engineers and scientists as rational in our listening and decision-making processes.  Much research shows clearly that we are not.  We have previously mentioned the book “Thinking, Fast and Slow”, Daniel Kahneman, Farrar, Straus and Giroux, 2011.  We highly recommend it as a both enlightening and humbling read.

[4] The “telephone game,” apparently known internationally as “Chinese whispers.”  See: https://en.wikipedia.org/wiki/Chinese_whispers

Leave a Reply

Your email address will not be published. Required fields are marked *