Home > Articles

  • Print
  • + Share This
This chapter is from the book

Soft Causes of Poor Reliability and Durability

What is reliability? What is durability? Here are useful definitions:

  • Reliability: Acceptable quality delivered consistently over time, under specified operating conditions
  • Durability: Acceptable product life, under specified operating conditions

So we focus on achieving the required quality, as perceived by customers, and on keeping it stable under the operating conditions of the various product applications.

These definitions don't have the rigor associated with being testable and measurable, but they are useful when thinking about reliability and durability at a high level. In Chapter 2 we present a definition for reliability that has statistical rigor.

Fundamentally there are two categories of root causes of reliability problems: "hard" causes and "soft" causes. Hard causes are in the technical elements of the product's design and of its manufacturing and service processes. Soft causes are in the human behaviors of project teams and in the management of the development process.

Many of the tools and processes in this book address the hard causes. Soft causes focus on opportunities for project leaders and management to enable excellence in execution and to avoid being the root causes of failures in project support, cross-functional integration, and teamwork.

Your process capabilities assessment may identify soft causes such as

  • Project plans that are not based on sound strategies or cross-functional dependencies
  • Production-intent designs specified before robustness and integration have been developed
  • Product requirements that are neither complete nor stable (e.g., "feature creep")
  • "Seat of the pants" decisions that increase project risks
  • Selection of design concepts that lack sufficient capabilities or initial robustness
  • Technical deliverables that lack clear expectations at a project milestone
  • Development teams that lack process discipline or are complacent about their capabilities
  • Project teams that are not able to speak truth to power or ask for help
  • Project plans that do not apply lessons learned from past projects
  • Development budgets that are reduced by ad hoc decisions external to the project

To the extent that your capability assessment recognizes these or similar problems, effective solutions can be developed. The literature on product development includes references that can provide additional insight into soft causes. For example, Robert Cooper 6 has characterized many things that successful companies do well. An interpretation of these, in the context of your business model, can help you design probing questions for your assessment. Don Clausing 7 describes many fundamental engineering methods and echoes the concern about soft causes in his description of "The 10 Cash Drains." You may recognize many of them as root causes in your own business. Let's look at our list of soft causes in a little detail.

Inadequate Project Management Plans

A development process to achieve higher reliability should follow strategies chosen by the project to have the highest probability of success. It may leverage mature designs. It may be dependent on the development of specific technical concepts achieving prerequisite robustness. It may collaborate with other companies that have necessary and complementary technical capabilities. It may depend on extensive modeling or experimentation in the early development phases. In whatever way the strategies are intended, the project management plans must then reflect their relevant activities, dependencies, timelines, milestones, and resources. The plans have to show how the strategies will be implemented. If the resources or funding is not available, the plans may not be achievable and the strategies may not work.

Another concern is that the project management plans must deliver key parameters to the project's business plan. For example, if the plan to achieve the required reliability is not acceptable or achievable, the initiative to achieve the reliability requirement is set up to fail. So if the project plans are not achievable, the business plan also is not achievable and the project should not be chartered.

Inadequate Development of System Integration and Robustness

This is a critical concern for reliability development, being part of the foundation for the familiar guidance to "achieve quality early." To the extent that these criteria are not satisfied, additional risks are incurred and the objectives for quality, reliability, and durability are in jeopardy, as are those for schedules and cost structures.

The evidence of robustness is the specification of critical design parameters that have been demonstrated to control the mean and standard deviation of performance under expected stressful conditions. The specification and configuration control of these set points are the objectives of Critical Parameter Management (CPM). During the product design phase these functional parameters are converted into design parameters suitable for product manufacturing and service. Without them, there is no sound basis for the specifications of a design.

Important actions include these:

  • Technical concepts should be developed to be robust for the application prior to becoming baseline for the product development project.
  • Subsystems should be developed to be robust within the system architecture prior to being integrated with other subsystems.
  • Robustness should be optimized at the system level in order to specify the parameters that must be controlled by the production processes.

The strategy for robustness development must incorporate an understanding of the roles and benefits of specific methodologies, many of which are discussed in later chapters. From a project management viewpoint, sufficient time needs to be allocated for the selection of the best design concepts and for the planning of experiments, avoiding a rush to cut metal and to build prototypes prematurely. Too many prototypes, built without the learning from previous generations, contribute to Don Clausing's concern for "hardware swamps." The rush to build-test-fix may satisfy management's desire to see things happen but may be contrary to sound engineering.

