STPAHow Many of Your Safety Analysis Actions Are Actually Closed? — Managing FMEA and STPA Actions Like Risks and Schedules

VisualPro Tech Brief

Illustration of action cards flowing from an FMEA table into a Gantt schedule; on every card the owner slot is an empty orange dashed outline.

How Many of Your Safety Analysis Actions Are Actually Closed? — Managing FMEA and STPA Actions Like Risks and Schedules

Driving FMEA and STPA actions to closure with an owner, a due date and evidence — 12 transmission DFMEA actions on a workboard, trace table and Gantt

FMEA and STPA Action Tracking | Risk and Schedule Management | VWAY Safety Analysis Column · 2026-10-19

AIAG-VDA FMEA Step 6STPARisk registerGantt scheduleRecoble workboardMCP

The analysis data in this article comes from the transmission DFMEA example project in VisualPro and does not reflect any particular customer's results.

01Summary (TL;DR)

When a safety analysis such as FMEA (Failure Mode and Effects Analysis) or STPA (System-Theoretic Process Analysis) is finished, every failure cause it finds produces an improvement action. Analysis standards require each action to record an owner, a target date, a status and evidence. Yet once the analysis file is approved, it is often unclear who checks those fields every week. For the project manager (PM), these actions are part of the risk register and the issue schedule, yet they rarely appear on the PM's schedule. This article moves 12 improvement actions from a transmission design FMEA (DFMEA) onto a Recoble workboard, so that safety engineers can trace each failure cause and PMs can see owners, due dates and delays in one place.

02The analysis is approved. Who is watching the actions?

The day an analysis report is approved is the end for the analysis team, but from a risk point of view it is the beginning. Risk only goes down when the improvement actions decided in the analysis actually make it into the design, the tests and the maintenance documents.

The screen below is Step 6 (Optimization) of the transmission DFMEA example project in VisualPro. Prevention and detection actions are written for all 12 failure causes with an action priority (AP) of H or M, and every AP after the action is predicted to be L. As an analysis, it is in good order.

VisualPro DFMEA Step 6 Optimization screen — prevention and detection actions per failure cause, with AP before (H) and after (L) the action

Select an action row and the fields for the responsible person, target completion date and status appear below it. At the very bottom there is also a field for "action taken with pointer to evidence".

VisualPro action detail panel — the target completion date (12/31/2026) is filled in, but the responsible person field is empty

Query the 12 actions in this example and every target completion date is filled in, but the responsible person field is empty in all 12. That may be because it is example data. Still, the same thing happens in practice. In the analysis meeting the team settles on something like "the controls team will handle it", and that agreement never makes it down into the field in the file.

The action texts reveal one more thing. Among the 12 are tasks that must be handled outside the design team, such as "specify the filter replacement interval in the maintenance manual". And two failure causes (gear shift failure due to a stuck hydraulic valve, and loss of hydraulic control) share exactly the same action. They are two rows in the analysis table but one piece of work in reality.

03What these actions mean to a PM: the missing rows in the risk register and issue schedule

The risk register and issue log a PM keeps usually have an owner, a response plan, a status and a due date for each risk. A failure cause found by FMEA is a product risk, while the risk register mainly covers project risks, so the subject is different. The information to manage, however, is the same. The failure cause is the risk, the prevention and detection actions are the response plan, and the target completion date is the due date.

Yet the two lists usually live apart. The safety analysis sits in the analysis tool; the project schedule sits in the PM's Gantt chart or issue tracker. So the PM has to ask the analyst to learn "how many actions that were AP H are due this month" or "whether the actions piling up on the test and evaluation team clash with the test schedule". When a safety action slips, it eventually becomes a schedule risk, but that signal reaches the PM's screen late.

04What existing frameworks ask, and what they do not

Frameworks for managing actions already exist. Let us start by acknowledging what they require.

Existing framework	What it asks	What it does not ask
AIAG-VDA FMEA Handbook, Step 6 (Optimization)	Whether each action records an owner, a target completion date, a status, the action taken with evidence, and S·O·D and AP after the action	Who checks those fields every week after the analysis is done, and where actions spanning several teams can be seen at a glance
STPA Handbook (Leveson & Thomas, 2018)	Whether requirements and constraints have been derived completely from the loss scenarios	Who in the project completes the derived requirements and countermeasures, and by when
ISO 26262-8 Clause 6 (Specification and management of safety requirements)	Whether safety requirements are specified, traced and verified	Where to manage actions that are not software requirements (maintenance documents, supplier confirmations)
Project risk register and issue log	Whether every risk and issue has an owner, a response, a status and a due date	Which failure cause the risk came from, and how far the response lowers the AP in the analysis
ALM and issue trackers (Polarion, codebeamer, Jira, etc.)	The status and traceability of registered requirements and issues	Actions that were never registered, and actions owned by people outside the software team

