Your team is split on risk levels for a system design. How will you navigate conflicting perspectives?

The systems design (note plural) will be for a viable solution system, operating in its future environment for its lifetime. It will be necessary to explore that future environment for threats, risks, options, alternatives, etc., and to take account of them in the Systems Design. Which may, in consequence, require reversionary modes, backups, etc, and—since the operational environment will undoubtedly change dynamically over time—will require flexibility in design to accommodate as yet unforeseen challenges. So, the Systems Design will include, but not be limited to, Mission Management, Viability Management and Resource Management capabilities.

System by definition is composed of number of subsystems and each subsystem includes number of components. Failure mode and effect analysis for components subsystems and eventually system is good start for assessing risks to meet the desired reliability. understanding the risks is the first step, Once the risk is understood, there are acceptable risks and not acceptable ones. single point failures typically are not acceptable however in certain cases one can minimize the risk by adding redundant feature. Risk mitigation process is a logical act of engineering. While consensus is very important if the risk poses reduced reliability, risk must be mitigated logically and through understood and qualified processes.

Begin by thoroughly understanding each perspective on the risks involved. In banking software development, this could involve evaluating risks related to compliance, security, performance, and user experience. Engage with team members to gather detailed insights into their concerns and the potential impact on the system’s functionality and regulatory adherence.

When designing a system there are a lot of things that should be taken into consideration, the risk could be varying depending on the approach we follow to build the system , for instance, if we failed to properly navigate the path of the data and made use of inappropriate channels and routines , that might lead to risk of memory leak.The understanding about the type of risks should be prior noted to avoid them . This could benefit the system by avoiding the issues such as high latency , more downtime, increasing memory and higher processing time.

I will push for data-driven and statistically backed decisions to ensure we tackle risks objectively, focusing on what matters most.

The most important element of safety risk assessment is to employ leaders at all levels that have real experience and are open to addressing risks, regardless of consequences not related to safety. Data tells the truth and cannot be ignored or put in second place to business desires…we have all seen the management pressures to “launch”.

Having worked in cross-functional teams and led major system migrations, I’ve learned the importance of creating a space for open dialogue. I ensure that every team member, whether they’re focused on front-end issues or backend database concerns, gets a chance to voice their opinion. This collaborative approach helps in uncovering potential blind spots and ensures a well-rounded understanding of the problem.

Round-Robin Approach: Use round-robin discussion format during meetings to ensure that each team member has an equal chance to voice their concerns, especially in larger teams where some voices may otherwise be drowned out. Encourage Active Listening: Encourage team members to listen carefully to each other's points without interrupting, which can help uncover valuable insights and perspectives. Anonymous Feedback: If the team is hesitant to share openly, consider anonymous feedback tool where members can express concerns without fear of backlash. Reframe Disagreements: When disagreements arise, focus on the problem, not the person. Frame disagreements as opportunities to refine the understanding of risks rather than as personal conflicts.

The clarity about system design varies with the year of experiences someone has in tech . The more the experience, the better the ability to figure out the loop holes in the system. The seniority should always focus on figuring out the potential risks and the rest could think for providing solutions to the risks that could occur . Every opinion should be considered because the perspective flows differently to everyone. A detailed architecture should be diagrammed highlighting the risks and solutions at every state change.

Risk Management can be effectively done via categorizing the risk identified. After doing Functional Hazard Analysis (FHA). One can identify the functions of your system and corresponding hazard associated with it. This can be categorized by indexing them based in the effect it creates and the probability of occurrence. In aviation, the effects are classified into: catastrophic (A), hazardous (B), major (C), minor (D), no safety effect (E). The probability of occurrence is classified based on frequent (5), probable (4), remote (3), extremely remote(2), extremely improbable (1). Based on this a matrix will be created. Index value of 5A, 5B, 5C, 4A, 4B, 3A are considered as intolerable and given the most priority.

The prioritisation should always be done depending on the risk . The major the risk , the higher the priority . A detailed view of every risk and their potential damages should be highlighted in order to understand the intensity of risk. Also given the metrics , the damage should be quantified in terms of requests that were not successful and the over all system running costs. The radar should always focus on the most impacted and slowly expand their horizons to the least impacted areas and address the same .

In my work, I often deal with systems where downtime is not an option, such as when managing messaging utilities for millions of users. To prioritize risks, I rely on a combination of historical data and real-time analytics. For instance, a 0.1% failure rate in message delivery is acceptable in some cases, but similar failure rates in a database migration might lead to critical issues. I focus on risks with the highest potential impact on user experience and operational efficiency.

It's necessary to take into account all team member and stakeholder perspectives regarding risk, to them assess them by priority, impact and probability, then sift through the information to derive an analysis which guides the system design to the best alternatives. Some customers are very risk adverse to the point of driving the cost and complexity, their needs need to be taken into consideration but also alerted to the impacts their concerns have and determination of the criticality of the factors involved. Add a dash of reality check as well. Risk analysis can spiral quickly to trying to encompass every possible and impossible potential issue, keeping the discussion grounded is thus as important as staying creative and diligent.

