top of page

SEARCH

Find what you need

564 results found with an empty search

  • Compliance: Obstacle or Opportunity?

    Let me start this by providing some context. I am a professional engineer who studied electrical / computer engineering back in the 80’s. You could say that I found compliance the long way around. As it turns out, compliance is not so different from engineering at least the way it is now. For most of my career I designed, built, and deployed systems to support compliance. In my early days, I developed systems for testing integrated circuits at both the wafer and packaged goods stages. You could say that this was dealing with a type of compliance: conformance to technical requirements and specifications. I then went on to implement quality management systems, document management, records management, data management, product life cycle management (PLM), DHF and DMR systems, ISO, and so on across multiple industries across North America. These had more to do with supporting compliance commitments instead of meeting compliance directly, but important, nonetheless. What I found, which brings us to the topic of this article, was that compliance was considered as an extra layer, an extra process, and extra program for many and most organizations and still is for the most part. Compliance you could say was all about meeting all the requirements over and above what was needed to get something to work such as quality, safety, security, sustainability, and so on. These are still requirements. But for some reason we didn’t, and we don’t treat them that way. We see these requirements instead as obstacles and in the way of getting something to market, a business launched, or a service delivered. And here's the thing – we still do. Compliance as Imagined Compliance as it was imagined, prescribed, and enforced was not welcomed and at most tolerated. And yet at a fundamental level was no different from designing systems to meet product, business or services requirements. So what is going on? If that wasn't enough of a question to answer, organizations decided that if these “other requirements” were going to be addressed it was going to happen at the end of the production process. Not earlier on as part of design. We don’t want to hinder innovation they would say. Now if you were in manufacturing, you were not happy with that approach as these extra steps would delay getting product out the door. This was a source of much of the push back and tension similar to what product engineers and designers are experiencing today when asked to consider "non-product" requirements int their design. After years of doing compliance this way no wonder people don’t like compliance. Not only that – they don’t want it. In fact, for those familiar with LEAN, you will know that it has a blind spot when it comes to compliance. LEAN views inspections, for example, as non-value add, a waste and something to eliminate. And guess what, lots of people view compliance this way. I knew there had to be a better way to do compliance where it was a value-add and not a waste which was the genesis for founding Lean Compliance – you could say – to correct this blind-spot. But this change could only happen if and only if there was a change in perspective. Back to the question: Compliance: Obstacle or Opportunity? If we are keeping score, I think compliance as an obstacle is winning. But let’s unpack this some more and see if we can discover the root cause of why this is the case. To help with that it is worthwhile looking at the tension between business and compliance which is not new thing and something we understand quite well. There have always been priority differences between what the business wants and what compliance wants. In fact, the way I stated these earlier telegraphs the cause of some and perhaps most of this tension. Business and compliance objectives for many are seen as mutually exclusive and not aligned to the same goals. At least, that’s how it looks to most. Back in the 90’s when ISO 9001 (the quality management standard) was introduced it was all about inspections and quality control. Compliance was measured by conformance with product specifications, which in turn would help identify defects, that would be corrected or at least measures put in place to prevent them from occurring again. We were contending with quality at the event horizon — the place where risk becomes a reality – and that is what a defect is. Defects are the effects of uncertainty in the production process or in the design itself that have been realized. Now, if you were a production manager how could you not see all the inspections and audits as getting in the way. The delays were not the real problem. It was what was discovered that was. Quality control was exposing what was hidden and made it visible. The Root Cause and Antidote The real problem you could say was that there was a misalignment of priorities that was made visible by the introduction in this case of a quality standard. For production the goal is to meet schedules and to ship product on time. All these other steps: inspection, quality control, corrective actions, etc. tacked on at the end of the process would and did cause delays and cancelled orders. So no wonder compliance was seen as a tax on production, an obstacle to getting on with the business. If we don’t ship on time we will lose customers which was a real concern. I don’t think this perspective and tension between production and compliance has changed over the years. In fact, I was recently had a conversation with a high-tech company in Europe, and this was exactly the problem. Competing priorities. Competing goals. Nothing has changed. But compliance has. Let me explain. Since the 90’s, and for all those that effectively manage quality, some would experience less defects, fewer delays and in fact shorter cycle times, and something else – they would experience customers who were more satisfied with their products. Imagine that! Instead of losing customers, they were gaining them. Even at the edge, at the event horizon, the last line of defence; compliance had an impact. But, how did this work? How was compliance able to do that? And now we get to the heart of the matter – the power of compliance. Compliance presents a process by which a standard could be used to evaluate the current level of conformance, in this case, with quality requirements not technical requirements. We already were doing technical requirements and accounted for it in our product designs. Compliance added a new benchmark – a new design objective for engineering. That’s what compliance does. It set’s an ideal for us to achieve: better quality, better safety, better security, better sustainability, you can call this drive – operational excellence – if you like. These standards, not the management standards, but the ideal of what we want, act as a measuring stick. They make what is invisible visible. However, that is only half of its power. Exposing gaps creates new problems to solve, new objectives to improve, and even new opportunities to innovate. Taiicho Ohno the father of Lean was known for saying, “without objectives there are no improvements”. Without a standard there are no gaps. When there are no gaps we have no problems to solve – no need to innovate. As it turns out: Compliance creates the opportunity for innovation. This is the real power of compliance. Compliance is not a set of check-boxes to tick off or to feel ticked off about. Instead, the purpose of compliance is to drive the organization towards better outcomes. Something we can and should all be aligned with. For that is what compliance is all about – alignment – staying on course, on-side, on target, and on mission. Moving Back from the Event Horizon This notion of alignment has been applied throughout the entire value chain. The body of knowledge has expanded to safety, security, sustainability, and many other fields. We now have a better understanding of the nature of obligations, how to contend with uncertainty, and how to regulate not only outputs but outcomes - the field of cybernetics of which control systems engineering is part of. Compliance has progressed and has moved away from the event horizon where – r isk becomes a reality – and has moved towards the source of risk itself. The place where – uncertainty creates the opportunity for risk. It is about being proactive and preventing non-conformance in all its shapes and sizes. Compliance is also still about regulating – something that is often forgotten. Compliance is now regulating how and what we do to increase the probability of the outcomes we want and decrease the probability of outcomes we don’t want. In fact, compliance helps us avoid obstacles and threats, and helps us now to enable and exploit opportunities to achieve mission success. This is why requirements are no longer just technical. They have expanded to include all the other requirements associated with risk. That is why compliance needed to change and so should the way we do engineering. Engineering needs to learn to innovate across all requirements not just the technical ones if we want to stay ahead of risk. This requires thinking in engineering terms such as: Design Thinking, Systems Engineering, Model Based Engineering, Digital Twins and Threads, Risk-based Thinking, and so on. What do you think now? Is Compliance an Obstacle or an Opportunity?

  • The Problem with Assessments

    Assessments are the fuel that power both step-wise and continuous improvement engines and this is no different when it comes to risk & compliance programs. Assessments help to identify the gap between where you are now compared to where you intend or need to be. The problem is that not all assessments are the same, and many do not assess the things that really matter. The Assessment Construction The purpose of an assessment is to answer the question, "Are we there yet?" so that adjustments (i.e. improvements) can be made to successfully get to there . What there means may manifest itself in many ways, for example: The distance between where we are compared to our destination . The speed we are travelling compared with what is needed to arrive at our destination on time. The amount of fuel remaining compared with what is needed to get to our destination . For an assessment to be effective we must have a stated goal that defines what we want to achieve along with a way to measure our progress towards that goal. In our previous example there are several goals: Zero distance from our destination – this is a Measure of Effectiveness (MoE) The trip will not be successful if we don't reach our destination defined as a distance of zero between were we are and where we want to be. Minimum speed to reach our destination on time – this is a Measure of Performance (MoP). We need to have the capability to travel at or above the minimum speed limit to reach our destination on time. We also need to sustain that level during the trip. Non-zero fuel level for the duration of the trip – this is a Measure of Conformance (MoC). To be successful we must ensure that we do not run out of fuel. This may require extra fuel (i.e. margin) to address uncertainty along the way. An effective travel plan will include a gap assessment conducted as often as needed to make certain that sufficient progress is made towards the desired destination, sustainment of the minimum speed, and that the fuel tank never reaches empty. The Assessment Conflation Taiichii Ohno (the father of LEAN) is known to have said, "without objectives there is no improvement," or in other words you need to have a gap, but not just any gap. The gaps you need to assess are the ones connected with your goals. Every management system standard connected with quality, safety & security, environmental and regulatory programs requires the establishment of objectives. These are instrumental goals towards ultimate goals such as zero incidents, zero harm, zero emissions, zero pollution, zero violations, and so on. To make progress against these objectives each company must perform at targeted levels often described in internal procedures and guidelines. A full evaluation of a management system will therefore include: Conformance Assessments (i.e. audits) are conducted to assess work-as-prescribed against work-as-done demonstrated by evidentiary artifacts which may include intermediate or final outputs of critical to compliance processes covering: quality, safety & security, environmental,and regulatory objectives. Conformance assessments answer the question, "Is the system following the standard?" Performance Assessments are conducted to verify actual performance against planned performance of critical to compliance capabilities. Performance assessments answer the question, "Does the system have the capability, competency, and capacity to advance objectives?" Effectiveness Assessments are conducted to validate progress against stated compliance outcomes (ex. zero violations, zero harm, zero incidents, etc.) Effectiveness assessments measure the results of a compliance system by answering the question, "Is the system having an impact on our compliance outcomes?" Audits are traditionally used to perform conformance assessments evaluated against a given standard. These standards are often externally defined with some requiring third-party certification. The purpose of the audit is to identify gaps against the standard that will need to remediated to achieve third-party certification or quality control criteria. This assessment focuses on confirming the existence of policies, procedures, and practices along with process outputs. However, what audits do not do is tell you whether or not your compliance system is performing or effective at advancing your goals and objectives. The latter requires a contextual evaluation against a company's targeted outcomes of their quality, safety & security, environmental, and regulatory systems. The Assessment Uncertainty There is one place where most of have experienced the impact (good or bad) of assessments and that is in the context of education and training. As part of making the grade a teacher will conduct tests throughout the year to measure a students progress culminating in a final exam to determine the grade. Performance in the final exam is often the largest contributor to the final grade which can be considered an outcome of a student's effort during the year. I remember during my university days sitting down for a final math exam. I felt good about this course. I had attended all of the classes, completed all the term exercises, and as a result felt ready for the final. On the day of the exam, I sat down, took a deep breath and waited for the start signal to begin the three-hour exam. Two hours went by and I had managed to work through all the questions on the exam page. Having completed the questions comfortably, I thought that all my preparations were paying off. I decided to use the remaining time to go over my answers and check my work. 50 minutes left. Everything was going as planned. I needed some scrap paper to verify some of my calculations and decided to use the back side of the exam paper. 45 minutes left. As I turned over the paper, my heart sank and then started to race. I saw another set of questions on the back side. How could I have I missed this? My performance on the previous questions would not be enough to pass the course let alone make a reasonable grade to advance the achievement of my engineering degree. Many organizations find themselves in a similar situation with respect to their risk & compliance programs. They do all the work to pass an audit, the front-side of the exam, but fail to turn the page over to work on performance and effectiveness. Unfortunately, when it comes to compliance obligations such as safety, it is too late to work on these after an incident or harm has been done. As for my exam, it was almost too late for me. I raced through the rest of the questions and barely achieved a passing grade. I promised to never let that happen again. The Assessment Conclusion Gap assessments are necessary to know what to improve provided you are measuring what really matters. While conformance assessments can tell you that you are missing a procedure and need to create one, they don't tell you how good a procedure is at achieving intended objectives. For this you will need to conduct performance and effectiveness assessments. These require contextualized comparisons between where you are now and the destination you have targeted which will be different for every organization. Of course, closing the gaps will not be as simple as creating a procedure. Closing gaps will require improving performance and effectiveness which need the application of problem solving, risk analysis, and change management, among other skills and capabilities. Progress towards risk & compliance objectives can only begin when companies turn the page to answer the other half of the questions. And remember, you still need to show your work! It's time to do more than just pass the course, it's time to make the grade.

  • Which Problem Should Compliance Be Solving?

    The question that compliance should be asking is not how do we move from spreadsheets to automation but rather how do achieve better outcomes form being in compliance. The former is a data-first mindset. Replacing spreadsheets with automated tools has some utility but it is not enough to stay ahead of risk and staying between the lines. This mindset turns the question into a data capture, storage, manipulation, and reporting problem. The latter is an outcome-first mindset. This turns the question into a benefits realization problem. It looks at what capabilities do we need to achieve targeted outcomes from our compliance, what resources do we need to achieve those outcomes, what obstacles are in the way, and how do we measure our progress. An outcome-first approach enables transformational change whereas a data-first approach will only at best produce the same results you currently have faster or at worst create a lot more work.

  • How to Support Your CCO

    A Chief Compliance Officer (CCO) is responsible for ensuring that an organization complies with relevant laws, regulations and to a broader sense – all stakeholder obligations associated with safety, security, sustainability, quality, environmental and internal commitments. The role of a CCO is crucial in ensuring that a company operates ethically and responsibly while minimizing the risk of legal, financial penalties, and loss of stakeholder trust. While a CCO has significant responsibility, they cannot fulfill their duties alone. They need help from other members of the organization to ensure alignment with organizational values and compliance with policies and procedures. This is because the outcome of compliance requires a collaborative effort that involves everyone in the organization working together. Additionally, a CCO needs help to fulfill their duties due to the complexity of compliance regulations and the constant changes to these regulations. Staying current with regulations and industry best practices requires constant monitoring and adaptation. Therefore, a CCO relies on other professionals within the organization to provide insights, identify risks, and recommend corrective and proactive actions. A CCO also needs assistance in implementing and enforcing policies and procedures. They may need to work with other departments such as human resources, legal, finance, and IT to ensure that compliance requirements are integrated into daily operations. However, for too long, many organizations have been managing their compliance in isolated siloes, only addressing issues after they've already occurred. This outdated approach is not only making the job of the CCO more difficult but also less successful. It's time to embrace a more proactive and integrative approach that takes a holistic view of your organization's capabilities. By doing so, you can stay ahead of the curve and ensure success in today's fast-paced business environment. A Proactive and Integrative Strategy For Compliance This approach involves several key elements, including integrating compliance into the organization's culture, taking a proactive rather than reactive approach to compliance, providing the necessary resources to enforce compliance, establishing clear communication channels, and adopting a culture of continuous improvement. First , the organization must integrate compliance into its culture. Meeting obligations and keeping promises must be a core value that guides the behaviour of everyone in the organization. Each person must understand their compliance obligations and take responsibility for adhering to the rules and regulations. By integrating promise keeping into the organization's culture, the organization minimizes the risk of non-compliance, reducing gaps in conformance and ensures sufficient performance to advance the outcomes of compliance: better safety, security, sustainability, quality, and stakeholder trust. Second , the organization must take a proactive approach to compliance. Instead of waiting for issues to arise, the organization should anticipate potential risks and take steps to mitigate them. This involves identifying areas of the organization that are particularly vulnerable to compliance issues and developing strategies to address those vulnerabilities. By taking a proactive approach to compliance, the organization can prevent risk as well as mitigate their effects ensuring the organization always stays between the lines. Third , the organization must provide the CCO with the necessary resources to enforce compliance effectively. This includes budget, technology, personnel, and training. The CCO should have access to the necessary tools and resources to monitor and enforce that obligations are met and promises kept. The organization must also provide training and education to employees to understand their compliance obligations and how to meet them. By providing the necessary resources, the organization supports the CCO in meeting their responsibilities which in turn helps the entire company keep all their promises. Fourth , clear communication channels between the CCO and other departments can support compliance. The CCO should be involved in all major decisions that could impact compliance, and other departments should consult with the CCO before making any decisions that could affect compliance. This ensures that compliance is considered in all decision-making processes and helps to minimize the risk of non-compliance. Finally , the organization must adopt a culture of continuous improvement. Compliance is not a one-time event but a continuous process. The organization should regularly review and assess its compliance program to identify areas for improvement. The CCO should work with other departments to develop and implement strategies to improve compliance continuously. By adopting a culture of continuous improvement, the organization provide the assurance that stakeholders require. Summary Compliance is crucial for the success of any organization, and the CCO plays a critical role in ensuring that the organization meets its obligations. However, they cannot do this alone or as an isolated part of the organization brought into the discussion after the fact. To support the CCO, the organization must adopt a proactive and integrative approach to compliance. This involves integrating compliance into the organization's culture, taking a proactive approach to compliance, providing the necessary resources, establishing clear communication channels, and adopting a culture of continuous improvement. By doing so, organizations minimize the risk of non-compliance and ensure it is able to continually stay between the lines and ahead of risk protecting value creation and engendering greater stakeholder trust.

  • Sustainable Development and Environmental Stewardship - Part 1

    This week we launched our “Learn with Me” program were we take a course together. The course we decided to start with is Sustainable Development (SD) and Environmental Stewardship (ES) provided for free by Polytechnique Montreal. This 4-week course introduces the topic and walks through 10 guidelines of sustainable development and environmental stewardship for Professional Engineers created by Engineers Canada in 2016. The first session began with us hearing from a variety of engineers, city planners, and others involved in sustainable engineering efforts. This provided the context of why this topic is so important. It also introduced us to important definitions: Sustainable Development - “development that meets the needs of the present without compromising the ability of future generations to meet their own needs” (Brundtland Commission) Environmental Stewardship - “the wisest use of the finite resources in nature to produce the greatest benefit while maintaining a healthy environment for the foreseeable future” (The World Federation of Engineering Organizations) Together, environmental stewardship is about keeping what we have, whereas sustainable development is about getting what we need. These definitions are intended to be practical and operational. They shape an objective to maintain a healthy environment at a cost but not at all costs recognizing that the environment will adapt and evolve. Sustainable engineering defines an approach to engineering to meet the challenges of sustainable development and environmental stewardship. Sustainable engineering assumes a broadened responsibility across the pillars of environmental, social and economic development. These pillars must be balanced to achieve a world that is livable, viable, and fair. The technical challenges alone that face sustainable engineering are immense. We learned using the IPAT equation that technologies will have to improve their efficiencies and emit up to 87% less green house gas for each unit of goods and service produced to achieve greenhouse emission targets. Clearly, there is much work to be done and considered. In many ways, in Canada, we have not done as much engineering as we used to. However, we now have an opportunity for that to change. Engineering needs to take on a more significant, broader, and intentional role if we are to achieve sustainable development and environmental stewardship objectives. To put all this into practice the national guideline on sustainable development and environmental stewardship for professional engineers outlines 10 guidelines for engineers: Engineers: Should maintain and continuously improve awareness and understanding of environmental stewardship, sustainability principles and issues related to their field of practice. Should use expertise of others to adequately address environmental and sustainability issues and enhance understanding and improve practices. Should incorporate global, regional and local societal values applicable to their work. Should establish mutually agreed sustainability indicators and criteria for environmental stewardship at the earliest possible stage in projects, and evaluate these periodically against performance targets. Should assess the costs and benefits of environmental protection, eco-system components, and sustainability in evaluating the economic viability of the work. Should integrate environmental stewardship and sustainability planning into the life- cycle planning and management of activities that impact the environment, and should implement efficient, sustainable solutions. Should seek and disseminate innovations that achieve a balance between environmental, social and economic factors while contributing to healthy surroundings in the built and natural environment. Should become engaged in a leadership role in the ongoing discussion of sustainability and environmental stewardship and solicit input from stakeholders and accredited experts in an open and transparent manner. Should assure that projects comply with regulatory and legal requirements by the application of best available, economically viable technologies and procedures. Should implement risk mitigation measures in time to minimize environmental degradation where there are threats of serious or irreversible damage but a lack of scientific certainty. Today these are voluntary for the most part. However, it is conceivable that in the near future “should” may be replaced with “shall” as governments strengthen their environmental commitment. Accepting responsibility is alway better when done voluntarily so now is the time for engineers to do just that. This after all is what engineers have always been good at –accepting responsibility – which is embedded in our code of ethics: The primary duty of engineers is to hold paramount the protection of public safety and welfare with due regard for the environment and societal values - Engineers Canada Code of Ethics I look forward to the weeks ahead as we continue to explore the topic of sustainable development (SD) and environmental stewardship (ES).

  • Compliance Compass To Make Certain You Are Always in Compliance

    The Hoshin Kanri method is a popular LEAN approach used to align strategy with outcomes. It uses what is called an X-Matrix that functions as a compass to ensure that all planned effort is working towards long term priorities and principles. The X-matrix is oriented in the following way: North : guiding principles, priorities or goals South : long term outcomes, results, or breakthrough objectives West : short term objectives, initiatives, or actions East : processes or metrics to improve The corners are used to map the correlation or contribution between each component of the matrix starting at the bottom and working your way around clock-wise. This is a great time of the year to get out your compliance compass and make sure that your plans are working towards better compliance. To help you do just that we created the following X-Matrix using The 10 Principles of Effective Compliance as the basis to guide initiatives towards better compliance outcomes: This compliance compass is available in XLS formats here . May it guide your path and help you make certain that you are always in compliance.

  • Assurance is an OUTCOME not an ACTIVITY

    Assurance is not an activity that compliance does or something that can be inspected into a business. It is an outcome that is created when stakeholders have confidence that an organization is meeting all its obligations today and will continue to be meet them in the future. This confidence is necessary for assurance and ultimately for trust to exist. That's why confidence levels are an important measure of success for all risk & compliance programs. Improving the level of confidence is therefore an important objective which often involves conducting audits to verify process outputs and validate program outcomes. However, conformance to procedures and processes, as important as that may be, are not enough to provide the necessary confidence for trust to be granted. Confidence is increased when companies take steps to make certain that promises are kept. This has more to do with improving the probability that the organization is heading in the right direction, operating between the lines, and is making progress towards its mission objectives. The best way that this is demonstrated is by having an operational compliance program to properly contend with obligation and operational risk. An effective compliance program will ensure that required capabilities and performance exist to meet all obligations today and in the future. These capabilities will include resiliency, sustainability, quality, safety, diversity, or any of the abilities that contend with the risks that matter to the organization. Measuring effectiveness of these capabilities is not something that traditional audit or assurance functions have done. However, this is what is now required to provide confidence that the business has a future. To improve the outcome of assurance the following questions need to be answered: What is the level of confidence that your organization will meet all of its obligations? What capabilities do you need to ensure that you will meet your obligations in the future? What measures can you take to make certain you can keep all your promises? What resources do you need to provide the necessary capabilities and measures? How will you evaluate your progress towards greater levels of assurance?

  • Risk-based Continuous Improvement

    Does your improvement process properly contend with uncertainty and risk? Continuous improvement in the form of Deming's wheel (plan-do-check-act) has helped organizations in recent decades significantly improve their business and manufacturing processes. Traditional PDCA is an iterative process based on four (sometimes more) stages: Plan: establish objectives and processes required to deliver the desired result Do: perform the previously defined plan. Check (study): data and results are gathered and evaluated against targeted goals, objectives, and outcomes. Act (adjust): actions are identified to address non-conformities, issues, and opportunities for improvement. Variations of this process exist and include: DMAIC, A3, Lean Improvement Kata, and others. Each one serves a slightly different purpose but what they have in common is that they focus on problems after they have manifested themselves. This makes continuous improvement a reactive process triggered by the presence of problems, non-conformance, or other issues. Risk-based continuous improvement is a proactive process that helps you anticipate, plan, and act to make certain that outcomes are advanced in the presence of uncertainty. The focus is on anticipating problems before they become a reality and is triggered not by the presence of issues but by the presence of uncertainty. Problem solving skills and capabilities used with traditional PDCA processes, for example root cause analysis, can also be used with risk-based continuous improvement. However, what makes the process proactive is the identification and assessment of uncertainty (the root cause of risk) along with the implementation of effective risk controls which are essential. It is the effectiveness of these processes that determine how well problems are prevented and opportunities are realized. It is with these that continuous improvement is most needed. Risk-based continuous improvement proactively contends with uncertainty and its effects on goal-directed endeavors. It is triggered not by the presence of a problem but by the presence of uncertainty. It is applied to each process affected by uncertainty along with the processes that anticipate, assess, and treat risk (i.e. risk controls) to improve their effectiveness.

  • Are You Being Nudged Into Compliance?

    The answer is yes and you have been for some time. Nudging is broadly used today in many domains including governments to addresses policy effectiveness and regulatory gaps, private companies to make employees more ethical, and in compliance to change safety, quality, and environmental cultures. Nudging can be effective and justified to get us to do what is good for us such as investing more for our retirement. Nudging can also be used to exploit our behavioral biases to achieve outcomes that we do not need or want. The use of nudging in compliance has ethical implications that need be to considered and addressed. Companies may not explicitly implement nudging yet still find themselves using technology that does which may not align with their own ethical values. Values of users are being replaced with the values of the nudge designers and this is a cause for concern. What is Nudging? Many people became aware of the theory of nudging when the book: "Nudges: Improving Decisions About Health, Wealth, and Happiness" by Richard Thaier and Cass Sunstein, was published in 2008. In their book, they define nudges as: "A nudge, as we will use the term, is any aspect of the choice architecture that alters people's behavior in a predictable way without forbidding any options or significantly changing their economic incentives." In essence, nudges use behavioral insights to influence behavior towards specific outcomes. Nudge theory has been applied in areas as diverse as: product placement, using opt-out versus opt-in strategies, and applying it to business management systems. We also see private companies introducing nudging aimed at making employees more ethical. More and more companies are considering the use of nudges as a proactive strategy to achieve compliance outcomes [8]. In Todd Haugh's paper on "Nudging Corporate Compliance" [5] he defines nudges in the compliance context: "Nudges are simple interventions designed to promote desirable choices— such as compliance choices—by taking advantage of psychology . . . [including] a growing list of mental shortcuts, cognitive biases, and psychological quirks that subconsciously influence, and often sabotage, our decisions. Nudges are designed to either harness or neutralize these tendencies, and help us make better decisions, by subtly altering the decision-making process or the mental context in which the decision is made" Neutralizing cognitive biases to make better decisions seems reasonable but harnessing these same biases to achieve a specific outcome has its problems. Critics of the use of nudging argue that they are short-term and do not help people make long-term behavior changes. However, while the effectiveness of nudging might be in question, there are other issues more pertinent to the ethics of using nudging in the first place. In the paper by David Colader and Andrew QI Lin Chong [7], they make the following argument: "Thaler and Sunstein implicitly assume that people would be better off with a choice architecture that encourages them to save more. By making this and similar assumptions, they are replacing their views for the consumer’s views. Our argument is that the explicit goal of nudge policy in this case should not be to encourage individuals to save more; rather it should be to give individuals the choice of whether they want a choice architecture that is more likely to encourage to save more. This is a subtle, but important, distinction that Thaler and Sunstein gloss over, and which underlies the difference between our non-paternalistic and their paternalistic nudge policy." The key point is that choice architectures inherently promote a set of values that may differ from those of the decision maker. This has critical implications when applied to making ethical decisions involving risk and uncertainty where it essential that the decision making process not diminish the autonomy or the accountability of the decision maker. It can be argued that too much "suggestion" may lead to holding the choice architects rather than the decision maker accountable which is not what we want or need. As a result, careful attention should be given to the use of choice architectures particularly those embedded in the technology (i.e. digital nudges) used to support and manage compliance. There are many ways in which choice architecture manifests itself in the digital environment. The most predominant is the use of defaults[1] as expressed through: check boxes, drop downs, auto complete, search results, default settings, timelines, call to actions All of these have defaults that are pre-selected. When you see these you are being nudged. For example, more people select the auto complete suggestion than what they were originally typing. What is suggested can and does nudge users towards a specific outcome. The most popular example regarding defaults is the impact of default choices on organ donations compliance rates. Countries where people where asked to opt-out of organ donation instead of opting-in reported significantly higher consent[9]: Steps to Address Nudging There are several aspects that companies should consider when considering the use of nudges, beginning with: Is the outcome what we want and need? Is the level of persuasion used in the nudge consistent with our ethical values? Is the autonomy and accountability of the decision maker preserved in the process? Nudges should by definition be easy to avoid [6] and no costlier than accepting the nudge itself. When the cost to avoid is higher, the nudge becomes a shove which is a form of coercion. Sunstein[6] posits the following distinctions for nudges with respect to ethical considerations: Paternalistic nudges – protect people from their own mistakes including behavioral biases Educational nudges – inform so that people can make better choices for themselves Nudges that enlist or exploit behavioral biases He further writes, "It follows that the most controversial nudges are paternalistic, non-educative, and designed to enlist or exploit behavioral biases." Nudging is a method of control within a spectrum between persuasion and coercion. The difference between persuasion and coercion hinges on whether or not you are free to decide if you need and want the outcome; and there in lies the rub. At what point does nudging become forced and in violation of a person's autonomy and accountability. Where you draw the line is a decision that companies need to make as part of their ethics policies. They should not let technology determine for them where this line is and even what the outcomes are. As companies continue to investigate the incorporation of nudging in their compliance programs it is incumbent on them to establish ethical policies and guidelines to govern their use. Ethical companies should at a minimum: 1. Develop a plan for how they will address the use of nudging within their compliance programs 2. Decide what is ethical and what is not (don't let the technology choose this for you). 3. Evaluate how nudges are used in existing and new technology: Where are they used? What outcomes are being influenced? Can the outcome and the level of persuasion be changed to better align with compliance obligations and core values. 4. Require that if and when nudges are used they are consistent with ethics policies and guidelines. Further reading: Digital Nudges, Fabio Pereira, Presentation at GOTO Conference, https://gotober.com/2017/sessions/303 The Persuasive Power of the Digital Nudge, Julia Fetherston, https://www.bcg.com/en-ca/publications/2017/people-organization-operations-persuasive-power-digital-nudge.aspx Digital Nudging – Guiding Judgement and Decision-Making in Digital Choice Environments, Markus Weinmann, https://link.springer.com/article/10.1007/s12599-016-0453-1 Digital Nudging: Altering User Behavior in Digital Environments, Tobias Mirsch, Chistiane Lehrer, Reinhard Junk, https://link.springer.com/article/10.1007/s12599-016-0453-1 Nudging Corporate Compliance, Todd Haugh, https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3004074 The Ethics of Nudging, Cass Sunstein, http://digitalcommons.law.yale.edu/cgi/viewcontent.cgi?article=1415&context=yjreg The Choice Architecture of Choice Architecture: Toward a Non-paternalistic Nudge Policy, David Colander and Andrew Qi Chong, http://sandcat.middlebury.edu/econ/repec/mdl/ancoec/1036.pdf Cast no shadow, Dr Tim Marsh, http://www.rydermarsh.co.uk/pdfs/SHP.0112.pdf Nudge Database v1.2, Mark Egan, https://www.stir.ac.uk/media/schools/management/documents/economics/Nudge%20Database%201.2.pdf

  • Demo-first Approach to Selecting Compliance Software

    When it comes to selecting commercial-off-the-shelf (COTS) compliance software there was a time when this involved a structured process based on a requirements-first approach. This has now been largely replaced with a demo-first approach encouraged by cloud vendors as well as by the buyers themselves. Instead of a bake-off compared against requirements, software is now chosen based on how well the software demos and looks. Does this approach result in better outcomes? Let's find out. Requirements-first Approach: A requirements-first approach typically includes the following steps: Request for Information (RFI) – survey of the market to identify candidate vendors and solutions Request for Proposal (RFP) – request for written responses to requirements from identified long list of candidate vendors. Short Listing – a short list is created based on the selection criteria rubric Request for Quotation (RFQ) – obtain firm and final pricing from the short listed vendors Live Test Demonstration (LTD) – make sure the short list of vendors actually meet the stated requirements by following a scripted walk-through. Select Apparent Winning Offeror – selection of the best alternative based on vendor performance, fit for purpose, and technical requirements. Pilot System - validation that the solution can achieve the intended outcomes as well as the verified technical requirements. The purpose of following these steps is to manage risk inherent in selecting a solution that best fits the scope, budget, and requirements. In addition, it also creates level of playing field, keeping everyone honest on both sides of the table. The following data is a compilation across 20 projects that followed a requirements-first approach: * Waterfall = Gated, Structured Approach * Hybrid = Gated, Agile Approach Key lessons learned from these projects include: System scope was the major influence in determining overall procurement cycle time. However, there is only an incremental increase (8 versus 12 months) when considering departmental versus platform solutions. The overall duration was largely determined by vendor and buyer schedules Waterfall approach using approval gates was preferred the larger the project scope In addition, 90% of projects did not purchase their first choice for reasons that included: Failed live test data (LTD) – RFP responses was good but based on software that was not yet available or didn't withstand scrutiny of actual use. Failed pilot system due to poorly understood or specified requirements Requirements changed during the procurement process It is worthwhile stating that each project completed successfully even though it was not with the first choice of vendor. Having a second choice proved to be a significant factor when mitigating the uncertainties experienced during the procurement process. Demo-first Approach: These days it seems that many companies jump right to requesting a demonstration of software without first understanding what it is that they need. While this may prove successful for some applications, when it comes to critical compliance solutions at the scale of the enterprise this can lead to decisions that are less than optimal and waste valuable time, resources, and possibly exposing companies to unnecessary risk. Companies who have used the demo-first approach have noted that these projects tend to produce the following: Scope creep – everyone wants all the capabilities that they see demonstrated Difficulty in making an apples to apples comparison of the alternatives Cost overruns due to unplanned integration, customization, and data migration Schedule overruns leading to late ROI and in many cases unrealized benefits Solutions that only meets rudimentary requirements and not capable of meeting the full demands of the organization Loss of data and information due to insufficient planning and resourcing for data cleansing and migration activities In addition, projects still end up taking the same amount of time to procure a solution as with a requirements-first approach. Although, in the case of a demo-first approach they tend not to follow a risk-based process. This makes them vulnerable to uncertainties that an RFP, LTD, and Pilot steps would have discovered. Companies have also noticed an increased tendency to choose software that may have: demoed the best, had the most capabilities, had the lowest initial cost, or the one that was used at the last company that someone worked at. In other words, without a set of requirements there was no basis on which to make an effective comparison based on actual and anticipated need. It would be reasonable to ask why companies would choose a less rigorous process for selecting compliance solutions. Here are some of the reasons given: Our current system doesn't work and we need something else but we don't know what that looks like I don't know what I need so looking at software helps me figure that out All I want is something that is user friendly. I expect the vendor to know what my requirements are. This is off-the-shelf-software so why do I need to write down any requirements. Don't they all do the same thing. I am just looking to replace what I currently have so those are my requirements We are looking at cloud-based software and the subscription costs don't warrant a large project Our business analysts used to do that but we don't have those roles anymore I don't have the time to go through a structured process. We are following an agile approach which means we don't need to figure out what are requirements are right now Even if it the software doesn't work we can replace it easily because its all in the cloud As more organizations move their systems over to the cloud it is expected that the use of a demo-first approach will increase. Of course each company will have different levels of success, however, the probability of success can still be improved by effectively managing uncertainties specifically with respect to scope. Risk-Based Approach: Acquiring software to support critical compliance processes still requires that risks be properly addressed. The most significant source of risk hasn't changed and is still scope creep or scope gallop as it often the case. Managing scope is essential to every project and this applies to choosing compliance software. Software demonstrations can be an effective way to learn about what is available in the marketplace. This in many ways has replaced the use of RFIs. However, demos do not replace the need to specify what the software needs to do or the need to manage risk. Requirements may not be as detailed as they once were and may take the form such as user stories. At the same time, they still must be sufficient to cover what the software contractually needs to deliver and how it needs to perform in order to achieved the desired outcomes. It is always good to remember that you are not the product the software is. In addition, as previously noted, it is a good strategy to always have a second choice because your first choice is likely not the one that will achieve the desired outcomes. Whether you follow a demo-first or requirements-first approach or not you still need to get answers to the same set of questions. The timing of when you get these answers will significantly influence the success of your project. If you wait until after you purchase the software you will need to deal with the effects of not knowing or what is called, "epistemic uncertainty." The risk of not knowing can and often leads to failed projects that in many cases doubles the cost since the project has to be done over again. Here is list of items that some companies chose not to know in advance: The importance of integration with other systems and consequently neglected during the procurement phase The value associated with legacy data leading to no budget for data migration The loss of control over how processes are implemented resulting in the using vendor generic workflows The impact of using generic approaches that were sub-standard to the company's higher standards The lack of understanding of how an on-demand pricing model would be affected by a fixed operating budget The lack of understanding of how the software is going to be transitioned and rolled-out All of these could have been known in advance and addressed using a requirement-first, risk-based approach. Here is a list of things that you should know when selecting compliance technology: 1. What defines success? What are the intended outcomes for the system? What defines what done looks like? How do you measure progress towards done? What steps are critical to achieving done? What risks need to be addressed that hinder achieving done? What opportunities should be pursued to increase the likelihood of getting to done? 2. What is the purpose for the software purchase? Technology replacement? Architecture alignment? Process improvement? Improved compliance? New capabilities? Increase or decrease in scale or complexity? Cost reduction? Introduction of best practice?. Point solution or platform to support multiple solutions.? 3. What are all the requirements for the expected use of the software? System, application, process, and other functional requirements? Compliance, security, data, privacy, and sovereignty requirements? Platform, network, communication, and other technical requirements? Performance, and reliability requirements? Customization, and integration requirements? Implementation, sustaining, and end-of-life requirements? Backup and recovery requirements? 4. What strategies will be used to introduce and sustain the use of the software? Lift and Shift - Improve processes first then shift? Shift and Lift - Shift to the new software first and then improve processes? All users at once or a phased roll-out? All modules at once or a phased roll-out? Distributed or centralized support? Business owners or IT support? 4. What are the impacts and risks associated with the choice in software, implementation strategies, and sustaining activities on the business What gaps in requirements need to be addressed by customization, work-around, or additional software? What is the total cost and budget needed to sustain and use this software over its anticipated lifetime? How is compliance maintained during and after the implementation? How will changes to the software or configurations be managed and validated? What actions are needed to address uncertainty in: capabilities, cost, user acceptance. ability to meet compliance obligations, and so on? Who owns the data and will the data be monetized by the vendor? How and when will breaches in service be communicated? What is your exit strategy and when will this be triggered should you need to revert to your second choice?

  • Is Compliance A Zero-Sum Game?

    Back in the day I would visit bookstores in the places that I travelled particularly for work. Browsing the book isles was one way you could get a sense for what the current trends were and which way the wind was blowing. This for me was a from of sense-making. Trying to determine what is relevant in a sea of constant change. You could say that going to the Gemba for me was going to the bookstore. Today, you can do the same thing by using Google’s N’grams based on google books. And here is what you would find: Quality peaked in 1992 and is now in decline (around the time that ISO 9001 was introduced and the quality movement was at its peak). Risk as a general topic continues to grow and dominates the discussion across all risk & compliance domains. Safety, Security, and Fraud have peaked and on the decline since 2000. Perhaps as a result of Y2K no longer being an issue. Regulation is near the bottom and declining. Cyber, Sustainability, Climate, are on the uptick but still way behind the others. What could this all mean? Less books are being written on the various topics. Traditional risk and compliance theory and practice have stalled i.e. nothing new is being added to the discussion. New compliance concerns are starting to take over. Compliance is a zero-sum game i.e. focus on something new takes away from existing resources. If the last one turns out to be true, then it is likely we will see organizations reallocate existing resources to tackle new areas of risk. To meet the new demand without sacrificing existing risk & compliance performance organizations must find ways to leverage existing capabilities. This will include one or more of the following: Apply LEAN principles and practices to reduce waste. Apply Risk Management principles and practices to focus on what really matters. Take a Holistic view of systems and processes to ensure the parts all work together to realize compliance outcomes. Embed compliance into processes to ensure the organization always stays between the lines. Leverage common principles and practices across all risk & compliance programs. Apply Proactive and Preventive strategies to stay ahead of risk

  • Playing the Compliance Game

    When we consider compliance we often think of being compelled by regulation to follow an arbitrary set of rules that get in the way of achieving business outcomes. No wonder many companies only want to do the minimum. However, a more useful way of looking at compliance is as a game that we want to play and one that want to be good at. As with all games they have rules. These rules do not inhibit playing the game they instead make it possible to play the game not just once but many times. That is what we want for our businesses. We want to act in such a way that we can continue to play the game over time for as long as we want to play. This requires a long-term perspective. However, some prefer a short-term view and take short cuts, cheat, or otherwise hack the game. When they do this they find that no one wants to play with them anymore. Customers do not want to buy from them, suppliers do not want to sell to them and stakeholders do not want to invest in them either. They have ended the game for themselves and as a consequence ended their business or at least severely damaged it. Don’t sacrifice your business by choosing actions that take you out of the game. Instead, learn how to become competent at playing the game well.

© 2017-2025 Lean Compliance™ All rights reserved.
bottom of page