Trainings available and Planned (W.I.P.)

 These classes are designed to be very short introductions to the concepts used in the workshops. They are designed to build on your existing processes, but optimize them by emphasizing the overlaps and linkages between the different elements of systems engineering. You don’t want a wonderful process (for example, perfect requirements or an exhaustive technical risk plan)…you want something “good enough” that you can use as your program learns and captures the most important outputs that feed the further steps.

For example, a topic may be a risk of design decision management and technical risk management (a decision may create or retire a technical risk; part of a technical risk retirement plan may involve making technical decisions and tradeoffs). So the classes on design decision management, technical risk management, and technical reviews emphasize how they work together to encourage a learning organization and a balance of speed and quality.

The overall system is divided into three overlapping areas: 1) Goal and problem formulation, 2) Design planning and technical risk/feasibility planning, and 3) Active Integration Planning.

Requirements are a necessary part of systems engineering; they capture the details of what needs to be done. But customers don’t typically buy based on specific requirements. They buy based on differentiated features and workflows or solutions to their problems. Requirements, scope, risk, and effort are treated together to ensure program work maximized business benefit.

• Focused on customer features and customer value, not specifically individual requirements
• Builds on INCOSE and Agile/User story best practices
• Can be extended to include dialogs on traceability and traditional requirements management

Technical risks can be retired or created by design decisions; both are ways of capturing and communicating what you have learned during the design process. Design reviews can be backward looking (what good work we’ve done so far) or forward looking (has the design space been properly explored? What remaining risks need to be managed?).

• How to efficiently identify and manage technical risks
• How efficiently identify and manage key design decisions and trade studies (framing and prioritizing decisions; when and how to delegate decisions)
• How technical risks and design decisions relate to each other
• How to use technical design reviews efficiently to manage risks

Integration and test can be opportunistic (what has been developed and how do we test the requirements) or strategic (what customer and market value have we fully finished so far? What functional and quality risks have we retired so the remaining work is built on a solid foundation?)

• How to plan out integrations and testing to reduce technical and business risks and find defects early (reduce schedule risk early)
• Leverages best practices of Waterfall, Agile, and Iterative Development (Spiral process model)…can be tailored to your specific guidelines
• Extension: best practices in defect management

Customers want products that solve their workflow issues intuitively and don’t break. You want products that are easy to manufacture and service. All the “-abilities” have to be included in the design process.

• We can create modules for how to incorporate Usability, Reliability, Six Sigma, Serviceability into your design
• Best practices in Failure Modes and Effects Analysis: 
• how to minimize effort and maximize benefits through prework (functional block diagrams and Parameter Diagrams) and reuse
• the relationship between safety engineering and FMEAs
• the benefits of each type of FMEA
• Full courses and workshops in Six Sigma and Reliability could be created

Focusing on the functions (“logical design”) as well as the structural (“physical design”) makes designs higher quality and more reusable. But design teams are usually defined by the subsystems (the structural design). Good system design starts with logical design but balances both.

• The difference between design and requirements flowdown
• How to enable functional design and MBSE

A key failure mode in engineering programs is assuming you know more than you really do (over-confidence). Several key symptoms of superficial thinking are stopping analysis at fixing symptoms rather than root causes, or assuming that you know more about the customer or environment than you really do. There are techniques to help teams avoid these pitfalls. However, these are fairly advanced topics; you can make significant process with just simple templates that expose the team’s assumptions and priorities.

• Root cause analysis
• Systems thinking
• Critical thinking