Diffusion of Responsibility

You may have experienced the concept of diffusion of responsibility – when members of a group feel less personal obligation to perform an activity or task, assuming “someone else will handle it,” leading to inaction, delays, or reduced accountability. This can occur when the quality management system either poorly defines responsibility or defines responsibility to a group. This effect, also referred to as the “bystander effect,” was described by psychologists John Darley and Bibb Latané in the 1960s. In group settings (e.g., teams or committees), responsibility dilutes as group size increases—each person feels less urgency because the burden is perceived as shared. The results:

  • Tasks falling through cracks
  • Delayed decisions
  • Social loafing (reduced effort)
  • Investigations or audits hearing “I thought someone else was doing that”

So how do we avoid diffusion of responsibility?

We should ensure that policies, procedures, and work instructions emphasize clear, singular ownership of responsibility. For example, management, project management, engineering, operations, and manufacturing procedures should assign a single accountable owner (or “single point of responsibility”) for critical processes or tasks. While a team may perform and complete the process or task, the single accountable owner would be responsible to ensure the process steps were completed and all the documentation and records were produced.

Some key frameworks may help. For example, one framework is the RACI Matrix. The acronym RACI is defined as:

  • Responsible
  • Accountable
  • Consulted
  • Informed

RACI is a standard tool in project management and QMS (e.g., aligned with ISO 9001/13485).

Accountable (A): Strictly one person—the ultimate owner who ensures completion, makes final decisions, and is answerable for outcomes (the “buck stops here”).

Responsible (R): Can be one or more people (the “doers”).

Rule: Only one “A” per task to prevent diffusion—multiple accountable parties recreate the group problem.

We would expect to see the single point of accountability person named in the governing plans for the project. One typical approach is to use “lead” on the front of team names. While the team may be “responsible” for the process or task, the “lead person” is “accountable” for ensuring all activities and tasks were performed according to the process and that all documentation and records were properly produced. From a management control perspective, there should be management action applied to the lead person if processes and/or tasks are not performed according to process.

Let us ensure all of our processes identify single points of accountability to counter this human tendency toward diffusion. Of course this is not intended to prevent teamwork and excellent group dynamics which is a related but separate topic.

Did you know that SoftwareCPR provides ISO 13495, QMSR, and MDSAP audits? Our certified auditors are not only expert with efficient and effective QMS but have that additional expertise with SaMD and HealthIT companies. Contact us for more information.

About the author

Partner and General Manager, Brian Pate is ISO 1385:2016 Lead Auditor certified for Medical Device Quality Management Systems (MD), and ISO 19011:2018 Management Systems Auditing (AU) and Leading Management Systems Audit Teams (TL). Brian started his medical device career in anesthesia clinical research in 1985 and has since worked both academia and industry including many years with Johnson & Johnson, Baxter Healthcare, and GE Medical. Brian’s roles have included software engineering, systems engineering, quality assurance, and regulatory affairs. Brian has served on multiple AAMI TIR working groups, including TIR32-2008 (Application of ISO 14971 Risk Management to Software; now IEC 80002-1) and TIR45-2012 (Guidance on the use of Agile practices in the development of medical device software) and served as a reviewer for the 2nd edition of TIR45. Brian serves on the AAMI Software Committee and as an AAMI instructor for the software, design controls, and agile methods courses. Brian also is a member of the Underwriters’ Laboratories (UL) Standards Technical Panel for UL1998 (Software in Programmable Components) and or UL5500 (Remote Software Updates).

SoftwareCPR Training Courses

ISO13485:2016 ISO 13485 Internal Audit(or) Training Course (Live, 3-day)

IEC 62304 and other Emerging Standards Impacting Medical Device Software (Live, 3-day)

Being Agile & Yet CompliantISO 14971 SaMD Risk Management

Software Risk Management

Medical Device Cybersecurity

Software Verification

IEC 62366 Usability Process and Documentation

Or just email training@softwarecpr.com for more info.

Corporate Office

15148 Springview St.
Tampa, FL 33624
USA
+1-781-721-2921
Partners located in the US (CA, FL, MA, MN, TX) and Canada.