The AIAG-VDA Handbook already asks for an owner and evidence. The risk register already asks for an owner and a due date. There is nothing new to require. The questions to ask are "are those fields actually filled in, and is someone looking at them every week?" and "are the safety analysis actions and the project schedule on the same screen?" The gap is not in the requirements but in the operation.

05Three rules

Rules come before tools. Follow the three below and tracking works whether you use Excel or an ALM.

1Every failure cause (or loss scenario) has at least one disposition.Rule 1

A disposition is either an action or a documented decision not to act, with its rationale. Anything with no disposition must show as "unresolved".

2Every action has one owning team, a due date and a completion criterion.Rule 2

The completion criterion states what must exist for the action to count as done. In this example, VisualPro's detection actions (test and evaluation plans) were carried over as the completion criteria.

3An action is complete only when evidence is attached.Rule 3

Completion is not the owner's declaration; a reviewer changes the status once evidence such as a test report or a revised document is attached.

Think of these as a way to make the principles already in AIAG-VDA Step 6 hold outside the analysis file as well. The three rules also match the rules of a PM's risk register.

06Walking through it: transmission DFMEA → Recoble

We read the 12 AP H and M failure causes and their actions from the transmission DFMEA in VisualPro and moved them into a Recoble workspace. The analysis data was queried through VisualPro MCP, and the notes, workboard and links on the Recoble side were also created through MCP. Moving them by hand gives the same structure.

1) Failure causes become notes (the safety engineer's rationale)

Each failure cause is one heading in a note, with a table underneath for the structure, function, failure mode, S/O/D, AP, and current prevention and detection controls. The rationale behind the analysis stays in this note.

Recoble note — transmission DFMEA failure causes FC-01 and FC-02 organized by heading, with S/O/D, AP and current controls in a table; one link shown to the right of each heading

2) Actions become workboard items (the action and issue list)

One action is one item. The two failure causes that share the same action (FC-01 and FC-03) were merged into a single item, so 12 became 11. Custom fields hold the failure cause number, owning team, AP before and after, severity, completion criterion and verification evidence (file). The target completion date and progress status (planned → not started, in progress → in progress) were carried over from VisualPro as they were. The owning teams are example values assigned to match each action for this article.

Recoble workboard "Transmission DFMEA Action Tracking" — 11 actions with columns for status, priority, assignee, failure cause, owning team, AP before→after, severity, completion criterion and verification evidence; the assignee column is empty throughout

The assignee (person) column was left empty on purpose, because the source had no responsible person. What matters is that the empty column is visible on the board right away. In the weekly meeting, "11 actions with no assignee" can be confirmed on a single screen.

3) Link failure causes to actions, and find the gaps with the trace table

We created a link type called "Countermeasure / addressed failure cause" and linked the failure cause headings in the note to the workboard items. The table view of Recoble's trace screen lays the documents out in order and expands one row per link.

Recoble trace table — FC-01 to FC-12 in the failure cause note and DFMEA-1 to 11 on the action board, shown as 12 linked; FC-01 and FC-03 both link to DFMEA-1

All 12 show as "linked", and you can see that FC-01 and FC-03 lead to the same action. The "1 missing" on the last row is not a failure cause but the row for the note document as a whole. Turn on the missing links filter at the top and only failure causes with no disposition remain, which makes this the screen for checking rule 1 before the meeting.

4) The same items as a Gantt chart (the PM's schedule view)

The PM needs a view that shows the same actions as a schedule. Add a Gantt view to the workboard and the 11 actions spread out as bars up to their target completion dates. It is not a separate schedule but the same data in a different view, so when the analysis side changes a due date, the PM's screen changes with it.

Recoble Gantt view "Action Schedule (Gantt)" — 11 actions shown as bars from October 19, 2026 to their target completion dates (November 30 to January 15, 2027), 0% progress

In this example, November 30 (changing the garter spring groove shape) is the earliest due date, and the due dates cluster between mid-December and mid-January 2027. If you add dependencies between items, you can also see on the schedule which items, such as test slots, are blocking other actions.

5) Review it weekly on a dashboard (the PM's and quality manager's weekly check)