Prioritizing identified concerns and identifying the severity/likelihood of each risk is critical to the success of system design. It is ok and even encouraged for a team to be split, especially for complex systems of systems, as differing viewpoints are fundamental in identifying and mitigating each risk. For this to happen, the end goal must be crystal clear, and each team member must be comfortable expressing their opinion while being open-minded to opposing inputs.

1. Clarify Decision-Making Criteria 2. Use Structured Decision-Making Tools 3. Modified Delphi Method 4. Facilitate Constructive Dialogue 5. Compromise and Balance 6. Document the Consensus 7. Revisit the Consensus

The Delphi method is a more structured approach, where experts provide anonymous feedback on risks in multiple rounds. After each round, responses are summarised and shared, allowing experts to adjust their views. This process continues until a consensus or common understanding is reached. It reduces bias and ensures informed decisions based on collective input. The modified Delphi typically limits the number of rounds to reduce time. It may also incorporate face-to-face discussions or online forums after the initial round(s) to speed up consensus-building. It’s especially useful when teams need to quickly reach a consensus but still want to benefit from the collective expertise.

Consensus is crucial, but so is ensuring the right balance between innovation and security. I’ve been part of teams where we had to make tough decisions. I approach consensus-building by suggesting pilot solutions or simulations, which allow the team to see the potential outcomes without committing fully. This helps the team feel more comfortable with the direction we’re taking.

Consensus is not the best solution here. If you have prioritized concerns then other succeeding decisions should be based on that

Aim to build consensus by finding common ground. This may involve negotiating trade-offs or developing compromise solutions that address the most critical concerns without fully disregarding others. In banking software, this might mean aligning on a solution that meets regulatory standards while also addressing performance and security needs.

1. Design Targeted Solutions 2. Assign Ownership 3. Set Measurable Objectives 4. Integrate Solutions into the Project Plan 5. Monitor Progress and Review 6. Team Commitment 7. Contingency Plans

Since I work in the aviation industry, we follow a detailed risk analysis at every stage and throughout the aircraft's lifecycle, adhering to rigorous standards. Performing verification and validation after each step would ensure that the every process is implemented properly. System design starts with requirement creation. Performing safety analysis like FHA, PSSA, CCA, FTA, etc. would validate if the requirement created at each stage is appropriate before moving on to system design. After the design, verification of the design is carried by another set of system analysis like FMEA, SSA, ASA, etc. Performing all these safety analysis would ensure that a proper implementation of system design is carried.

Once the consensus is reached, implementation needs to be smooth and well-documented. In my experience with migration projects clarity is key. I ensure that all components are modular and scalable, and that team members are aligned on their responsibilities. This minimizes the risk of miscommunication and ensures faster resolution of any issues during deployment.

Sort through the proposals and after a consensus decide on the best solution, so all understand and move forward. Once the decision is made stick my it!

Once consensus is achieved, move forward with implementing the agreed-upon solutions. Develop a detailed action plan that includes timelines, responsibilities, and milestones. For a banking system, ensure that all regulatory compliance checks are incorporated into the implementation process and that rigorous testing is conducted.

Since I work in the aviation industry, we follow a detailed risk analysis at every stage and throughout the aircraft's lifecycle, adhering to rigorous standards. Performing verification and validation after each step would ensure that the risk analysis is carried at every stage. This is similar to that of a Swiss cheese method. System design starts with requirement creation. Performing safety analysis like FHA, PSSA, CCA, FTA, etc. would validate if the requirement created at each stage is appropriate before moving on to system design. After the design, verification of the design is carried by another set of system analysis like FMEA, SSA, ASA, etc.

When perceptions differ it is helpful to see if the “risks” are “worries”. For example: if the product fails qualification tests, then there are re-design, re-test, and cost/schedule impacts. This really is not a risk… Instead it’s a worry that somewhere in design, analysis, planning, procurement, etc. something will go wrong and the product fails testing. There are likely “real risks” in this endeavor, the challenge is finding those that: a) can be identified, b) are actionable to reduce occurrence or magnitude of impact, and c) can be quantified to assess if mitigations are effectual. Digging deeply into the real vs perceived risk will often reveal genuine risks that require more than due diligence and good practice to overcome.

- Monitoring progress helps identify potential risks early, allowing the team to adjust based on real-time data, which can ease differing concerns. - Regular progress reviews offer evidence-based insights, helping resolve conflicting perspectives with objective information rather than assumptions. - Monitoring encourages open dialogue, ensuring everyone stays engaged and on the same page, reducing friction over risk perceptions.

After implementation, continuously monitor the system to ensure that the solutions are effectively mitigating the identified risks. Set up regular review meetings to track progress and address any emerging issues. Use metrics and feedback from system performance and compliance audits to make necessary adjustments.