Effective product development is analogous to applied systems engineering. It follows a disciplined process of developing linked information and decomposing it to be useful at the various levels in the system hierarchy. Manufacturing and service functions are considered to be part of the system, as are the procedures for users of the product. The development process includes the flexibility to make changes easily within the system and to freeze elements upon which other developments are dependent. Although it is a disciplined process, it should be very adaptable to the technical and business characteristics of a project. The leveraging of existing information and designs is prudent and efficient, while ill-advised shortcuts introduce risks and can sabotage the project.

Changing Product Requirements

Your engineers create solutions to requirements that are understood in the technical language of their design concepts. The origins of these requirements fall into three fundamental categories:

  1. The needs and preferences of your customers in selected market segments
  2. The standards and mandates imposed internally by your company
  3. The government regulations and industry standards for your markets and countries

Ideally these requirements are defined and clarified in the initial development phases and, in the ideal case, approved and frozen. In practice, life is not that easy. Requirements are vulnerable to misinterpretation, internal biases, lack of insight, disagreements, conflicts with each other, risks for achievability, and changing market situations. Feedback from customers may prove the initial requirements to be wrong or ambiguous. Your experience adds to this list. The consequences can range from being trivial to disastrous. If the requirements are vulnerable to changes, engineering is shooting at moving targets with an increased probability of major consequences for their delivered quality, costs, and schedules. If the requirements lack insight into the real intentions of their application, or lack clear differentiation from competitive products, the product and price positioning are in jeopardy. Failure to comply with regulations or industry standards can be a barrier to market entry. There is very little forgiveness.

Good practices are well developed to enable engineering and customers to work together so that designs not only solve the actual problems but also delight customers in ways that establish competitive advantages. Useful tools can enable the thorough and accurate translation of requirements from the language of customers into the technical language of engineering. They can then be decomposed to be applicable at the levels of subsystems, components, and manufacturing processes. Agile strategies for product development enable teams to react to late-arriving changes in requirements and to feedback from customers' tests of prototypes without dramatic consequences for schedules and costs.

It is the job of development teams to design the basic functions of the product, specifying the controllable parameters so that the product transforms the customers' inputs into desirable outputs, in spite of stressful factors that can cause deterioration or failure. Figure 1.1 illustrates this simple viewpoint. It's then essential for development teams to understand the input/output relationships in the applications and the uncontrollable stresses that can affect them.

Figure 1.1

Figure 1.1 The requirements for a product's output attributes are driven by customers (VOC), as well as by internal mandates (VOB, VOT) and regulatory standards (VOM).

There are two fundamental concerns that project leaders need to address:

  1. There is a tendency for engineers and management to believe that
    1. They already know more than their customers
    2. The process for understanding the voice of the customer (VOC) is too expensive and time-consuming, or it places the confidentiality of the project in jeopardy
  2. Requirements can also be driven by "voices" other than those of customers (VOC):
    1. There is the "voice of the business" (VOB), which tends to demand lower development costs, shorter schedules, and lower production costs, but often without comparable concerns for satisfying customers. Lean product development and sound strategic decisions early in the process align with this mandate. Start the project earlier, instead of depending on schedule pressures to compensate for delayed decisions.
    2. There's the "voice of technology" (VOT), which tends to modify requirements to reflect those capabilities that can be delivered within the cost and schedule constraints. Another version of VOT is the "technology push" scenario that assumes, often naively, that customers will benefit from a new technology because it's new.
    3. There's the "voice of marketing" (VOM), which tends to push a wide range of requirements focused on opportunities for current sales and market share. These can be a reaction to the latest market information and to sales challenges with current products.

These additional sources of requirements are not to be ignored. The worst case of technology push assumes that the benefits of the product are needed, that customers will accept and pay for whatever capabilities you deliver, and that there are no competitors. This is often called a "WYSIWYG" product, that is, "What you see is what you get." Of course, in a competitive market that strategy doesn't work.

In many cases there are valid and reasonable strategies to shortcut the VOC process. It may be that a few key people have more insights about future markets than do current customers. That's a gamble that may pay off. The challenge is to know when a rigorous VOC process must be included in the project plan and how to get more benefits from the investment in its process.

Risk Management

Many decisions are made during a product development project. Good ones clarify the direction of the project, enable the progressive freezing of information, and reduce risks. However, business and technical pressures can promote risk taking, even reward it. Risks are problems that have not yet occurred but might occur in the future. The probability of their occurrence is uncertain, as are their expected consequences for customers or for the company. When problems actually do occur, projects know that they have to be dealt with in a manner appropriate to their consequences. However, potential problems that have not yet occurred tend not to get the same deliberate attention.

Another way to say this is that problem correction is expected and rewarded, whereas problem prevention is a quiet competency that can go unnoticed. Problem correction late in the process tends to cost more than problem prevention. Excellence in achieving schedule milestones and the objectives for reliability and durability, for example, often is rooted in the capabilities of reducing risks, that is, avoiding the problems that consume valuable time and resources when they can be least afforded.

