Spanish multinational pharmaceutical and chemical manufacturer Grifols is the leading producing of blood plasma-based products. With over 21,000 employees in its four divisions—Bioscience, Diagnostic, Hospital, and Bio Supplies— Grifols develops, produces, and markets innovative medical device solutions and services in more than 100 countries.
As a leader in the future of healthcare, Grifols strives to set the standard for continuous innovation, quality, safety, and ethical leadership. On an operational level, it knew that its requirements and risk management processes played a key role in facilitating innovation, and its current solution wasn’t up to the task.
Grifols Sees Opportunities for Process Improvement
When Grifols’ Diagnostic division began a new project in 2018 to improve the management of disease detection in blood bank laboratory operations, the company knew it had an opportunity to improve its requirements and risk management processes. While the company’s legacy solution had served its purpose for many years, the task of reviewing requirements was arduous. The solution was also unable to facilitate the collaboration needed to keep the project’s team — split between Spain and the United States — on the same page.
“Our globally dispersed teams need to work on the same projects and using our previous legacy solution was very slow,” said Carmen Pazos, Diagnostic Divisions R&D Instruments Senior Manager at Grifols. “We experienced performance issues. We were looking for a way to expedite the process.”
Legacy Solutions Impede Innovation in Medical Device Development
Not only were the processes tedious and error-prone, but since Grifols’ products are considered medical devices, they must also comply with ISO 14971 — the standard for the application of risk management to medical devices. So, on top of Grifols’ manual process being time consuming, it also made things difficult to document and prove compliance.
It was then that the Diagnostic division was introduced to the solution that Grifols’ Hospital division had been successfully using. “When I saw how Grifols was already using Jama Connect, I thought, ‘I really need that,’” Pazos said.
Grifols Improves Risk Management and Speeds Development
Within two or three months, Grifols began working from a medical device pre-configured template within Jama Connect on a small, low-risk project to test its capabilities. Things went well and Grifols began implementing Jama Connect into more projects.
The immediate benefits the Diagnostic team saw from Jama Connect were how user-friendly and intuitive it is, while also keeping people in different time zones instantly in synch. The ability to comment and facilitate robust discussion within Jama Connect helps remote teams drive clear agreement on project items while also automatically building an audit trail for compliance.
And the results are also worth mentioning. Within months of onboarding Jama Connect, Grifols reported:
Savings of 80 hours or more per project
Review cycles reduced from three months to fewer than 30 days
Requirements linked to risks, tests, and executions for traceability
Improved communication and efficiency
Reduced rework
Read the full case study to see how Grifols was able to increase efficiency and cut costs by optimizing their requirements and risk management process with Jama Connect.
You’ll gain more confidence that your recently-released products avoid recalls, fines, or worse if you perform failure mode and effects analysis (FMEA) as part of your risk management.
Over the course of the hour-long webinar, Quillinan and Jama’s senior product manager, Joel Hutchinson, provided some key elements around the value of risk management and FMEA, and the importance of modernizing your risk management process to accommodate.
At the conclusion of the webinar’s presentation, the pair answered a range of questions from the hundreds of participants in attendance. Unfortunately, they weren’t able to get to everyone’s questions, but luckily they took some extra time afterward to answer some of those remaining, touching on everything from risk mitigation in aerospace to specific standards like ISO 14971.
We’ve compiled the questions (some of which have been slightly modified for clarity) below and encourage you to check out the full webinar and Q&A session here.
Q: Given that FMEA teams in companies can be non-permanent and have a fluid scope, which role should own and drive the activity overall?
Bethany Quillinan: I think the ownership role should align with those of the design/new product introduction process. If there is a project lead, then that person would make the most sense. There may also be a particular functional group who is given ownership of risk management, like Quality or Compliance teams. I think it really depends on the organization. What we want is alignment and integration within the design process, not a separate “silo” for risk management.
Q: Do you have any suggestions for criteria that would help when selecting a good FMEA facilitator?
Quillinan: A good facilitator will be someone who is well-versed in the FMEA process and the organization’s particular methodology, rating scales, etc. Additionally, the facilitator should be skilled in well, facilitation, and by that I mean having meeting management skills — things like tracking time, noticing when energy is low and a break is needed, drawing out quieter members, dealing with overly-dominant members, and generally equalizing the field. The facilitator should not get involved in the “content” of the FMEA, just the process itself. Ideally, there is also a content leader who can keep the team focused on the scope of the FMEA. That said, the facilitator should be aware of the scope, in case the team gets way off track and no one is calling it.
Gain Confidence in Your Risk Management Plan with Jama Connect. Learn how.
Q: Any suggestions for facilitators to keep people from taking things personally?
Quillinan: One engineer I worked with who had facilitated a lot of FMEAs shared a good technique — to ask people, “How could you make it fail?” And that turned around defensiveness to creativity. From a facilitation aspect, I think emphasizing that the analysis is “potential,” that we’re not saying it’s going to happen, but that it’s a just a possibility to consider. Depersonalizing statements can help — talk about “the design” vs. “your design,” for example. If someone is super defensive, the facilitator may need to call a break to let things cool down and talk to the person offline. Diplomacy is important!
Q: What you talked about is used in the automotive field which is very effective, but the aerospace industry tends to use FMEAs focused on managing the effects and quantitative failure rates (assuming constant failure rates). How do you get the benefits of automotive FMEA and, at the same time, satisfy aerospace FMEA requirements?
Quillinan: Having quantitative failure rate data to inform the discussion of the probability of occurrence is a big benefit. Failure mode, effects and criticality analysis (FMECA), where “C” is criticality analysis brings in more of the quantitative factor, and I see that terminology used more in aerospace. Satisfying specific Aerospace requirements is somewhat out of the scope of this presentation. In the context of the AS9100 quality management system standard, the requirement is to perform risk management, and FMEA is not prescribed but is a possible tool. Bottom line, I see FMEA as a prioritization tool rather than a reliability prediction. (In the early days, the military hoped to use FMECA to calculate an actual reliability metric, but it didn’t work out that way.)
Learn why Frost & Sullivan likes Jama Connect as a modern solution for risk management. Read the brief.
Q: What happens when multiple users are creating individual risk analyses? How do they collaborate if they are analyzing similar things?
Joel Hutchinson: As Bethany mentioned during her presentation, we understand that there’s going to be overlap in various FMEAs. An example of this is subsystems, which may have additional functionality that is only present at the system level. Risk management in Jama Connect helps the cross-functional team that works together to perform a risk analysis and has the ability to add view-only roles for context. One way of addressing this would be for the moderators of the two overlapping risk analyses to add each other as view-only roles to their respective analyses. This way, each cross-functional team is aware of what the other team is doing and how they’ve scoped their risk analysis.
Do you know where, when, and how intended Use FMEA (uFMEA for medical devices, per IEC 62366-1:2015) and software FMEA (life cycle requirements for medical device software per IEC 62304:2006+A1:2016)integrate into the requirements management process and product development timeline?
Quillinan: Generally speaking, risk management for usability, software, or any other aspect of a design should be integrated with the design process as soon as these aspects enter the design conversation. For example, early on during the initial “concept” phase, we need to be thinking about usability risks to inform the design concept and assist in evaluating different design routes to take. I also think useability/human factors could potentially be considered at any level of the product, so it could follow the same general timeline I showed in the presentation.
Likewise, for software, at the concept phase, the conversation will likely include software needs for satisfying customer expectations. From a systems standpoint, I feel the sooner the better. (I often use the initial rollout of the Healthcare.gov website for the Affordable Care Act (ACA) marketplace as an example of a “silo’d” approach to design. Each module was developed and tested in isolation and the “validation” of interfaces between modules was when it went live… and crashed.
We have to remember that the ultimate focus is at the system level — the end-user interaction with the product. In a medical device setting, most consultants are going to advise you to build in human factors considerations throughout the design process rather than waiting until the final human factors validation test on the finished design, for all the same reasons I described in the presentation.
Find out how to better manage medical device development in accordance withISO 14971. Read our guide.
Q: Risk Priority Numbers (RPNs) seem to always be subjective from one party to another, specifically the occurrence and detection. The occurrence is difficult to gauge when the failure mode and risks are new or when little-to-no history is available. For detection, we’ve had difficulty assessing the controls in place and how to rate them in terms of efficiency.
Quillinan: One way to help make the RPNs more objective is to establish and use consistent rating scales with descriptions that are relevant to your organization’s products and processes.
When there is no history and risks are new, the typical practice is to be conservative and give them high ratings. I often find that people have difficulty distinguishing prevention controls from detection controls.
Preventive controls typically act on the inputs to a process or are the controls during the process — think of mistake-proofing, for example not being able to choose an obsolete revision of a component for a bill of material (BOM) or having design guidelines to follow. Detection controls are after the fact and are inspections of the output of a process. In design, a typical detection control is a second person (or more) performing a design review.
Q: What is the relationship between design failure mode and effect analysis (DFMEA) and process failure mode and effect analysis (PFMEA), in terms of the failure modes and causes?
Quillinan: In DFMEA, we are looking at how the product could fail, and causes are from the design process itself; the assumption is that the process is being run correctly. In PFMEA, we’re looking at how the process could fail, assuming the product is designed correctly. Of course, this depends on FMEA scope. If we’re looking at a design for manufacturability, then we’re looking at how the design process could fail in terms of designing the product in a way that it can be easily and efficiently built.
While a positive brand reputation takes years to nurture and build, irrevocable damage to a brand — and a business — can happen in only moments.
As innovative companies are asked to move faster than ever to bring products to market, it’s worth taking a moment to step back and look at the cost — financial and otherwise — of a misstep that could lead to product recall or failure. In addition to fines, regulatory reprimands, and decreased market share, a product recall inevitably impacts your brand and can have a major impact on your bottom line.
Brand erosion, for instance, is one consequence of a major product recall. As the name suggests, brand erosion is the gradual destruction or diminution of your organization’s reputation when your products are deemed unsafe, unfit for the marketplace, or simply don’t perform as marketed.
If you’re working in an industry where functional safety is a top priority, like automotive or aerospace, guarding against these types of scenarios means getting crystal clear on the standards and regulations that help protect your product. That also means ensuring proper risk management techniques like Preliminary Hazard Analysis (PHA) and failure modes and effects analysis (FMEA) are being performed correctly.
Often times, penalties come as a result of companies not properly performing these functions, and instead rushing to deliver products that haven’t met benchmarks for quality, compliance, and — in the case of many industries — functional safety. Other times, companies simply fudge the data. Let’s look at a few famous examples:
Ford Motors’ 1980 Failure to Park Product Recall
While product recalls can happen in any industry, some of the most notorious and detrimental have happened to automotive companies. Such was the case for Ford Motors which, in 1980, was determined by the Department of Transportation to have more than 23 million cars and light trucks in circulation that contained a functional safety defect that permitted the vehicle to accidentally slip from park into reverse, although to the driver the placing of the shift lever appeared to be in park.
And while the company would have faced financial ruin if all 23 million automobiles had been recalled, regulatory authorities ruled that instead of recalling all vehicles involved, Ford could make amends by sending out a sticker for drivers to place on their dashboard warning that “unexpected and possibly sudden vehicle movement may occur” if the car was not properly parked.
The failed safety catch was found to have led to 6,000 accidents, 1,700 injuries, and 98 deaths, and Ford was tied up in litigation for years, costing the company tens of millions of dollars. The “failure to park” issues continued even after the sticker warning was issued.
While the cost of this functional safety error included lost revenue and expensive lawsuits, the safety malfunction may have additionally cost Ford the trust of their consumers. Especially in industries that are highly regulated — and thus highly trusted — recalls related to safety and reliability can cause devastating harm to the foundation of the organization.
Learn how how a Fortune 100 semiconductor company is meeting the challenges of developing automotive-related technology by downloading our case study.
Volkswagen’s “Defeat Device” Scandal
While some product failures and recalls are the result of honest mistakes, such as the example above, others can be attributed to downright dishonesty. Such was the case for Volkswagen in September of 2015, when the company admitted that they had installed software in 550,000 automobiles that could figure out when the cars’ emissions were being tested and modify their performance to meet mandated standards.
Initially, Volkswagen spokespeople claimed that a “few software engineers” were struggling to meet stringent U.S. emissions standards while also producing a diesel engine that would perform well. That, the spokesperson said, was the reason those individuals decided to design a “defeat device,” a system to switch on emissions controls when the cars were being tested and turn them off when the automobile was driving normally. What we now know is that knowledge of this system went much higher, and some believe awareness could have been as high as the CEO, who resigned and was later indicted.
The scandal cost the company over $29 billion dollars in recalled automobiles, but the damages didn’t stop there. After losing the trust of the public, the company posted their first quarterly loss in 15 years, showing that consumers weren’t likely to invest their money in an organization that had deceived them.
A recent study by Edelman shows that consumers are more interested than ever in purchasing from organizations that they believe are “doing the right thing.” The study revealed that 64% of consumers around the world — up 13% from 2017 — now buy on belief, meaning that they will choose, switch, avoid, or outright boycott a brand based on where the organization stands on issues they care about.
The same study showed that consumer trust dropped 10% (from 58% to 48%) in the last year, and that nearly half of consumers don’t trust businesses to “do what is right.” And organizations whose products are recalled due to deceiving functionality are certainly not going to earn a reputation for doing what’s right for their customers.
An additional 8 million cars were sold in the E.U. with the same “defeat device,” but because emissions standards are much lower there than in the U.S., Volkswagen legally committed no crime in the E.U.
NASA’s Costly Math Mistake
On December 11th, 1998, NASA launched a robotic space probe called the Mars Climate Orbiter into space with the hope of studying the Martian climate, atmosphere, and surface changes. Nearly 10 months later, in September 1999, the $125 million probe burst into flames and fell to pieces in outer space. While this was certainly not the first, or last, failed space expedition, what sets this one apart is that the reason for failure comes down to a simple math error.
The navigation team at the Jet Propulsion Laboratory (JPL) used the metric system of millimeters and meters in its calculations, while the team that designed and built the spacecraft, Lockheed Martin Astronautics in Denver, provided crucial acceleration data in the English system of inches, feet, and pounds.
The result was that the software controlling the orbiter’s thrusters was faulty. The software calculated the force that the thrusters needed to exert in pounds of force, while a second piece of code that read this data assumed it was in the metric unit— newtons per square meter. And while fortunately no lives were lost, this simple mistake pushed the orbiter dangerously close to the planet’s atmosphere, destroying the spaceship and killing the mission.
Despite NASA’s next Mars mission also resulting in a lost spaceship, the organization did bounce back from the ordeal. They recovered over the following years by returning to the basics, rebuilding the Mars program based on conservative strategies and concepts that had already been tried and tested.
In the case of NASA’s space mishap, detriment took the form of missed opportunity and lost ground in their research efforts. Because of the immense time, money, and resources it takes to launch a space mission, failures and missteps can result in years of setback. What was supposed to be the first weather observer in another world became a $125 million mistake.
How Better Requirements and Risk Management Can Help You Avoid Product Recalls and Failure
Developing complex systems and products requires teams to have the ability to effectively define and track requirements, adhere to safety-critical regulations, collaborate and communicate effectively across teams and functions, and evaluate and mitigate potential risks. Failure to do so may result in product recalls or failure, and in the case of safety-critical products, injury or worse.
According to the CHAOS Reports from The Standish Group, three of the biggest contributors to projects that fail are lack of user input, incomplete requirements and specifications, and changing requirements and specifications.
Unfortunately, too many organizations struggle with requirements and risk management and the effects, some outlined above, can be devastating.
In the case of the Mars Climate Orbiter, the simple miscommunication between JPL and Lockheed Martin not only shows how small mistakes can lead to mission failure, but also highlights the need for teams — especially those in different physical locations — to work collaboratively instead of in silos, and for organizations to invest in solutions that help teams achieve this.
With the Jama Connect Risk Management Center, development teams can participate in risk management techniques including PHA and FMEA in accordance with industry-specific standards like ISO 14971 and IEC 60812. By working with live data, teams can efficiently identify and mitigate risks early in the development process, ensuring quality and safety in complex product development.
To learn more about how Jama helps organizations thrive in critical product markets by reducing risk and providing a single source of truth, download Frost & Sullivan’s recent executive brief,“Safeguarding Regulated Products Amidst Growing Complexity.”
Many products must go through a risk management process to ensure safety, but it’s the severity of the potential outcomes that vary.
For our customers creating products in heavily-regulated industries — such as automotive, medical devices, and aerospace — the consequences associated with not correctly mitigating risk puts lives in jeopardy. And there’s ample evidence that too many in these fields are still struggling to find a process that works.
Even while tougher safety regulations and standards are being enacted, product recalls are still soaring. In February and March alone, millions of vehicles were recalled due to quality issues. And, within the fourth quarter of 2018, recalls of medical devices spiked 449% to just over 161 million, which was the second highest quarter in at least 14 years.
These examples showcase why teams building complex products need a smarter way to identify the probabilities and severity of risks early so they can track and mitigate them throughout development. And while risk management is imperative, it can’t come at the expense of the speed of development; in fact, it should complement rather than hinder efficiency.
The Jama Connect Risk Management Center was developed from best practices learned from our work with companies that deliver quality products in safety-critical industries. With the newly-updated Risk Management Center, development teams can participate in risk management techniques including Preliminary Hazard Analysis (PHA) and FMEA in accordance with ISO 14971 and IEC 60812.
As an overview, here are some common problems we’ve often seen around managing risk and how the Jama Connect Risk Management Center solves them.
Problem: Not sure how to implement a solid risk management process
Risk management is a daunting challenge, especially for startups vying to disrupt an entire industry. Whether it’s ISO 14971, IEC 60812, or beyond, many new companies aren’t sure where to start when creating a risk management plan to bring their products up to international standards and government regulations.
Solution: Pre-configured risk analysis templates and startup services
In Risk Management Center, users receive guided templates based on best practices like FMEA and ISO 14971, which helps remove the bulk of the guesswork.
For medical device developers, Jama also has a Professional Services division that can work directly with your team to provide the best possible start to your process in accordance with ISO 14971. Through training and consultation, they’ll help customize your templates in a way that matches your team’s risk management process so you can start managing and mitigating risks quickly while accelerating development.
Jama’s professional services dramatically speed time to value, so much so that one customer began developing medical devices in less than a week with our guidance.
Frost & Sullivan points to Jama Connect as a way to better manage risk for companies in regulated industries. Read the report.
Problem: Risk management process can be siloed
In many organizations, managing risk during development is painfully cumbersome, disconnected, and inefficient.
If you can imagine a company emailing gigantic Excel spreadsheets around to manage risks for large, complex products — whether its airplanes, automobiles, medical devices, or software that interacts with any of these elements — you can also envision the unintended errors that can manifest as a result.
Solution: Streamlined risk management
The Jama Connect Risk Management Center takes a strong, team-based approach, ensuring risk analysis is not done in silos and instead performed early, collaboratively, and continuously throughout development.
With your risks and requirements housed directly within Jama Connect, Risk Management Center helps you track both in a single place. And since the data in Jama Connect is updated in real time, you’ll always be working from the most recent version of any risk analysis. Invited individuals can simply log in to Jama Connect and participate throughout the development process.
Through this effort, risk management becomes a continuous and collaborative part of the development process saving you valuable time and rework cost.
Problem: Aligning teams around risk management
Throughout the frenzied pace of development, those charged with leading the risk management process at organizations can find it difficult to keep teams engaged and focused on reviewing risks. The issue often manifests itself in long, painful, cross-functional meetings, wherein risks are reviewed in detail.
By their very nature, cross-functional teams aren’t performing risk management full time. As a result, review meetings can become susceptible to the same problems all meetings are prone to: participants don’t prepare, precious meeting time is spent on what to focus on, and action items aren’t clearly identified or resolved. This type of disorganization can significantly extend the development cycle if risks are still discovered late in the design or commercialization phases – times when efficiency is most needed.
Solution: Centralized risk management activities
Lengthy meetings around risk management can be halved with the Jama Connect Risk Management Center. Throughout development, key stakeholders in the risk management process can be given select access to Risk Management Center.
These chosen team members can then easily and efficiently view and contribute to the risk analyses that matter most to their expertise and experience. Users also get the ability to easily bookmark, organize, and identify recently-viewed analyses so they can pick up right where they left off.
Organizations using dedicated requirements management platforms receive fewer warnings, recalls, fines, and production stoppages than those that don’t, according to Engineering.com. Get the full report.
Problem: Tracking accountability in risk management
If your team is still relying on spreadsheets when building complex products, that’s going to cascade into other problematic areas.
In the whirl of development cycles, it can be difficult to manage the multitudes of requirements and tasks, leaving teams with a sense of unease around whether or not they’ve properly tracked and mitigated all possible risks when it comes time to launch.
Solution: Visible risk tracking and mitigation
In Risk Management Center, you’ll have the ability to link risks to requirements and verifications to better manage development complexity and assess the impact of changes to ensure quality. This feature also allows you to easily track open risks and those that are still needing mitigations, effectively eliminating the chance something slips by your team.
When it comes time to prove compliance, risk analysis and plan elements can be easily exported to allow sign-off in another compatible document or management tool.
Learn more about Jama Connect Risk Management Center by downloading our datasheet or contacting your account manager.
Companies are facing intense pressures to bring complex products to market faster than ever. In addition, those delivering products in safety-critical markets must also create and execute against a risk management plan for expanding standards and regulatory oversight.
In these cases, inefficiencies and blind spots in the development process can lead to risk management errors which not only throw releases off schedule but can put lives in jeopardy.
To help raise awareness around these issues, prominent research and consulting firm Frost & Sullivan recently observed the product development landscape and its relationship to risk. The output is a recently-released brief, “Safeguarding Regulated Products Amidst Growing Complexity,” that spotlights Jama Connect™ as a remedy for ineffective risk analysis in product development.
Symptoms of Ineffective Risk Management
The Frost & Sullivan brief outlines the current competitive environment facing organizations producing products in regulated industries and makes the case that relying on outdated processes impedes success.
“Many businesses in these spaces have invested heavily over the years in their document-based systems to manage their product development process and are hesitant to upgrade to unknown technologies or solutions,” writes Frost & Sullivan. “These antiquated systems are often static and spreadsheet- or even paper-based. And while they may offer a (possibly false) sense of reassurance against the costs and risks associated with a live digital system, they end up creating more costs and causing more harm.”
As we’ve heard from many companies, performing requirements management and risk analysis through versioned spreadsheets and extensive meetings not only drains resources, slows development, and creates errors, but it’s just no longer an effective strategy when you need to build safe products quickly.
Gain a stronger handle on ISO 14971 — the FDA’s mandatory standard for risk assessment in medical devices — by grabbing our whitepaper.
Strengthening Collaboration During Development
One other notion dispelled by Frost & Sullivan is the idea that remote development teams can operate at maximum efficiency without a powerful, shared solution for centralized enablement.
For instance, with regulated companies, there’s too much at stake to leave issues around requirements, risk mitigation, and compliance up to emailed documents.
“A strong, platform-based solution can provide a virtual space in which different but interdependent teams can collaborate, key stakeholders can review and weigh in on decisions, and regulators can trace end-to-end compliance,” writes Frost & Sullivan. “It can also enable risk mitigation as an ongoing, semi-automated process that catches and integrates changing conditions. Such a solution can help ensure compliance across processes, functions and locations, as well as with product definitions and design, processes and test cases.”
Learn how how a Fortune 100 semiconductor company is meeting the challenges of developing automotive-related technology by downloading our case study.
A Better Risk Management Solution
For businesses still hesitant to invest in improvements to their risk management process, it’s not always strictly a question of budget. The move involves a change in mindset and executable process, according to Frost & Sullivan. For instance, tracking and managing risk needs to be an intrinsic, collaborative, ongoing part of the development process, and not something performed by a specialized team in a silo.
Some organizations, especially newcomers to regulated industries, may not even be sure where to start with complex standards like ISO 14971, let alone assembling a risk management plan. It’s in these cases you’re more likely to see a development team dig into a risk management framework in the later stages of development, potentially adding rework and cost when schedules and budgets may not allow for either.
Frost & Sullivan contends Jama Connect is worth a look for all organizations interested in mitigating product risk, as it can “provide risk management, collaboration, efficiency and regulatory compliance as aspects that strengthen, rather than complicate, each other.”
Whichever path a company chooses, what Frost & Sullivan make clear is that staying the course with an ineffective risk management process isn’t really an option at all.
“Teams will otherwise struggle to get their people up to speed, across the globe and across groups,” writes Frost & Sullivan. “A team-based approach… is the ideal solution in heavily regulated industries.”
Access the full Frost & Sullivan brief, “Safeguarding Regulated Products Amidst Growing Complexity” by downloading it now.
Compliance standards, especially those that involve relatively new functional safety elements, will likely add additional requirements to the development process.
For example, the increasing complexity and abundance of automotive electronic systems led to the creation of a functional safety standard called ISO 26262 in 2011. And to ensure that new electronic functions remain functionally safe in the industry’s rapidly evolving environment, the International Organization for Standardization (ISO) recently introduced a second edition of ISO 26262 in December 2018. Similar regulations for other industries abound: DO-178B/C for aerospace standards, and IEC 60601 and ISO 14971 for medical standards.
Common to all of these safety standards is a risk-based approach to determine the criticality and potential hazards associated with key system functions. The primary goal of these standards is to prevent the failure of a system or device that could cause injury, harm or death. If a failure is unavoidable, then the system should fail gracefully.
ISO 26262 complements good systems engineering practices by requiring that hardware and software safety concerns be addressed and documented in a systematic way throughout the development lifecycle. In the past, safety design was considered part of general requirements activity. But merely identifying and tracing requirements in the software and hardware teams is not enough. The common practice of hardware and software teams working in silos will not guarantee the level of safety coverage required by ISO 26262.
How can the problem be resolved?
One of the key things missing from the general approach to requirements are the traceability links between phases. Many tools do a great job of requirements management and traceability within a particular phase but provide a poor auditable trail for traceability between phases. The activities of comprehensive and complete lifecycle traceability become an auditing afterthought, to be finished after the project is completed. This is the result that ISO 26262 tries to avoid through documented attention to the development process, decision-making and selection of supporting tools.
And because functional safety is a top priority for so many of our customers, Jama went through the process of earning a certification from internationally recognized testing body TÜV SÜD. Jama Connect™ is certified as a fit-for-purpose software tool for development of safety-related products according to ISO 26262 (up to ASIL D), IEC 61508 (up to SIL 3), IEC 62304 and EN 50128, giving our customers confidence that the products they are building are safe to use.
Tool qualification depends upon how the tool is used, which in turn determines what impact it could have on safety. For example, depending upon its usage, can the tool introduce a hardware defect or software bug into the system? How the tool is used within a tool chain will also determine the probability that an error introduced by the tool will be detected.
A confidence level is assigned to a given tool, or a flow within a tool, based upon the probability that it will insert or cause an error, combined with the likelihood that the error will be detected during the development process. The importance of the tool confidence level is that it will determine the cost an organization must invest in tool qualification.
As with other standards, implementing the ISO 26262 process requires iteration of a number of basic steps:
Determine the existing process and tools to answer the question “Where are we now?”: Review the current embedded hardware and software development processes and tool chains. Understand the application(s) to be developed and assign levels of confidence in terms of safety.
Gap analysis to answer the question “Where would we like to be?”: Perform a gap or impact analysis to identify current challenges and process efficiency improvements – often done using model-based design techniques.
Training and instruction: Provide design-for-safety training and instruction to address the previously identified gaps.
Hands-on deployment support: Apply the knowledge gained in the previous steps to a specific pilot project. This will require assistance in a wide range of areas including requirements traceability, modeling, simulation, code generation, verification, validation, tool qualification and system integration.
Jama Software is the first SaaS and Agile vendor to be ISO 26262 fit-for-purpose certified by TÜV SÜD. Read more.
Alignment with Best Practices for Functional Safety
This holistic approach to functional safety exemplifies several key elements of good system engineering processes: collaboration, traceability, validation and verification (V&V), risk analysis and mitigation, and careful integration within the tool chain.
Software engineers are eternal optimists. When planning software projects, we usually assume that everything will go exactly as planned. Or, we take the other extreme position: the creative nature of software development means we can never predict what’s going to happen, so what’s the point of making detailed plans? Both of these perspectives can lead to software surprises, when unexpected things happen that throw the project off track. In my experience, software surprises are never good news.
Risk management has become recognized as a best practice in the software industry for reducing the surprise factor. Although we can never predict the future with certainty, we can apply risk management practices to peek over the horizon at the traps that might be looming. Then we can take actions to minimize the likelihood or impact of these potential problems. Risk management means dealing with a concern before it becomes a crisis. This improves the chance of successful project completion and reduces the consequences of those risks that cannot be avoided.
During project initiation take the time to do a first cut at identifying significant risks. It’s possible that the risks will outweigh the potential benefits of the project. More likely, getting an early glimpse of potential pitfalls will help you make more sensible projections of what it will take to execute this project successfully. Build time for risk identification and risk management planning into the early stages of your project. You’ll find that the time you spend assessing and controlling risks will be repaid many times over.
What Is Risk?
A “risk” is a problem that could cause some loss or threaten the success of your project, but which hasn’t happened yet. And you’d like to keep it that way. These potential problems might have an adverse impact on the cost, schedule, or technical success of the project, the quality of your products, or team morale. Risk management is the process of identifying, addressing, and controlling these potential problems before they can do any harm.
Whether we tackle them head-on or keep our heads in the sand, risks have a potentially huge impact on many aspects of our project. The tacit assumption that nothing unexpected will derail the project is simply not realistic. Estimates should incorporate our best judgment about the potentially scary things that could happen on each project, and managers need to respect the assessments we make. Risk management is about discarding the rose-colored glasses and confronting the very real potential of undesirable events conspiring to throw the project off track.
Why Manage Risks Formally?
A formal risk management process provides multiple benefits to both the project team and the development organization as a whole. First, it gives us a structured mechanism to provide visibility into threats to project success. By considering the potential impact of each risk item, we can focus on controlling the most severe risks first. We can marry risk assessment with project estimation to quantify possible schedule slippage if certain risks materialize into problems. This approach helps the project manager generate sensible contingency buffers. Sharing what does and does not work to control risks across multiple projects helps the team avoid repeating the mistakes of the past. Without a formal approach, we cannot ensure that our risk management actions will be initiated in a timely fashion, completed as planned, and effective.
Controlling risks has a cost. We must balance this cost against the potential loss we could incur if we don’t address the risk and it does indeed bite us. Suppose we’re concerned about the ability of a subcontractor to deliver an essential component on time. We could engage multiple subcontractors to increase the chance that at least one will come through on schedule. That’s an expensive remedy for a problem that might not even materialize. Is it worth it? It depends on the downside we incur if indeed the subcontractor dependency causes the project to miss its planned ship date. Only you can decide for each individual situation.
Typical Software Risks
The list of evil things that can befall a software project is depressingly long. The enlightened project manager will acquire lists of these risk categories to help the team uncover as many concerns as possible early in the planning process. Potential risks to consider can come from group brainstorming activities or from a risk factor chart accumulated from previous projects. In one of my groups, individual team members came up with descriptions of the risks they perceived, which I edited together and we then reviewed as a team.
Following are several typical risk categories and some specific risks that might threaten your project. Have any of these things have happened to you? If so, add them to your master risk checklist to remind future project managers to consider if it could happen to them, too. There are no magic solutions to any of these risk factors. We need to rely on past experience and a strong knowledge of software engineering and management practices to control those risks that concern us the most.
Dependencies
Some risks arise because of dependencies our project has on outside agencies or factors. We cannot usually control these external dependencies. Mitigation strategies could involve contingency plans to acquire a necessary component from a second source, or working with the source of the dependency to maintain good visibility into status and detect any looming problems. Following are some typical dependency-related risk factors:
Customer-furnished items or information.
Internal and external subcontractor relationships.
Inter-component or inter-group dependencies.
Availability of trained and experienced people.
Reuse from one project to the next.
Requirements Issues
Many projects face uncertainty and turmoil around the product’s requirements. Some uncertainty is tolerable in the early stages, but the threat increases if such issues remain unresolved as the project progresses. If we don’t control requirements-related risks we might build the wrong product or build the right product badly. Either outcome results in unpleasant surprises and unhappy customers. Watch out for these risk factors:
Lack of a clear product vision.
Lack of agreement on product requirements.
Inadequate customer involvement in the requirements process.
Inadequate impact analysis of requirements changes.
Management Issues
Although management shortcomings affect many projects, don’t be surprised if your risk management plan doesn’t list too many of these. The project manager often leads the risk identification effort, and most people don’t wish to air their own weaknesses (assuming they even recognize them) in public. Nonetheless, issues like those listed here can make it harder for projects to succeed. If you don’t confront such touchy issues, don’t be surprised if they bite you at some point. Defined project tracking processes and clear project roles and responsibilities can address some of these conditions.
Inadequate planning and task identification.
Inadequate visibility into project status.
Unclear project ownership and decision making.
Unrealistic commitments made, sometimes for the wrong reasons.
Managers or customers with unrealistic expectations.
Staff personality conflicts.
Lack of Knowledge
Software technologies change rapidly and it can be difficult to find suitably skilled staff. As a result, our project teams might lack the skills we need. The key is to recognize the risk areas early enough so we can take appropriate preventive actions, such as obtaining training, hiring consultants, and bringing the right people together on the project team. Consider whether the following factors apply to your team:
Lack of training.
Inadequate understanding of methods, tools, and techniques.
Insufficient application domain experience.
New technologies or development methods.
Ineffective, poorly documented, or ignored processes.
Technical approaches that might not work.
Outsourcing
Outsourcing development work to another organization, possibly in another country, poses a whole new set of risks. Some of these are attributable to the acquiring organization, others to the supplier, and still others are mutual risks. If you are outsourcing part of your project work, watch out for the following risks:
Acquirer’s requirements are vague, ambiguous, incorrect, or incomplete.
Acquirer does not provide complete and rapid answers to supplier’s questions or requests for information.
Supplier lacks appropriate software development and management processes.
Supplier does not deliver components of acceptable quality on contracted schedule.
Supplier is acquired by another company, has financial difficulties, or goes out of business.
Supplier makes unachievable promises in order to get the contract.
Supplier does not provide accurate and timely visibility into actual project status.
Disputes arise about scope boundaries based on the contract.
Import/export laws or restrictions pose a problem.
The second article in this series will describe the various activities associated with the practice of risk management and recommend the specific bits of information you should record about each risk you identify.
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.
In the first part of this two-part series I described the value of managing risks formally on a software project and listed numerous common risks in various categories. This article describes the various activities associated with the practice of risk management and recommends specific information you should record about each risk you identify.
Risk Management Components
As with other project activities, begin risk management by developing a plan, perhaps using the risk management plan template available at www.ProjectInitiation.com. Small projects can include a concise risk management plan as a section within the overall project plan. Risk management consists of the activities illustrated in Figure 1 and described below.
Risk Assessment
Risk assessment is the process of examining a project to identify areas of potential risk. Risk identification can be facilitated with the help of a checklist of common risk areas for software projects, as I described in the first article in this series. Risk analysis examines how project outcomes might change with modification of risk input variables. In other words, just how could the risk harm your project.
Loss
Probability
Low
Medium
High
Low
Low
Low
Medium
Medium
Low
Medium
High
High
Medium
High
High
Figure 2: Risk exposure is a function of probability and potential loss.
Risk prioritization helps the project focus on its most severe risks by assessing the risk exposure. Exposure is the product of the probability of incurring a loss due to the risk and the potential magnitude of that loss. I usually estimate the probability from 0.1 (highly unlikely) to 1.0 (certain to happen), and the loss (also called impact) on a relative scale of 1 (no problem) to 10 (deep tapioca). Multiplying these factors together provides an estimate of the risk exposure due to each item, which can run from 0.1 (don’t give it another thought) through 10 (stand back, here it comes!). It’s simpler to estimate both probability and loss as High, Medium, or Low. Figure 2 shows how you can estimate the risk exposure level as High, Medium, or Low by combining the probability and loss estimates.
Risk Avoidance
Risk avoidance is one way to deal with a risk: don’t do the risky thing! You might avoid risks by not undertaking certain projects, or by relying on proven rather than cutting-edge technologies when possible. You might be able to transfer a risk to some other party, such as a subcontractor.
Risk Control
Risk control is the process of managing risks to achieve the desired outcomes. Risk management planning produces a plan for dealing with each significant risk, including mitigation approaches, owners, and timelines. Risk resolution entailsexecuting the plans for dealing with each risk. That’s when you actually control the risk. Finally, risk monitoring involves tracking your progress toward resolving each risk item.
Let’s look at an example of risk management planning. Suppose the “project” is to take a hike through a swamp in a nature preserve. You’ve heard the swamp might contain quicksand, so the risk is that we might step in quicksand and be injured or even die. One strategy to mitigate this risk is to reduce the probability of the risk actually becoming a problem. A second option is to consider actions that could reduce the impact of the risk if it does in fact become a problem. So, to reduce the probability of stepping in the quicksand, we might look for signs of quicksand as we walk and draw a map so we can avoid these areas on future walks. To reduce the impact if someone does step in quicksand, the members of the tour group could rope themselves together. That way if someone does encounter some quicksand the others could quickly pull him to safety.
Even better, is there some way to prevent the risk from becoming a problem under any circumstances? Maybe we build a boardwalk as we go so we avoid the quicksand. That will slow us down and cost some money. But, we don’t have to worry about quicksand any more. The very best strategy is to eliminate the root cause of the risk entirely. Perhaps we should drain the swamp, but then it wouldn’t be a very interesting nature walk. By taking too aggressive a risk approach, you can eliminate the factors that make a project attractive in the first place.
Documenting Risks
Simply identifying the risks facing a project is not enough. We need to write them down in a way that lets us communicate the nature and status of risks throughout the affected stakeholder community over the duration of the project. Figure 3 shows a form I’ve found to be convenient for documenting risks. It’s a good idea to keep the risk list itself separate from the risk management plan, as you’ll be updating the risk list frequently throughout the project. You can download an alternative template for your risk list from www.ProjectInitiation.com. This format includes essentially the same information that’s in Figure 3, but it’s laid out in a way that’s amenable to storing in a spreadsheet or as a table in a word-processing document.
ID:<sequence number or a more meaningful label>
Description: <List each major risk facing the project. Describe each risk in the form “condition – consequence.”>
Probability: <What’s the likelihood of this risk becoming a problem?>
Loss: <What’s the damage if the risk does become a problem?>
Exposure: <Multiply Probability times Loss.>
First Indicator:<Describe the earliest indicator or trigger condition that might indicate that the risk is turning into a problem.>
Mitigation Approaches:<State one or more approaches to control, avoid, minimize, or otherwise mitigate the risk.>
Owner:<Assign each risk mitigation action to an individual for resolution.>
Date Due: <State a date by which the mitigation approach is to be implemented.>
Figure 3: A risk documentation form.
Use a condition–consequence format when documenting risk statements. That is, state the risk situation (the condition) that you are concerned about, followed by at least one potential adverse outcome (the consequence) if that risk should turn into a problem. Often, people suggesting risks state only the condition—“The customers don’t agree on the product requirements”—or the consequence—“We can only satisfy one of our major customers.” Pull those together into the condition-consequence structure: “The customers don’t agree on the product requirements, so we’ll only be able to satisfy one of our major customers.” This statement doesn’t describe a certain future, just a possible outcome that could harm the project if the condition isn’t addressed.
Keep the items with high risk exposures at the top of your priority list to focus your risk-control energy. Set goals for determining when each risk item has been satisfactorily controlled. Your mitigation approaches for some items may focus on reducing the probability, whereas the approach for other risks could emphasize reducing the potential loss or impact. With any luck, some of your mitigation strategies will help you control multiple risk factors.
Risk Tracking
As with other project management activities, you need to get into a rhythm of periodic monitoring. You may wish to appoint a risk manager for the project. The risk manager is responsible for staying on top of the things that could go wrong, just as the project manager stays on top of the activities leading to project completion. It’s a good idea to have someone other than the project manager serve as the risk manager. The project manager is focused on what he has to do to make a project succeed. The risk manager, in contrast, is identifying factors that might prevent the project from succeeding. In other words, the risk manager is looking for the black cloud around the silver lining that the project manager sees. Asking the same person to take these two opposing views of the project can lead to cognitive dissonance; in an extreme case, his brain can explode.
Keep the top ten risks highly visible and track the effectiveness of your mitigation approaches regularly. New risks might float up into the top ten as you gradually beat the initial list of top priority items into submission. You can drop a risk off your radar when your mitigation approaches have reduced the risk exposure from that item to an acceptable level. Don’t conclude that a risk is controlled simply because the selected mitigation action has been completed. Controlling a risk might require you to change the risk control strategy if you conclude it isn’t working.
A student in a seminar once asked, “What should you do if you have the same top five risks week after week?” A static risk list suggests that your risk mitigation actions aren’t working. Effective mitigation actions should lower the risk exposure as the probability, the loss, or both decrease over time. If your risk list isn’t changing, check to see whether the planned mitigation actions have been carried out and whether they had the desired effect.
Also, look for new risks that might arise during the course of the project. Conditions can change, assumptions can prove to be wrong, and other factors might lead to risks that weren’t apparent or perhaps did not even exist at the beginning of the project. Escalate risks that aren’t being controlled to the attention of senior managers or other stakeholders. They can then either stimulate corrective actions or else make a conscious business decision to proceed in spite of the risks.
Learning from the Past
We can’t predict exactly which of the many threats to our projects might come to pass. However, most of us can do a better job of learning from previous experiences to avoid the same pain and suffering on future projects. As you begin to implement risk management approaches, record your actions and results for future reference. The risks are out there. Find them before they find you.
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.
Software engineers are eternal optimists. When planning software projects, we usually assume that everything will go exactly as planned. Or, we take the other extreme position: the creative nature of software development means we can never predict what’s going to happen, so what’s the point of making detailed plans? Both of these perspectives can lead to software surprises, when unexpected things happen that throw the project off track. In my experience, software surprises are never good news.
Risk management has become recognized as a best practice in the software industry for reducing the surprise factor. Although we can never predict the future with certainty, we can apply risk management practices to peek over the horizon at the traps that might be looming. Then we can take actions to minimize the likelihood or impact of these potential problems. Risk management means dealing with a concern before it becomes a crisis. This improves the chance of successful project completion and reduces the consequences of those risks that cannot be avoided.
During project initiation take the time to do a first cut at identifying significant risks. It’s possible that the risks will outweigh the potential benefits of the project. More likely, getting an early glimpse of potential pitfalls will help you make more sensible projections of what it will take to execute this project successfully. Build time for risk identification and risk management planning into the early stages of your project. You’ll find that the time you spend assessing and controlling risks will be repaid many times over.
What Is Risk?
A “risk” is a problem that could cause some loss or threaten the success of your project, but which hasn’t happened yet. And you’d like to keep it that way. These potential problems might have an adverse impact on the cost, schedule, or technical success of the project, the quality of your products, or team morale. Risk management is the process of identifying, addressing, and controlling these potential problems before they can do any harm.
Whether we tackle them head-on or keep our heads in the sand, risks have a potentially huge impact on many aspects of our project. The tacit assumption that nothing unexpected will derail the project is simply not realistic. Estimates should incorporate our best judgment about the potentially scary things that could happen on each project, and managers need to respect the assessments we make. Risk management is about discarding the rose-colored glasses and confronting the very real potential of undesirable events conspiring to throw the project off track.
Why Manage Risks Formally?
A formal risk management process provides multiple benefits to both the project team and the development organization as a whole. First, it gives us a structured mechanism to provide visibility into threats to project success. By considering the potential impact of each risk item, we can focus on controlling the most severe risks first. We can marry risk assessment with project estimation to quantify possible schedule slippage if certain risks materialize into problems. This approach helps the project manager generate sensible contingency buffers. Sharing what does and does not work to control risks across multiple projects helps the team avoid repeating the mistakes of the past. Without a formal approach, we cannot ensure that our risk management actions will be initiated in a timely fashion, completed as planned, and effective.
Controlling risks has a cost. We must balance this cost against the potential loss we could incur if we don’t address the risk and it does indeed bite us. Suppose we’re concerned about the ability of a subcontractor to deliver an essential component on time. We could engage multiple subcontractors to increase the chance that at least one will come through on schedule. That’s an expensive remedy for a problem that might not even materialize. Is it worth it? It depends on the downside we incur if indeed the subcontractor dependency causes the project to miss its planned ship date. Only you can decide for each individual situation.
Typical Software Risks
The list of evil things that can befall a software project is depressingly long. The enlightened project manager will acquire lists of these risk categories to help the team uncover as many concerns as possible early in the planning process. Potential risks to consider can come from group brainstorming activities or from a risk factor chart accumulated from previous projects. In one of my groups, individual team members came up with descriptions of the risks they perceived, which I edited together and we then reviewed as a team.
Following are several typical risk categories and some specific risks that might threaten your project. Have any of these things have happened to you? If so, add them to your master risk checklist to remind future project managers to consider if it could happen to them, too. There are no magic solutions to any of these risk factors. We need to rely on past experience and a strong knowledge of software engineering and management practices to control those risks that concern us the most.
Dependencies
Some risks arise because of dependencies our project has on outside agencies or factors. We cannot usually control these external dependencies. Mitigation strategies could involve contingency plans to acquire a necessary component from a second source, or working with the source of the dependency to maintain good visibility into status and detect any looming problems. Following are some typical dependency-related risk factors:
Customer-furnished items or information.
Internal and external subcontractor relationships.
Inter-component or inter-group dependencies.
Availability of trained and experienced people.
Reuse from one project to the next.
Requirements Issues
Many projects face uncertainty and turmoil around the product’s requirements. Some uncertainty is tolerable in the early stages, but the threat increases if such issues remain unresolved as the project progresses. If we don’t control requirements-related risks we might build the wrong product or build the right product badly. Either outcome results in unpleasant surprises and unhappy customers. Watch out for these risk factors:
Lack of a clear product vision.
Lack of agreement on product requirements.
Inadequate customer involvement in the requirements process.
Inadequate impact analysis of requirements changes.
Management Issues
Although management shortcomings affect many projects, don’t be surprised if your risk management plan doesn’t list too many of these. The project manager often leads the risk identification effort, and most people don’t wish to air their own weaknesses (assuming they even recognize them) in public. Nonetheless, issues like those listed here can make it harder for projects to succeed. If you don’t confront such touchy issues, don’t be surprised if they bite you at some point. Defined project tracking processes and clear project roles and responsibilities can address some of these conditions.
Inadequate planning and task identification.
Inadequate visibility into project status.
Unclear project ownership and decision making.
Unrealistic commitments made, sometimes for the wrong reasons.
Managers or customers with unrealistic expectations.
Staff personality conflicts.
Lack of Knowledge
Software technologies change rapidly and it can be difficult to find suitably skilled staff. As a result, our project teams might lack the skills we need. The key is to recognize the risk areas early enough so we can take appropriate preventive actions, such as obtaining training, hiring consultants, and bringing the right people together on the project team. Consider whether the following factors apply to your team:
Lack of training.
Inadequate understanding of methods, tools, and techniques.
Insufficient application domain experience.
New technologies or development methods.
Ineffective, poorly documented, or ignored processes.
Technical approaches that might not work.
Outsourcing
Outsourcing development work to another organization, possibly in another country, poses a whole new set of risks. Some of these are attributable to the acquiring organization, others to the supplier, and still others are mutual risks. If you are outsourcing part of your project work, watch out for the following risks:
Acquirer’s requirements are vague, ambiguous, incorrect, or incomplete.
Acquirer does not provide complete and rapid answers to supplier’s questions or requests for information.
Supplier lacks appropriate software development and management processes.
Supplier does not deliver components of acceptable quality on contracted schedule.
Supplier is acquired by another company, has financial difficulties, or goes out of business.
Supplier makes unachievable promises in order to get the contract.
Supplier does not provide accurate and timely visibility into actual project status.
Disputes arise about scope boundaries based on the contract.
Import/export laws or restrictions pose a problem.
The second article in this series will describe the various activities associated with the practice of risk management and recommend the specific bits of information you should record about each risk you identify.
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.
