ISO 26262 Planning Requirements are Not Enough

Every project has a plan that includes schedule and resource estimates. For functional safety related projects, the ISO 26262 standard for road vehicle product development requires a Safety Plan. This plan is required to describe the schedule, resources (competencies), and the safety work product development and delivery. Many companies develop safety plans that meet these planning requirements but is this level of plan good enough to deliver on time, on budget, and at the agreed upon quality levels?

In contrast, the Automotive SPICE MAN.3 process area requires the rigor needed to manage a complex software project. Smart organizations are applying the MAN.3 base practices to all of the functional development areas of their ISO 26262 compliant functional safety projects.

I will look at 3 base practices in MAN.3 (PAM 3.0) that could benefit project and safety managers running safety related projects: feasibility (BP 3), resource estimation (BP 5), and project interfaces (BP 7). Scope (BP 1), while critical, is typically not an issue in a safety plan due to the part 3 emphasis on Item definition.

The planning requirement to evaluate the feasibility of a project always raises questions with project managers and safety managers new to MAN.3. They either laugh (‘of course this project isn’t feasible but we can’t say that’) or get really excited (‘this is a great way to ask the teams some hard questions’).   Undertaking an ISO 26262 development is an enormous task.  By using feasibility analysis, project managers and safety managers need to have conversations about resources estimates, schedule requirements, and technical reality up front.  Feasibility should be data driven and ideally based on past performance.  Feasibility is directly related to risk. Make sure to include feasibility risks in the project risk assessment with triggers and backup plans in the case those risks become reality.

The second practice, BP 5, moves beyond work break down estimation to including estimation of effort, hardware and software resources, all human resources, and materials.  Good resource estimation is process driven, monitored for accuracy, and adjusted based on historical data. When planning the fault tree analyses, for example, historical data of time -vs- the number of safety requirements in scope for the analysis could be used to plan the effort and to support the schedule feasibility.  BP 5 requires evidence that the estimation process was followed, which supports the collection of data that can over time be used to make better estimates.

The third planning requirement is the identification of communication interfaces and the monitoring of agreed commitments (BP 7). Smart organizations structure their communications and regularly report progress against defined metrics to the stakeholders. This could be done under a lifecycle like APQP, a toll gate process, through Agile ceremonies, or using a custom lifecycle.  Consider building dashboards to automate the project metrics, highlight thresholds, and subscribe stakeholders to receive updates.  The old fashioned monthly project review works as long as it is diligently followed and the meeting results are published and easily accessible (i.e. on the project portal). Don’t forget to define an escalation plan for the project when thresholds are crossed. By including the communication plan in the safety plan (or the accompanying project plan), stakeholders know how and when the monitoring of commitments will be done. By the way, BP 7 also applies to interfaces between different groups, with suppliers, or with the customer.

We encourage you to take your safety planning to the next level by borrowing from the ASPICE playbook. Your stakeholders will thank you.