1. Term Project D1 Retrospective L3: 180502 Class
High Concept: drag-and-drop plug-and-play modular options to deal with an ever surprising situational environment.
Mental Preparation (Operational Story) BEGIN WITH THE END IN MIND: you live in the operational environment, you see a variety of surprises, you can configure an appropriate response for each.
You are the architect/designer, and I am the person who will implement your system based on what you send me as D1/D2.
Thus, CURVE, Op Story, RSA, RRS, and AAP should instruct me in what you want implemented (Op Story and AAP), how you want it implemented (AAP and RRS), and why (CURVE, Op Story and RSA).
What you send me is your plan that you want me to understand and implement as you intend – so make it a clear complete communication.
D1 is a preliminary plan – and my comments on D1 are my confusions, questions, suggestions, and attempts to decipher what you really meant that wasn’t communicated effectively.
“Good” comments on RSA/RRS/AAP slide areas mean “appropriate” for the tool element intent, does not mean sufficient for your system description.
Effective communication of your plan is the objective of D2.

2. Justifying Your Solution Proposition
If you can’t articulate the problem, any solution looks okay.
Tools that characterize the problem Space:
CURVE (high level problem space characterization)
Reality Factors (influences RSA issue identification)
Response Situation Analysis (addresses the CURVE)
Characterizing the problem space provides the reasons, justification, and traceability for what you propose and design as a solution.
It also reveals the extent of what you are considering and not considering.
Even if your solution can’t address the full problem space, it is useful to know how much of the problem space can be addressed, and what must be prioritized for subsequent solution-space evolution.
Note that D2 effectiveness hinges on the closure matrix – which relates your operational-time activities to your operational-time response issues.
If you confused design-time objectives as operational-time response issues you will have to fix this.

3. Understand the Dynamics of the Environment

4. Getting Your Head Together
What’s the problem you want to solve? Do you really have one? Explain why it is a problem worth solving. Is it caused principally by a CURVE environment? If not, find another problem to solve. If so, of what type? What are the costly surprises? Where isn’t CURVE dealt with in the current systems approach? Could you redesign/replace the current system with a modular, drag-and-drop, plug-and-pay approach to deal with the CURVE environment better? Is an agile adaptable-system approach necessary, or beneficial? In what way? Step away from your favored solution, and understand the problem to be solved.

5. Pro forma only – not comprehensive
CURVE High-Level Response-Needs of Concern Example: System Engineering Process
Caprice: unknowable situations
Obsolescence of solution approach before completion
Requirements additions and changes
Uncertainty: randomness with unknowable probabilities
Feasibility of solution design
Continuous political and funding support
Risk: randomness with knowable probabilities
Unacceptable cost increases
Failure to meet necessary schedule
Variation: knowable variables and variance range
Critical test facility availability
Multiple COTS-source performance differences
Evolution: gradual (relatively) successive developments
Continuous incremental change in targeted operating environment
Alternative technology improvement curves (Moore’s law effect)
Pro forma only – not comprehensive

6. Restrooms Deferred Commitment
TOMORROW – One of the greatest labor saving devices of today.
Signs to be hung in various places as sign-hanger walks around
Restrooms
Orientation deferred until time and location of placement.
No advanced planning required

7. Case Example: Electric Distribution Substation Design Substation Designs in 6 Hours – (normally 6 months)
Why was this approach needed?
PNM’s Second
Standard Substation
Design
DASL provides common framework and common equipment modules
Gene Wolf , P.E. T& D World Conference, 2004
Details:

8. CURVE: PNM Electric Substation Design
Accurate and rapid designs with low-experience engineers, under:
Capricious time to gain construction permits
Uncertain availability of competent design engineers
Uncertain cost and schedule of transformer delivery
Risk of canceled substation need
Variable engineer substation-design experience
Evolving power-capacity requirements for substation
(Note: above only shows reactive CURVE elements, need proactive also)
Reputation Goals:
Easy, rapid, predictable design
Accurate costing
Predictable installation completion
Low spares-inventory costs
Construction exactly as shown in city/county permit approval
Case: Public Service New Mexico (PNM)