Good practices for managing risks reserve some capacity in resources to identify risks and to implement preventive actions, where justified. Contingency plans are the alternative. These are preplanned actions that will be taken to compensate for the consequences of the problem, when the problem does occur.

Collective wisdom and functional understanding are organized to identify risks and to characterize their expected consequences and probabilities of occurrence. This understanding can be based on experiences with previous projects, on specific technical or business insights, on scenario planning, or on other techniques. Often the foundations for a lower-risk project are put in place with decisions that are made in the early development phases, such as the selections of the development strategies, the system architecture, its design concepts, and their enabling technologies. The concerns increase when significant risks are ignored and risk taking is rewarded. But what are the costs? And who pays for them? For example, decisions based solely on reducing manufacturing costs can result in poor product quality or reliability, higher life-cycle costs, or a loss in market reputation.

Imagine a development project that achieved its requirements for quality, reliability, durability, production costs, and schedule, with no late crises that jeopardized its graceful market entry. Calculate the costs of delayed market entry, and then ask how much you could afford to invest in identifying risks and preventive actions. Remember the wisdom in "Pay me now, or pay me later."

Immature Baseline Technologies

Baseline design concepts are chosen in the early development phases. What criteria are used for their selection? How dependent on them is the product architecture? For new or adapted design concepts, what happens if their capabilities fall short of their expectations for the application?

The concern here is that new technical concepts may be chosen for reasons that are independent of the value they can deliver to customers. It may be that engineers favor a particular design concept for purely technical reasons. Possibly it enables lower costs or an attractive architecture. It may be one for which they have personal preference. It might be the key to major increases in reliability and durability. Fine, but is it ready to be commercialized by a product development project? Does it have functional parameters that control its performance and variability? A disregard for this question tends to place technology development within a scheduled product development project, imposing additional risks. A very difficult situation is created when the product's architecture is entirely dependent on a design concept whose technologies are immature, that is, neither superior to alternatives nor robust for the application.

We remember a disastrous project. The product's architecture was entirely dependent on a design concept that enabled a rather compact system configuration with lower power consumption and reduced acoustical noise. However, the control parameters of the design could not be replicated by available manufacturing processes. In robustness terminology, the process could not be maintained "on target with minimum variability." In addition, the environmental stresses from the product's applications caused shifts in the functional response that customers would not tolerate. Fighting these problems continued well into production. No alternative designs were available, primarily because the system architecture could not be adapted. The root cause of the problem was a decision made very early that "bet the farm" on the hope that clever engineering could compensate for a failure of technology development. It could not. The costs were enormous!

In preparation for its commercialization, a new technical concept must be developed to be superior to available alternatives and to be robust for the range of intended applications. These criteria say a lot. Products often compete with their technologies. What makes them superior to available alternatives? What does it mean to be robust for the application? Good practices include two basic deliverables:

  1. A stream of alternative technologies developed in anticipation of the needs of future product development projects
  2. An unbiased selection process that places available alternative concepts in competition, with selection criteria that include demonstrated performance and robustness relevant to the intended product applications

Examples of "available alternatives" can include a current design already in production, an analogous mature approach that can be adapted to a new application, a design available from a partner or competitor, or an alternative new technical concept developed in parallel. A selection process that is vulnerable to the loud, bully voice of a concept advocate will lack the objectivity that is necessary.

Lack of Clear Expectations

Management has substantial power to guide a development project and affect its outcome. Certainly they charter projects, review their progress, provide resources, and make decisions. They also have the role of setting clear expectations. These expectations may focus on functional excellence. They may demand rigorous integrity in data that are needed to support decisions. They may express a bias for costs or schedule compliance. They may emphasize concerns for risks, that is, reductions in uncertainty. In the absence of clear expectations, development teams are left to define their own acceptance criteria.

Routine conversations with management, as well as those during project gate reviews, are opportunities for these expectations to be clarified and reinforced. If the discussions are entirely business-oriented, the technical expectations are at risk. If the discussions are entirely technical, the development teams can tend to forget that they are managing an investment that is the generator of a new value stream with expected returns to the business.

The challenges for management are substantial. For the purpose of this discussion, they can include the need to

  • Maintain an accessible and interactive relationship with development teams
  • Ask probing questions with both technical and business insight
  • Recognize good answers and understand their metrics
  • Make data-driven decisions so that their customers win
  • Set clear expectations for the effectiveness and efficiency of future project work
  • Focus on the "critical few" risks that are most important to the business, rather than on the many potentially trivial "issues" that people tend to push on management
  • Accept action items to enable the predictable progress by development teams
  • Reinforce both flexibility and discipline in standardized development processes

