How to Capture Your Processes and Regulatory Requirements in ALM

Mature Organizations: How can we ensure our teams are following internal and industry guidelines? Is there a way to automate our internal auditing process to discover gaps and identify improvement areas?

Teams: How can we demonstrate compliance while minimizing additional overhead? How do we know whether we following the correct guidance for each project? Have work product requirements changed during implementation, and if so, what is the impact to our workflow?

Consistent project execution and compliance with functional safety and ISO 26262 standards require both well-defined internal process guidelines and team specific workflows. Whether your organization is just beginning to capture this information or already has a wealth of documentation, there are challenges in keeping it up to date, ensuring teams are making the most use out of them, and perhaps most importantly: ensuring they are being followed and are providing value.

There is nothing more wasteful than spending time documenting best practices and defining team workflows only for them to fall into irrelevance. This can happen in any number of ways:

• A team spends a few man weeks defining their standard project implementation procedures only to end up with an “ideal” workflow that they aren’t ready to follow.
• Teams download a copy of the “latest” version of an internal process guidance document. The document is later updated but the teams continue to use their outdated copy.
• References between workflows and the guidance they adhere to are not kept up to date.

Outdated, unused or misused documentation increases risk of implementation errors and complicates compliance audits. How can this be avoided?

Application lifecycle management (ALM) solutions are considered essential for managing many aspects of product development, such as requirements, project execution, testing, and issue tracking. What if ALM could be used to better manage not just the product development itself, but the workflows that teams execute during product development? And what if pieces of those workflows can be linked directly to guidance and industry standards that they are complying with? Let’s explore what that looks like and how it can help organizations.

Treat guidance as requirements

Better usage of guidance starts with treating them as high-level functional safety requirements that drive project implementation. Like any other project requirements, they should be stored in a repository that offers change and configuration management, access control, and traceability.

One option is a requirements management tool like DOORS® Next Generation, part of IBM’s Jazz ecosystem, that includes solutions for configuration management, task tracking, test management, model-based systems engineering, and reporting. In DOORS® Next Generation, guidance documents can be stored as modules, retaining their structure while allowing specific pieces of the document to be treated as individual requirements. These can then be linked off to other items such as tasks, test cases or other requirements.

As standards and regulations evolve, teams will need to ensure that they are adhering to the proper standards for each project they are working on. For example, they may need to adopt a new revision for new and just-started projects while allowing other projects to stick with a previous revision. DOORS® Next Generation’s configuration management capabilities allow teams to pick out which revisions apply to specific projects directly in the tool. When team members work in the system, they will only see the revision that applies to the project they are currently working on, eliminating confusion and ensuring the correct guidelines are being used.

Figure 1:Projects formally adopt specific guidance revisions

Link guidance to team-level procedures and project plans

Most teams have a typical way of working, or workflow, to execute a project. Teams using task management systems such as Jira® or IBM® Engineering Workflow Management (formerly IBM® Rational Team Concert), they may even have predefined work items they generate for each major project phase. But how easily can they prove these tasks are fulfilling certain standards? The tasks themselves may contain work instructions that reference those standards and may even link to source documentation, but this kind of information is usually not structured well enough to feed into reporting systems.

If standards guidance is treated in the same way as requirements, then demonstrating compliance can be achieved through linking work performed to specific compliance requirements. This is much easier to build reports around and can help organizations answer questions that would otherwise require a meeting or set of emails. As nice as this sounds, it would be inefficient and time consuming to manually create these links every time a project is created. Teams could reduce this burden by embedding these links in their own team-level guidance that serves as a project template.

Let’s take a team that develops automatic lane centering systems (ALCS). For each ALCS variant they execute some recurring tasks, one of which is a vehicle-level safety analysis that produces a document that conforms with the ISO 26262 Hazard Analysis and Risk Assessment (HARA) work product. The team understands this task fulfills this part of the Functional Safety standard, and the task itself may state this somewhere in its description, but compliance teams would have a hard time discovering this information on their own. Instead, they would need to send an email to the team or organize a meeting to go through their project plan to discover this information.

Instead of documenting this task’s expected output - the HARA work product - in the description, the team can create a link to the work product requirement itself. By doing so, they are formalizing the task’s relation to the Functional Safety standard and enabling traceability that will allow the compliance team to discover the task by looking at the work product itself and inspecting links off to teams’ project plans where it is being produced.

If the team does this with all their tasks that produce ISO 26262 work products, this gives them – and the compliance team – the ability to inspect their project plan for potential gaps. If a work product is not linked to any task in the team’s plan, they can use that information to determine whether the gap exists for a valid reason and if their project plan needs to be modified. If the team keeps a template of these recurring tasks along with their links to their related work products, future projects will inherit these links, thus not only ensuring more consistent adherence to the standard but also reducing compliance overhead.

There is no question there is some upfront effort involved that will require teams to inspect their processes and pick out areas where they comply with guidance and add, if needed, extra tasks to cover gaps. For some teams, this may require formally documenting their entire workflow for the first time. For agile teams, this may sound like a path back to formal project management, but that does not need to be the case: while some may opt to create a work breakdown structure of tasks and activities, others could define higher-level items that feed into a project backlog.

Figure 2: Traceability from standards to team workflows and project execution

By placing their documentation into the same configuration management system and linking them to applicable standards, teams will reap future benefits: less time gathering information for compliance auditing, less effort managing changes to their process and adopting new guidance, and better visibility over their own workflows.

Track compliance with traceability reporting and dashboard visualizations

One of the most powerful benefits of this solution is the automated, real-time reporting that can be generated from it, such as:

• Track guidance adoption among teams, identify compliance gaps
• Track project status at the compliance level (e.g., which teams still need to complete a work product)
• Identify deviations from guidance such to drive retrospectives and continuous improvement initiatives

Figure 3: Dashboard showing work product status across multiple systems under development

Another great benefit is the ability to run impact analysis on proposed changes to guidance: if a particular work product or procedure is expected to change, the same reporting system that can track compliance can also be used to identify where the change is expected to impact each teams’ workflows.

Taken as a whole this functionality can lead to improved compliance, more consistent project execution, and less manual effort needed to execute audits.

Summary

Applying application lifecycle management practices to standards and enabling teams to bake in compliance at their workflow level can help organizations resolve the numerous issues with managing standards in a separate, disconnected repository. It brings powerful features to the table that can help teams more consistently adhere to standards while reducing the effort needed to demonstrate compliance to management or auditors.

Management and compliance teams have better visibility over standards adherence, and using the reporting systems available in ALM solutions, they have the capability of seeing in real-time where each project or team stands without needing to call a meeting. The end result is more consistent verifiable adherence to standards, improving product quality and safety.

Interested in learning more about ALM for your organization? Contact our team today!