9. RF: PNM Electric Substation Design
Reality Factors
Human Behavior – Human error, whimsy, expediency, arrogance...
Engineers aren’t schooled in power engineering.
Engineers want to make custom designs.
Arrogant less experienced engineers not seeking the advice of more experience engineers.
Organizational Behavior – Survival rules rule, nobody's in control...
Permitting agencies don’t believe the actual design will match the design submitted for approval.
Company wants quicker designs.
Company wants reduced spares inventory (cost).
Technology Pace – Accelerating vulnerability-introductions, sparse testing, new agile SE methods...
Transformer technology-advances requires knowledge-current engineers.
New emphasis on smart and internet technologies
System Complexity – Incomprehensible, highly networked, unintended consequences, emergence...
High knowledge/experience required.
Level of complexity increasing with smart grid technologies.
Globalization – Partners/customers/employees with different ethics, values, infrastructures, culture...
Differing cultural beliefs and values among customers.
Increasing foreign cultural background among employes.
Partially Agile Enterprise (Faddish Practices) – Outsourcing, web services, SOA, process and progress transparency, COTS policies and affects...
Outsourcing substation design occasionally.
Agile Adversaries/Competitors/Customers – Distributed, collaborative, impatient, innovative...
Grid attacks on the increase.
Customer needs change constantly.

10. RSA: PNM Electric Substation Design
Response Domain
Response Situation Analysis
Proactive
Reactive
Creation (and Elimination)
Substation design (tp)
Bill of materials (tp)
Construction permit approval (tp)
Improvement
Time to permit approval (ts)
Time to construction completion (s)
Cost of spares inventory (ts)
Migration
High voltage H configurations (cp)
Transmission right-of-way fly-through configurations (cp)
Modification (of Capability)
Upgraded transformer incorporation (tc)
Engineer substation-experience maturity (t)
Correction
Wrong capacity requirement (tc)
Inadequate engineer (tp)
Transformer delivery too far out (tc)
Variation
Expertise and skill levels among engineers (ps)
Time allowed to complete the project (ps)
Expansion (of Capacity)
Power capacity range to 9x over base capacity (tp)
Reconfiguration
Substation power capacity (tcs)
Inventory spare transformers used in new construction (t)

11. RRS: PNM Electric Substation Design
Reconfigurable
Scalable
Reusable
Encapsulated Resources Resources are encapsulated independent units loosely coupled through the passive infrastructure.
engineers, transformers, switchgear, transmission termination structures, low-voltage feeder circuits, station steel
Evolving Infrastructure Standards Resource interface and interaction standards and rules that evolve slowly.
DASL design tool ConOps
DASL module interconnects, Construction policies/regs
Facilitated Interfacing (Pluggable) Resources & infrastructure have features facilitating easy resource insertion/removal.
Drag and Drop DASL operation
DASL flags improper module-mating
Redundancy and Diversity Duplicate resources provide fail-soft & capacity options; diversity provides functional options.
Multiple engineers capable of designing
Experience of engineers can vary
Facilitated Reuse Resources are reusable and/or replicable; with supporting facilitation for finding and employing appropriate modules.
Drop-down menus for selecting modules
Elastic Capacity Resource populations & functional capacity may be increased and decreased widely within the existing infrastructure.
Peak design-time activity can employ many easily-qualified design-engineers
Peer-Peer Interaction Resources communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored.
Designers communicate directly with permitting agency to secure approvals
Designers communicate directly with inventory management to ensure availability
Distributed Control & Information Decisions made at point of maximum knowledge; information accessible globally but kept locally.
Transformer designers work independent of substation designers, maintaining interconnect standards
Deferred Commitment Resource relationships are transient when possible; decisions & fixed bindings are postponed until necessary.
Quick design time enables design commitment at last responsible moment
Self-Organization Resource relationships are self-determined; and component interaction is self-adjusting or negotiated.
Trust relationship between designers and permitting agency is self-organized evolution