Certainly there are other items for your list, but the important point is that your development teams listen to management. So management needs to be clear about the signals they send.

Lack of a Disciplined Process

Complacency can be a handicap for those companies that have dominant technologies, a high market share, admirable profitability, or a history of successful product launches. With deep pockets, money can be thrown at problems. An unfortunate side effect is that the realities of inefficient processes, growing competitive disadvantages, and customers choosing other companies' value propositions, among others, can remain outside a company's consciousness. Fundamental changes in the marketplace can be overlooked. Your company can become vulnerable to its own successes.

In these situations, the problems that have soft causes become much more fundamental than just product performance or reliability. Your basic business model may no longer be viable. Instead of your capability assessment providing guidance for continuous improvements, it may identify the need for major reengineering projects. Companies that survive over the long run often practice an ongoing reinvention of themselves. Those that do not often find themselves no longer being significant players in the market, or in some cases no longer existing. Although this concern is far beyond the scope of this book, to the extent that it exists it can be a major handicap to the development of reliable new products.

Inability to Speak Truth to Power

In the preceding discussion about the setting of expectations, the advice has been for management to have an "accessible and interactive" relationship with development teams. The absence of this relationship can easily jeopardize the ability of teams to deliver on their value proposition.

Suppose, for example, that management gave clear expectations that they did not want to hear bad news, particularly at gate reviews. This is a "shoot the messenger" scenario. How would development teams behave? Management may intend sternness and ridicule to motivate improved deliverables. On the other hand, such a policy may also prevent bona fide risks from being revealed or significant decisions from being based on the correct data. Project teams may not be willing to acknowledge problems, hoping to correct them before the next gate review. Worse yet, the development teams would be set up to be scapegoats for resulting failures. That situation is neither constructive nor efficient.

The quality leader Dr. W. Edwards Deming 8 was prescient when he urged management to "drive out fear." Rewards should go to those who are open and honest about the status of their project. Management needs to understand the truth early, when there's still time to react without jeopardizing the project's success.

This same intimidation may motivate project leaders to withhold any requests for additional resources or guidance. They may be convinced that it would reflect poorly on their own leadership capabilities. But who pays for this mistake? Imagine how constructive would be the process that brought the right resources to the right problem at the right time, regardless of a naive plan that was established sometime in the past. Independence and self-confidence are healthy attributes, but they can work against you. Certainly it's better to address problems when they are small, when their corrective actions can be managed easily. In his memoir, Harold Geneen, 9 the executive who built ITT into a multinational conglomerate, described his expectations on being open about problems. He felt that hiding problems was a waste of time, time being the one irreplaceable resource that his organization had. He expected his staff, when faced with difficult problems, to be open and to seek help early in the belief that the collective experience, wisdom, and skills of the organization usually trumped those of the individual.

When we work to solve problems, time is our most important asset. Letting too much time pass before getting help on a tough problem makes it more likely that schedules will suffer and that the delivered product performance and reliability will fall short of expectations.

Failure to Implement Lessons Learned

Many organizations engage in the struggle to get a new product to market faster but do not allocate time afterward to learn about what went well and what did not go well. These lessons learned are important contributors to continuous improvement. Without organizational learning, the mistakes of the past tend to be repeated. This can generate inadequate technical and business results across the portfolio. It can also demoralize the workforce who see the same mistakes being made over and over, and who will wonder if product development work will ever become less stressful.

A key element of organizational learning is the clear intention that the evaluation process not be a negative one, that is, one that is perceived to place blame on individuals or teams. To the extent that it is managed to be blameless and clearly intended to build wisdom into follow-on projects, with a top-down commitment to act on the results, it will be a healthy and anticipated process.

Inadequate Development Budgets

If teams are required to shorten development time and also to reduce their resource budgets, they may have objectives that are overly constrained. For example, it is often the case that an overrun in the project's development budget will have only a small impact on a new product's profitability. However, spending more money on resources to commercialize the product earlier, with higher quality at launch, can enable higher revenues and contribute to lower manufacturing and service costs. Unfortunately, budget compliance often gets more attention, probably because it is more easily measured and is a familiar measure of management performance.

This discussion of common soft causes of problems reinforces the notion that product development, although often perceived to be a set of technical activities, is managed in the context of a wide range of processes and behaviors that have the potential for either positive or negative consequences. That depends on how they are managed. The assessment of your company's capabilities and of the related needs for their improvement must include these soft concerns as well as those more technical hard causes.

Throughout this book we intend to shed light on both categories for improvements, particularly to the extent that they can contribute to the development of improved product reliability.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020