How do you promote Systems Engineering Standards adoption?

From the Coaching of Teams perspective, as part of the assessment a corner stone is to know what is the purpose of the organisation. It will be key to check if the standards you want to implement are aligning with this purpose.

As we delve into this evaluation, a paramount task is the identification of key stakeholders who wield influence over the systems engineering domain. Understanding their roles, expectations, and prevailing attitudes towards industry standards is instrumental. This holistic perspective ensures alignment with diverse stakeholder interests, which is fundamental in shaping our proposed changes.

In some companies, especially the ones with a small team, engineers may take different roles in the project at the same time. For example, subsystem or equipment responsible can also perform as systems engineer. Then, s/he can have difficulties to put his subsystem focus aside and adopt systems engineering approach to see the big picture. This difficulty can be highlighted in assessing current state.

When we talk about adoption of system engineering standard, we need 1st to make sure that the standard is fit for the organization and for the project. If it is not fit, it would be challenged to implement. To make the standard fit, we need to carefully design the standard. This includes understanding the stakeholders, their goals, priorities, and define and communicate the project boundary conditions (like resources, technologies, tools, budget, timing, etc.). Only well planned, designed (for the particular organization and project), communicated, organized and managed system engineering standards are executable, can achieve full support by stakeholders and success.

Before any meaningful transformation can take place, it's crucial to thoroughly assess the current state of systems engineering within the organization. This is something I find particularly important in my role at Boeing’s newly established research center in Nagoya. Tools like SWOT analysis, maturity models, and stakeholder interviews offer invaluable insights. For instance, I’ve observed that smaller teams, like ours in Japan, often juggle multiple roles, making it challenging to fully commit to any single standard. This situation requires special consideration during the assessment phase.

I think inclusion of the team in defining the desired state is one of the most important factor to achieve adoption of systems engineering. Adoption of systems engineering requires high level of cooperation and concurrent engineering within the team and it is very difficult to achieve such teamwork without giving them responsibility of defining what state to reach.

Following the assessment, it's essential to articulate a clear vision for what the optimized state of systems engineering looks like for the organization. Within Boeing, we align our objectives with not just technological goals but also the overarching corporate strategy. Involving the team in this vision-setting process ensures collective ownership, which is integral for effective implementation.

Hire a set of skilled Systems Engineers who align with the Companies' SE goals and values. Provide them with necessary training about the goals. And then trust them with the job they were hired for.

In summation, a judicious examination of our current systems engineering state, fortified by established tools and methodologies, will illuminate a path towards enhanced practices and a resilient culture, all while fostering stakeholder buy-in and adherence to industry standards.

I find helpful to keep in mind that standards can vary in accordance with factors such as complexity and criticality of systems. For example, while highly constrained standards are being adopted for space systems due to harsh environment and difficulties in accessing to space system once launched, more productive approach can be adopted for different systems to increase productivity. Another point I would like to highlight is that all sectors can get affected from each other. For example, some space standards got inspired from aeronautics and automotive sector. Hence, I find it helpful to select appropriate standards based on your domain but also keep an eye on other standards to be able to improve when possible.

ISO:15288 & INCOSE Handbook are more than enough and well equipped with all the information needed to define a PRODUCT's Life Cycle and Process around it. Let these be your baselines and build your SE Plans on it with the capacity to adapt and upgrade while making sure at the CORE the guidelines are well preserved.

Choosing the right standards is a nuanced process that takes into account the specific industry, project scope, and organizational objectives. In the aerospace sector, for instance, ISO/IEC/IEEE 15288 is often highly relevant. However, there are also merits in considering hybrid approaches, borrowing elements from standards in other industries to create a more agile framework, especially for teams that are smaller or newly established.

Forcing standards based approaches into organisations that want / expect to act in an agile way is often met with resistance, particularly with employees that have been in the industry for some time. The ability to take the core values and outcomes expressed by various standards is equal in importance to the ability to adapt the processes to the needs and wants of any given organisation.

Equally significant is the consideration of available resources and guidance. Opting for standards with readily accessible documentation, training materials, and support can expedite the adoption process and fortify our ability to adhere to chosen standards effectively. I would like to mention the ARP4754A and the most updated version ARP4754B. ARP4754A and ARP4754B are two guidelines developed by the Society of Automotive Engineers (SAE) that provide a framework for the development and certification of safety-critical aircraft systems. While they share a common foundation, ARP4754B represents an updated version that builds upon the principles and practices outlined in ARP4754A.

Once the right standards are chosen, it's about creating a concrete, actionable plan. This includes specifying which projects and processes will be affected, allocating resources for training and tools, and setting measurable milestones. For example, within BR&T Japan, we’re in the process of identifying and recruiting personnel to bolster our efforts in model-based engineering, aligning this recruitment with the standards we intend to implement.

Implementation will be as good as the development phase. Let your development phase define the implementation details with clarity and conciseness. Development is like laying out the path where Implementation is like walking the path. So if you lay down a 6-lane highway with a set of rules, all types of vehicles will run smoothly and reach their destination safely and on time. And if it is a street what you lay, chaos and confusion are what you will get, resulting in a messed up low-quality end product.

The implementation plan should be in accordance with the ARPs.The ARP4754B represents an updated and more comprehensive version of the guidelines compared to ARP4754A. It places a stronger emphasis on risk assessment, safety assessment, and alignment with certification authorities, while also providing more detailed guidance on system development processes and considering the entire system lifecycle. ARP4754B is intended to help aerospace organizations develop safer and more reliable aircraft systems.

Effective communication is paramount. Utilizing a range of channels—from internal memos to workshops—ensures the message gets across. Being a smaller, less visible team at Boeing Japan, we place high importance on stakeholder communication, actively seeking their input and sharing our progress and roadblocks. This is a two-way street that ensures active participation from all involved.

Clear Communication is of utmost importance and hence always a flat structure is preferred. Clear communication not only eases the flow of information but encourages collaboration, without which an efficient high-quality SE is not possible. So have a communication plan and flow chart covering every aspect highlighting the decision makers well enough.

If we are talking about changing from one method of operation to another, we are effectively talking about change management. Core to successful change is clear definition on what is changing, why it's changing, and when it's changing. You need to ensure that the stakeholders that are affected by the change have a voice on the 'change journey' because organisations don't change, people do.

Start by clearly articulating the reasons behind adopting the standards and the motivation for each stakeholder. Explain how these standards align with the organization's goals, improve quality, enhance safety, or address regulatory requirements. Highlight the potential benefits, such as increased efficiency, reduced risks, and improved competitiveness.

One thing I've found helpful is questioning goals of the standards or planned activities during all phases of the project. There are several examples that some activities or standards are applied as habit but actually they do not contribute considering what costs it induce. For example, traditional space standards are not very beneficial for commercial satellite constellation projects so new space approach is adopted for most of them.

Ongoing evaluation is critical for ensuring that the standards continue to add value and remain aligned with organizational goals. Key Performance Indicators (KPIs), such as efficiency gains or error reduction rates, can offer actionable insights. This, in turn, informs any necessary adjustments to the implementation strategy.

Regularly communicate the progress made in implementing the standards. Use various channels like newsletters, emails, or project status reports to keep stakeholders informed. Transparency about progress helps build trust and confidence. This is key in terms of monitoring and evaluation process.

I believe the target audience for this article needs to be clarified. If this is industries where SE is already established, the model makes sense albeit it is a bit conventional. If this is industries that are about or have only recently started applying SE (e.g. most automotive OEMs), I believe you need to start with the WHY standards before the as-is situation (I.e. to what business problem are SE standards the solution to?) just my thoughts.