12. AAP: PNM Electric Substation Design
Resources
T T H H H
Integrity
Management
engineers
transformers
switchgear
termination structures
low-voltage feeders
station steel
Situational awareness
Resource mix evolution
Resource readiness
Activity assembly
Infrastructure evolution
DASL program mgr
min/max purchaser
project & chief engineer
design engineer
chief engineer
Active
Infrastructure TT HH
Passive
T Station
H Station
Fly-Thru Station
Sockets
Signals
Safety
Security
Service
DASL module interconnects
Substation requirements
Construction policies/regs
No development customization
DASL design tool ConOps
Rules/Standards
H-pad standards
Fly-pad standards

13. BACKUP

14. The CURVE Environment Drives the Response Need
Agile systems are defined in counterpoint to their operating environments.
Words used to describe the general nature of the target environment often include and combine dynamic, unpredictable, uncertain, risky, variable, and changing, with little attention to clear distinction among them.
To design and develop a system that can deal effectively with changing environments it is useful to articulate the nature of changes that should be considered.
Agile systems have effective situational response options, within mission, under:
Caprice: randomness among unknowable possibilities.
Uncertainty: randomness among known possibilities with unknowable probabilities.
Risk: randomness among known possibilities with knowable probabilities.
Variation: randomness among knowable variables and knowable variance ranges.
Evolution: gradual (relatively) successive developments.
The difference between risk and variation in this framework is that risk is viewed as the possible occurrence of a discrete event (a strike keeps all employees away), while variation is viewed as the intensity of a possible event (absenteeism varies with the season).

15. Pro forma only – not comprehensive
CURVE High-Level Response-Needs of Concern Example: System Engineering Process
Caprice: unknowable situations
Obsolescence of solution approach before completion
Requirements additions and changes
Uncertainty: randomness with unknowable probabilities
Feasibility of solution design
Continuous political and funding support
Risk: randomness with knowable probabilities
Unacceptable cost increases
Failure to meet necessary schedule
Variation: knowable variables and variance range
Critical test facility availability
Multiple COTS-source performance differences
Evolution: gradual (relatively) successive developments
Continuous incremental change in targeted operating environment
Alternative technology improvement curves (Moore’s law effect)
Pro forma only – not comprehensive

16. Proactive Response: Agile Systems-Engineering
Creation:
project management strategy (t);
project team (t, c);
system requirements (t, p);
V&V/test plans (t);
team collective understanding and learning (t, p);
product development [software code, hardware build documentation] (t, c, p).
system architecture (t, s);
system design (t, c, p);
development activity plans (t);
Improvement
activity effort estimating (p);
activity completion to plan (t, c, p);
reducing uncertainty and risk (t, p, s).
Migration
compelling new technology availability (t, c, s);
project scope change (s);
lean process principles (p).
Capability
added team member unfamiliar/uncomfortable with management strategy (t);
new environmental dynamics (t, c, p, s).
Pro forma only – not comprehensive

17. Reactive Response: Agile Systems-Engineering
Correction
wrong requirement (t);
inadequate developer (t);
failed V&V/test (t, c);
non-compliant supplier (t, c).
Variation
expertise and skill levels among team members (p);
grace period on schedule (t, c);
deliverable performance range (p);
availability, interaction, and expertise of customer involvement (s).
Capacity
2x project scope change (t, c, p, s);
team-size changes of x-y engineers distributed across n-m locations (t, s).
Reconfiguration
unanticipated expertise requirement (t);
development activity-sequence priority change (t).
Pro forma only – not comprehensive

18. Pro forma only – not comprehensive
Example: Scrum Agile Architecture Pattern (AAP) Details in
Modules/Components
Integrity
Management
Developers/ Testers
Product Owners
Scrum Masters
Product Backlog
Stakeholders
Resource mix evolution
PO with Team Collaboration
Resource readiness
Scrum Master, Developers/Testers
Situational awareness
Everybody
Activity assembly
Self Organizing
Infrastructure evolution
Product Owner (PO)
Active
Infrastructure
Passive
Scrum Meeting
Sprint n
Sprint Retrospective
Sockets
Signals
Security
Safety
Service
Peer-Peer Interaction
Daily Scrum Info
Trustworthy Transparency
Collaborative Review
Process Rules & ConOps
Rules/Standards
Retrospective Change
Pro forma only – not comprehensive