Systems Engineering Workshops

The core of my approach are systems workshops, which take design teams and work on their actual new product development challenges (not an example training problem). 

• The workshops involve the entire program design leadership (not just systems engineers)
• The workshops work on your technical challenges, using your design. 
• They produce real program deliverables.

They are proceeded by 4-8 hours of “sensing”, some tailoring of the agenda and materials, a small amount of training on the concepts, terminology, and templates; and followed up by 4-8 hours of mentoring

This workshop is done just after the new product development program is kicked off. It assumes that the team has access to the market needs and competitive analysis. It takes the marketing and business inputs and turns it into crisp engineering outputs for: 

• Program Scope definition
• Technical Risk Planning
• Design Decision Management
• Technical Review Calendar (especially the “-ilities”)
• Design team operating mechanisms

 This workshop is done just before the program commits to the delivery date (the program manager and execution lead will likely need 2-4 weeks to come up with project plan details before the business review). It assumes that the team has retired the most challenging technical risks (the red and orange risks) and closed the technical decisions that gate the implementation teams. The workshop identifies the integration strategy: What is the definition of “done” for the implementation teams, and how does the team develop functionality that adds customer and business value (turning subsystem definition of done” into risk retired business value). Since you are completing business and customer value with each integration step, if the program is slipping the business can decide whether to slip the program or simply jettison an integration step and ship a “minimally viable product” on time (or early).

• Integration Step Strategy
• Verification Strategy (especially challenging testing)

 A key assumption of the two primary systems workshops is that quality produces efficiency and speed…if you are building new functionality on a solid foundation you aren’t spending time working around crashes and bugs or debugging what turns out to be known issues. Thus, challenging verification is a key component of the Active Integration Workshop. In terms of “designing in quality” a key tool is Failure Modes and Effects Analysis (FMEA). 

While many FMEAs are done after the design is mostly complete, you can make them more efficient and reusable by emphasizing the functional requirements and failure modes (not the specific physical failure modes). The proper prework can reduce total FMEA development time by half (and for some modules you may be able to eliminate the FMEA and just use the Parameter Diagrams).

• Goals of an efficient FMEA
• Proper prework (Functional Block Diagrams and Parameter Diagrams)
• Planning out the development and review of FMEAs (how deep to go, when to stop, when to split large FMEAs into pieces)

This is an optional workshop that can precede or follow the active integration workshop