Introduce STPA to your organisation

New methods are never easy in implementation. The larger the organisation, the more challenging it becomes to introduce changes to the workflow. STPA can be very agile method of working for development teams, or it can function as a unit working in parallel with multiple development teams. All depends on the project complexity and company/companies structure. Today we will try to explain how You can use modern safety analysis, to improve the way of executing the projects in the organisations. How to beat all the obstacles, and fear about the implementation of new methods of working. To introduce STPA to your organisation, firstly You need to ask a question:

Is Your organisation ready for STPA?

Simple answer is no. Thank You, end of a paragraph. The more complex system your company is designing, the stronger the need for STPA is. Therefore it might be very cost effective for the projects, to realise them with STPA method. Today’s systems, which contain multiple hardware disciplines, multiple software stacks, are unbelievably complex. It’s not easy to understand how they work as one complete systems. Often there is available only integration between the certain components. As long as everything is working correctly, that’s fine. But once there is a fail in certain subsystem, it can influence overall operation. Here STPA can help and close the gaps. (If You wonder how, check our STPA Handbook or check 150 pages handbook from MIT.

Let’s say, Your company implements complex projects. You have a lot of costs on the end of the project. Engineering go fine, but during commissioning You need to implement a lot of changes. Why it’s like that? Most probably, system haven’t been analised during the concept and engineering. So you doing the analysis during commissioning and you discover a gaps. We all have been there. That’s painful and very costly. However if you perform STPA analysis at the beginning, during the concept phase, you would understand the details of the processes entirely, and you could do changes in the documentation during engineering phase, when you have just paperwork. No additional expensive hours during commissioning. If you are still with us, now I think I changed No into Maybe, and we are ready to try STPA. But here comes the most iconic questions: But how?

Setting up a ground for STPA Introduction

You made decision that you want to start. That’s a good starting point. You have 2 options, easy and difficult.

Option 1: You hire dedicated employee, or you delegate a task to dedicated employee, to introduce STPA into organisation. All the handbooks from MIT are available in the web, for free. You just need a time, and tools to implement them.
Option 2: You approach someone experience in STPA to help You introduce methodology into organisation. This can be Safetonomy or other experts.

Let’s say you choose option 1. Your organization have enough resources to take care of the project by itself. Great. You have dedicated person. Next steps is to establish workshops and presentation of methodology to the project team. It’s important to challenge the team with proper presentation. The more interactive presentation is, the better for the stakeholders, and STPA leader. During the workshops on some example, can be project related but it’s not necessary, method leader should focus on asking a questions to the team, and lead the notes. Notes from the workshop should be taken according to the method standard. Initial education of the team, should prove to the team that method is solving their issues. This is the role of a STPA leader.

That’s not important if You choose option 1 or 2. Let’s say after initial workshop, stakeholders see a positive outcome. They are committed to implement regular workshops, identifying UCA’s and discuss mitigations. There is also a green light from management. So this is a right time for pilot project.

Start the pilot project

In our opinion, that’s the most important step in implementation of STPA to the organization. Why? You warmed up the team with nice presentation and first workshops. You implement couple of good stories, and jokes. Atmosphere is good, but now it’s time to progress some real work. So You need to choose a manageable scope for a first pilot program. It should be part of your real scope. You need to take care of a scope, planning, execution and reflection on the results. (Most probably discussed with Your superiors)

Scope of STPA Pilot – How to introduce STPA to your organisation

Benefit here is that STPA can be used with zoom in and zoomed out scope. So I suggest to zoom in to certain area, where scope is already quite defined. Pilot project should be manageable in the scope. It’s better when pilot is to small, then too large. Also, better to naturally expand scope from pilot project, when team is still working in proper way, then exceeding the scope for complete project, and lost the pace in the middle of the process. It’s important to go through all the steps, prepare a complete documentation, and do a reflection about the process.

Planning

Planning is also very important. It’s good to schedule a weekly or bi-weekly meetings. It should cover the scope for a 4 weeks. That planning, should allow to keep team motivated, and management curious about the first results. Depend of the scope size, amount of session during the week, and length of workshops should be adjusted.

How to plan a team? In our experience perfect team is built from domain experts (2-3 people), end users/end customer (2-3 people), and STPA Leader (1 person). Dependable on the complexity of the project, amount of domains which are connected by the project, 7 people is a top line. More will not bring much benefit, and I would suggest to downsize the team if possible. Dependent of the topic, team can be rotated. Let’s say You have different domain experts if You discuss control of the physical process, and different people when You discuss software infrastructure. So role of STPA leader is to estimate, who is needed on which session.

Documentation: Depend on the project and the domain, different types of documentation should be the outcome of STPA. According to the methodology, we should have defined all loss scenarios, and mitigations of this events. However it’s quite easy to generate functional descriptions of the systems, acceptance criteria and other types of documents. It should be agreed at the beginning what should be the outcome of pilot process, and how STPA should help your organisation.

Reflection

After successful pilot, complete team should be presented with the outcome from the sessions. This should cover creation of summary document of findings, and all identified loss scenarios and other documents which You have agreed on during the planning. You should collect feedback from a team, to improve the process in your organization. We just gave You a few tips which have to be followed during first time you perform STPA. However every organization is different, and may benefit from this methodology in the different way. It’s important to develop your own way, or adjust the method to your needs.

Building internal capabilities vs External Expertise

Like every decision in our life, there are pros and cons. If you want to build up STPA capabilities in your organisation, You would need a time. This might take few months, to build up the knowledge, and confidence in applying the methodology. That’s absolutely OK. This is tradeoff, which you need to make. You will gain a method knowledge, and adjust it to the company existing workflow. Having inside experience and expertise is always a good thing, if your organization is big enough. But there is other way.

Other scenario is to hire experts (You can do this here!), to implement method to the team. Let say your organization is big enough, but you don’t have few months, you need results in few months. You can get quick knowledge transfer and implementation of the right tools, and working methods. During the pilot project, you can potentially start to handover STPA leader position to someone from the organisation. Depend of the needs, planning can be adjusted that external consultant starts the process, and slowly steps out when organization takes over responsibility. Consultant still can participate in the process to advice where should be more focus, and over the time step out completely. You achieve fast implementation, corrections, and efficient use of the teams time.

So as always, there are tradeoffs, and You need to decide by yourself, what is the best solution in your situation.

If You are curious how STPA method is working, and you want to implement it to your organisation internally we recommend to start with following documents:

STPA Handbook – that’s an absolute must have
Create a presentation for the superiors and team to explain the methodology
Find the tools which You might want to use
Kick off the STPA Workshops