Total actions, completion rate, overdue count and completed count, together with the distribution by status, owning team and AP change, are gathered on one dashboard. As of today all 11 are open and none are overdue yet. By owning team, the mechanical design team has 5, the control software team 4 and the hydraulic design team 2.

Recoble dashboard "Transmission DFMEA Action Status" — 11 total actions, 0% completion, 0 overdue, 0 completed, with charts by status, owning team and AP change

Items that need a decision in the meeting (for example, a decision not to act) are recorded in a meeting note and linked to the item. Later, "why did we decide this?" can be answered straight from the item.

07If you already use an ALM or issue tracker

The source of truth for software safety requirements belongs in the ALM, and double bookkeeping should be avoided. In that case the workboard takes on only two roles. One is a place to manage, under the same rules, actions that do not fit well in the ALM, such as maintenance documents or supplier confirmations. The other is a workspace that records, per failure cause, which ALM ID each action was registered under. A small team or a research project without an ALM can run everything on the workboard alone.

08What to check tomorrow

Analysis owner (safety engineer)

Among the AP H and M failure causes (or loss scenarios) in your last analysis, how many have no disposition?
Do the items you decided not to act on have a rationale and a decision-maker on record?
Does every action state a completion criterion, that is, what must exist for it to count as done?

Project manager and quality manager

How many actions have an empty responsible person field?
Are the safety analysis actions in the project risk register or schedule?
How many AP H actions are due this month, and do they clash with the owning teams' other schedules?
Do the owners of actions outside the design team (maintenance, suppliers, testing) know about their items?

09Closing

The output of a safety analysis is not a report but a list of improvement actions to complete, and from the project's point of view, a list of risks with a schedule. Attach a disposition to every failure cause, and an owner, a due date and evidence to every action, and the analysis ends not on the day it is approved but on the day the last action is closed. Open your last analysis and start by counting how many actions have an empty responsible person field.

10Frequently Asked Questions (FAQ)

Q1Our FMEA tool already has owner and target date fields. Do we need separate tracking?

Filling in a field and checking it every week are different jobs. The analysis tool is opened by the people who do the analysis, so a separate view that action owners and the PM look at weekly makes empty fields and missed dates visible. We recommend keeping the analysis tool as the source of truth and using the workboard to track progress.

Q2Can FMEA actions be managed in the project risk register?

Yes. But with a risk register alone, the link to the failure cause behind each risk and the change in AP after the action are easily lost. The setup in this article links failure cause notes to action items, so the PM sees schedule and ownership while the safety engineer sees rationale and traceability in the same data.

Q3How do we notice when a safety action is running late?

When a workboard item passes its target completion date, the overdue count on the dashboard goes up, and in the Gantt view the bar ends before the today line while still open. Starting the weekly meeting with these two views puts delays straight onto the agenda.

Q4Does every failure cause need its own action?

No. As in this example, one action can address two failure causes. The rule is that no failure cause is left without a disposition. A disposition can be a link to an existing action, or a documented decision not to act, with its rationale.

Q5Does the same approach work for STPA results?

Yes. Put loss scenarios where the failure causes are and safety requirements and countermeasures where the actions are, and the structure is the same. STPA countermeasures include more items outside software, such as operating procedures or HMI wording, so this setup can be even more useful there.

Q6Does AI create the actions automatically?

In this example, AI read the analysis data, moved it into notes and items, and created the links. Deciding what becomes an action, and whether a decision not to act is justified, remains with the analyst and the responsible owner.

An analysis ends not on the day it is approved, but on the day the last action is closed.

References
· AIAG & VDA, FMEA Handbook, 1st Edition, 2019.
· Nancy G. Leveson, John P. Thomas, STPA Handbook, MIT Partnership for Systems Approaches to Safety and Security, 2018. — STPA Handbook (PDF) — MIT PSASS
· ISO 26262-8:2018, Road vehicles — Functional safety — Part 8: Supporting processes.
· Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide).

※ The analysis data in this article comes from the transmission DFMEA example project in VisualPro and does not reflect any particular customer's results. The owning team assignments are examples for illustration. Screens were captured in Recoble and VisualPro on October 19, 2026; the on-screen Korean text has been translated into English for this article. Published by VWAY, developer of VisualPro and Recoble.

VisualPro & Recoble Demo

VWAY Co., Ltd. | sales@vwaycorp.com

See it on real screens, from safety analysis in VisualPro to action and schedule tracking in Recoble.
VisualPro FMEA | VisualPro STPA | Start Recoble for free | VisualPro Lite

Back to list

Newsroom

Technical Resources