Building Leadership, Technological Knowledge and Enterprise Integration in Growth Stage Technology Businesses

1. SYSTEMS ENGINEERING
Building Leadership, Technological Knowledge and Enterprise
Integration in Growth Stage Technology Businesses
MARCH 27, 2019
DAVE LITWILLER

2. DEFINITIONS
Systems Engineering
• The co-ordination and direction of several engineering
disciplines in a single, complex effort
• The design of the whole, to realize a harmonious and
effective ensemble, as distinct from the design of the parts
• Development in which a number of major complex
components must be simultaneously created to act together
to perform some greatly improved operation, requiring
considerable development of various techniques beyond the
present state-of-the-art
• The art and the science of coordinating multi-faceted
development in the way that allows the greatest level of
decentralized autonomy and creativity, while adhering to
centralized guidelines and core values

3. DEFINITIONS
Systems Engineering
Research & Development
Source: Synergy, H.W. Bode, Bell Labs, 1971

4. DRIVING FACTORS
• Heterogeneity; multi-disciplinary
• Tight coupling
• One or several sub-systems operating at or beyond the
state-of-the-art
• From applied research to advanced production
• The need for high speed development, including
concurrent development
• At issue: Consistent success in systems engineering
requires organizational engineering as much as multi-
disciplinary technical engineering

5. LEVERAGE OF SYSTEMS
ENGINEERING
Source: Breakthroughs and the Long Tail of Innovation, MIT Sloan Management Review,
Fall 2007, Lee Fleming
• The wins get bigger moving from single- to multi-discipline
systems engineering, but so do the risks
Today’s Seminar:
How to get up
here:
Breakthrough,
multidisciplinary
performance

6. LEVERAGE OF SYSTEMS
ENGINEERING
• Multi-disciplinary innovations are much harder for
competitors to imitate than mono-disciplines
• True for technologies
• True for business models
• Competitors have to try to recreate or better the whole,
rather than just a part
• Organizational capabilities and a culture for business
model adaptability and innovation are highly related to
systems engineering and technological innovation
• Getting systems engineering right provides a wider gamut
of competitive flexibility in commercial dimensions, not just
technical, to respond as the strategic environment evolves

7. TYPICAL PLURALITY OF
SYSTEMS ENGINEERING
ROLES
• Research studies and experimental investigations
• Advanced planning and evaluation of new architectures
• Creation and maintenance of the development plan
• Preparation and evolution of the system specification
• Technical direction for component and sub-system
development groups and contractors
• Monitoring of program progress
• Direction of the test program, and harmonization of
system, integration, and component/unit test
• Investigations of alternative approaches

8. DOING SYSTEMS
ENGINEERING
• Builds upon recognition that systems engineering is a
socio-technical challenge, not just technical
• Systems engineering isn’t just about having good ideas
• It requires time, repetition and face to face communication
in negotiating and persuasion, as much as the technical
work itself
• Isomorphic: Technical performance and quality mirrors the
speed and fidelity of information and communication flow
across a R, D & E organization
• The design of a product mirrors the design of the
organization that created it

9. COMMON FORMS OF
TECHNICAL
PROGRESSION
Knowledge build-up in systems engineering operating
beyond the known state-of-the-art:
• Qualitative
• Figuring out what are the big independent variables that
affect dependent outcomes
• Quantitative
• Developing quantitative, repeatable relationships and
variance understandings, as well as larger mathematical
and conceptual models
• Architecture and interfaces
• Zen: Mastering and managing the relationships between
the relationships within the system

10. TEST
• The cultural inheritance of much of an organization’s
knowledge about systems engineering
• Test really shows how an organization thinks about
engineering systems, and the fitness landscape the
system needs to operate in
• Mission, values, goals and technological approach to
realizing value for users are directly reflected in test
training, tools, techniques and personnel
• The point of experiment is maximum information release,
partly to assess validity and partly to point the way to
better ideas

11. SYSTEMS ENGINEERING
FULCRA
Three particularly potent, though often underrepresented,
roles in systems engineering:
1. Configuration and change management
2. Work package management
3. Allocation of capacity-limited resources and equipment

12. CONFIGURATION
MANAGEMENT
• Mainly about change control
• Making sure that necessary changes in sub-system design
are immediately reflected throughout the total system
configuration
• Uses power of purse, schedule and performance to
approve, reject or modify proposed changes
• Budgetary authority and accountability has to be invested
in those responsible for configuration management
• Otherwise, fluidity in teams and tasks creates weakness in
decision authority and ownership

13. CONFIGURATION
MANAGEMENT
• Creates centralized nexus of change approval and
communication
• Pushes out decision criteria for how changes are to be
evaluated and approved to partially decentralize developing
and proposing changes that incorporate systems thinking
before a proposer submits a candidate change
• Enables timely and complete change notifications once
changes are approved and released
• Develops multi-disciplinary, cross-functional thinking
• Trade-offs among: Performance, Reliability, CapEx, OpEx,
Margins, Cash Flow, Inventory, Time, $, Development Speed,
Production Efficiency, Maintainability, Extensibility, Risk, and
Contract Terms
• Trade-offs among heterogeneous technologies and operating
disciplines

14. CONFIGURATION
MANAGEMENT
• Configuration control and change control linkages:
• Engineering communication
• Technological investigations
• Design (hardware and software)
• Supply chain
• Test
• Production
• Operating procedures
• Maintenance
• Training
• Issue tracking
• Management authority
• Costs (program and unit)
• Schedule, and,
• Contractual matters
• The typical challenge:
• Maintaining similar high velocity for these
different workstreams, and integrating
them all to jointly optimize
• A good practice:
• To meet with finance and legal right after
every meeting where there is technical
redirection, to calibrate cost and
contractual matters

15. CONFIGURATION
MANAGEMENT
• Requires:
• Technical requirements linkages to product specifications
for each change
• Part and module nomenclature and numbering
• Control documents
• Change processing and approval
• Integrated records management
• Usually, there is a multi-functional change control board to
oversee configuration management
• Especially if the rate of change and complexity is beyond
what can be sensibly handled with design freeze followed
by ECNs, often the case in concurrent engineering

16. CONFIGURATION
MANAGEMENT
• Configuration management helps further detail overall
requirements for the product and program as it
progresses, some of which may have been overlooked at
the outset, to help guide everyone’s work better as the
project advances
• Reaches
• Upstream into supply chain
• Downstream into distribution and deployment environment
• Laterally into complementary products and services
• From present to future, spanning time
Tip: Periodically audit if approved change directions are being received in a
timely manner throughout the organization and the development effort

17. WORK PACKAGE
MANAGEMENT
• Cascades systems engineering practices both laterally and vertically
• Creates and maintains a detailed description of assigned tasks
• Articulates:
• Who is responsible
• Schedule
• Cost
• Performance
• Quality and reliability
• Documentation
• Interface compatibility requirements
• Test methods, as well as,
• Protocols for change negotiation and notification of approved
changes

18. SCARCE RESOURCE
MANAGEMENT
• Exercise control over
• Allocation of equipment and resources
• Authority to move scarce equipment or resources to the
area most in need at a given point in time
What you do with your scarcest, most critical resources says as
much about your engineering approach and technical culture as
almost anything else you say or do

19. DAILY ITEMS OF
IMPORTANCE (IoI)
COMMUNICATION
• Daily, written, push communication from all collaborators
to leader
• Covers: Main events of past 24 hours, including summary
of significant verbal communications internally and
externally
• Leader prepares similar summary with leader’s notes and
comments, shared back to team, and the leader’s peers

20. DAILY ITEMS OF
IMPORTANCE (IoI)
COMMUNICATION
• Benefits of IoI system in a high velocity environment
• People are more careful about their facts when committing
in writing in a single unambiguous system of record
• Misunderstandings are reduced
• People get fast at this once they get over initial learning
• Fosters fast, tight integration up, down and across the org
• Keeps everyone au courant, a leading challenge in large
team, high speed technological and engineering projects
• Discourages people pointing to the existence of
collaboration software as (suspect) indirect evidence of
timely, thorough communication, when levels of
engagement, currency and utility may vary widely

21. WEEKLY TROUBLE
MEETING
• Review of entire development program with a view to
saving time, especially interfaces and interdependencies
• Identification of where new issues, risks and complexities
have emerged
• Assigns ownership for resolution of all issues to
individuals
• Articulates major decisions and investigations to be made
in the coming week, and the individual responsible to do
so for each one

22. WEEKLY TROUBLE
MEETING
• Ensures rapid collection and dissemination of critical
information
• A distinct, cadenced, and frequent trouble forum prevents
other daily or weekly status updates from becoming oriented
mainly toward good news or superficiality
• Discussion of the problem areas and resolution pathways
stays ever present, direct and unavoidable
• Ensures prompt, accurate reporting of difficulties with
prescribed reporting format to aid in detection of change and
anomalies
• Keeps people focused on proposing solutions to emergent
problems, not just surfacing the problem
• Shows where the development program really is, rather than
drifting toward success theatre of where the program ought
to be

23. DESIGN REVIEW
MEETINGS
~Monthly review of progress and challenges relative to overall goals, or,
milestone driven at time of significant increases in the cost of change
• In systems engineering, design review meetings help drive
integration of thinking across technologies and across functions of
the enterprise
• They improve discipline in fact checking by those reporting
• They keep leadership in touch with the nuts and bolts of what is
happening in major development programs
• The focus in design review meetings should be on challenging and
improving the system under development, with a clear goal for each
milestone linked to the overall program’s objectives
• A centrally prescribed reporting format needs to be used to aid
comparisons over time and between subsystems, with a requirement
of reporting identical data at system design reviews as for internal
subsystem efforts (one set of technical books)

24. DESIGN REVIEW
MEETINGS
• Document
• Minutes of each meeting
• Changes in specifications, schedules and technical directives
• Changes in recognized key interdependencies between disciplines
• Alterations of work package assignments and any corresponding contract
changes
• Shifts in critical resource allocations
• All action items, responsibly party for each, and completion date
• Leaders of design reviews should evaluate cross-functional design
solutions and the thinking behind them, by asking a lot of questions to
coach the right kinds of team member thinking in real time, based on:
• Collaboration,
• Experimentation,
• Rigor,
• Detail, and ultimately,
• Ownership

25. DESIGN REVIEW
MEETINGS
• The discipline trick in design reviews is to keep the dialog candid,
based on learning and achieving high standards, rather than having
the meetings and collaterals slide into being forums where people
don’t want to criticize or offend, and presenters just want to get
offstage as quickly as possible
• Leadership needs to model the behaviours that others are to exhibit,
in energy, intensity and priorities
• This is one of the best places for management to demonstrate how
product excellence is to come ahead of ego, in part through
preparation, collaboration and attention to detail in the meetings
• The main issue is to keep accountability high, but not devolving into
a fear-driven environment in which people clam up or obfuscate
• The best way for leaders to operate is to ask good questions that
stimulate the right kinds of team thinking;
• The worst is giving the team the answer since it compromises people
development and shifts the onus of future responsibility from many to
few/one

26. CONCURRENT
ENGINEERING
• Concurrent engineering is where systems engineering is
arguably at its zenith, vs. more serial or loosely coupled
development
• Strong overlap of research, development, production and
deployment, vs.
• A more serialized, waterfall-like approach, or,
• Evolutionary, Agile, piece-wise approach or where
changes in one subsystem have little impact on other
system characteristics

27. CONCURRENT
ENGINEERING
• Requires a strong centralized systems engineering approach
to manage change in a large development
• One essential skill: The engineering management methods to
be able to keep a highly interrelated body of sub-systems all
co-evolving without going out of control, and introducing
significant cost or schedule overruns (or performance failures)
• A second key capacity: Sufficient but not excessive design
margin. The changes in the performance of any one
component or subsystem vs. earlier expectations can be
accommodated through manageable changes elsewhere in
the system, without having to entirely throw out what has
already been developed and start over
• The ability to do concurrent engineering well almost always
requires as much innovation and ongoing adaptability in
modeling, simulation, test, test bed engineering and
deployment infrastructure as it does in the core system
design

28. CONCURRENT
ENGINEERING
• Concurrent engineering of components, sub-systems and
systems is most important when one or several tightly
coupled technologies need to operate beyond the prior state-
of-the-art to achieve system performance objectives
• Interactions are nearly impossible to fully predict
• Performance expectations for enabling system elements may
come up short
• Functionality and reliability typically needs to be dynamically
reallocated throughout the system as technological and
commercial knowledge gets built, to maintain overall system
objectives
• The ongoing discipline is to maximize the earliest availability
and use of stable, though necessarily incomplete, data
• Production, deployment/distribution and maintenance issues
are often also significantly in play in concurrent engineering

29. CONCURRENT
ENGINEERING
• Concurrent engineering success depends on detailed
planning and scenario thinking, despite the fact that so much
will change over the completion of a major systems
development
• Only through carrying out detailed planning can sufficient
adaptability in the system design, interfaces, and program
elements be attained to succeed in concurrent engineering
• Von Moltke (paraphrase): Plans don’t survive the first shot of
battle, but the act of planning is invaluable for anticipating
lateral and temporal issues in a system and a program, to be
able to react well on the fly
• Scenario planning improves thinking about back-up
developments for the most uncertain components and
subsystems
• Any other approach to concurrent engineering without
planning, scenarios and contingencies just increases the
schedule and cost, usually substantially

30. INDIVIDUAL TRAITS
AND SKILLS
• System general management
• Synthesis: technology integration and enterprise
integration
• Cross-functional, and cross-disciplinary prowess; talking
the language of the domain specialists
• Fluidity making multi-dimensional trade-offs
• Comfort dealing with complexity, ambiguity and even
contradictory points of view, without devolving to prolonged
indecision
• Savvy, thoughtful negotiation – technical, commercial,
programmatic

31. INDIVIDUAL TRAITS
AND SKILLS
• Continually provide for uncertainty
• Evolving repertoire of back-up plans and fall-back positions
• Multiple back-up options in highest risk areas of the
system
• Goal: That failure of any single approach not paralyze the
entire system and development program

32. INDIVIDUAL TRAITS
AND SKILLS
• Confront emerging challenges
• Acknowledge problems, hitting them hard and early
• Be serious, but not driven to distraction, about schedule,
budget and performance risks
• Masters of persuasion, influence, sourcing reliable
information and high resilience communication
• Internally and externally
• Shaping expectations – management, customers, partners
• Builders and wielders of soft power of influence to remove
bottlenecks, more than leaning on formally appointed
authority

33. ROLE AND
RESPONSIBILITIES
• Acting as the hub for technical decision making
• Architecture and high level design
• Setting performance and reliability goals at a system level,
and then partitioning and setting the same for sub-
systems
• Defining interfaces and interactions among subsystems,
as well as the external deployment architecture
• Determining whether to develop components and sub-
systems in-house or to source from outside vendors

34. ROLE AND
RESPONSIBILITIES
• Prescribing manufacturing/production requirements, as
well as maintainability, reliability and repairability
• Specifying system level test requirements, with flow-down
as appropriate to sub-system, integration, unit and
component tests
• Checking and challenging component and sub-system
design fitness
• Surveying the horizon for new technological solutions,
design and modelling tools, and development practices
• Ensuring that the development is completed in a timely
and economical manner

35. WHAT SETS APART GOOD
SYSTEMS ENGINEERS
FROM AVERAGE
• Strong voice of the customer to guide ongoing decisions
• Advocacy for the customer inside the business, at the
same time as influential representation of the company
with the customer and marketplace
• High integrity
• Adaptability to rapid change, but with strong, predictable
and persistent underlying goals and values
• Fast, concise, high fidelity communication to review and
adapt the work of component and sub-system
development teams
• High levels of real-time insight into the performance of
outside constituencies upon which the development
program depends

36. WHAT SETS APART GOOD
SYSTEMS ENGINEERS
FROM AVERAGE
• Demonstrated understanding of peoples’ attitudes and
needs
• Ability to build true commitment (not just symbolic) from
teams and individuals to the development program’s
objectives, without overreliance on executives to do this
for them
• Rapid capacity to translate across technological and
enterprise domains; universal translators among
technologies and business considerations
• Nearly immediate understanding of the system-level
technical implications from alternative possibilities in
components, sub-systems and architectural variations

37. MOVING FROM
GOOD TO GREAT
• Sufficient technical depth and capacity in systems engineering to
challenge component and sub-system engineering groups on the
range of potentially viable sub-system solutions, as well as the best
selection and advantageous mutations
• Diversity, competition of ideas and mutual evolutionary influence of
ideas propels almost all progress
• Ultimate test for the technical organization in the relationship
between systems and sub-systems:
• Willingness to invest the systems engineering function with power of
direction over subsystems, vs. just consultation
• Though necessarily, directive power needs to be rarely exercised to
keep system-subsystem engineering relationship functioning well
• At the very least: Requirement to reach concurrence, if sub-system
teams and vendors are strong

38. GOOD TO GREAT
• Comfort trading off constantly between personal risk and
project risk
• Achieving breakthrough, multidisciplinary R&D progress
quickly usually requires the systems engineer to stick his or
her neck out many times along the way, challenging people
and institutions
• The job of systems engineering requires thick skin while still
being able to relate well to others
• Realpolitik of systems engineering in many cases requires
achieving consensus through the least unacceptable
alternative
• From time to time though, technical greatness in systems
engineering requires going beyond individual and institutional
comfort zones, to achieve breakthrough performance,
reliability and scalability

39. GOOD TO GREAT
• Self-regulation and ability to remove political obstacles
before tackling technical obstacles
• Deft ability to keep constituencies that often try to assert
partial control (finance, legal, regulatory, administrative) at
bay to preserve as much freedom of action as possible
• The ability to hold global interests for the system’s
development well ahead of local interests is usually much
easier if there is a real and widely shared sense of urgency
and absolute necessity
• Focus relentlessly on achieving entropy reduction
• Which often means internalizing as much of the difficult
technical challenges as possible

40. GOOD TO GREAT
• Obtain and sustain the quality and quantity of resources to
keep development (not just plodding along, but) to achieve
industry-leading speed of development and performance
advances
• An early climate of success in a development program often
becomes self-fulfilling
• Express agreement on strategy (technical, programmatic or
commercial) through articulation of how success will be
measured and evaluated
• Vaguer articulations of strategic agreement usually conceal
too much difference of interpretations
• Those divergences about what constitutes success become
problematic when inevitably exposed later

41. DIAGNOSING AND
FIXING TROUBLE
• Most system level problems have a strong contribution
from sub-system interface issues
• Technical interface issues almost always have a
corresponding team communication issue, or an
accountability lapse in the affected area, as well as one or
more technological knowledge gaps
• Lasting corrective and preventative action in systems
engineering requires improvements of all three of:
1. Interface definition, change management and related
quality control
2. Team communication protocols
3. The way technological knowledge is developed, and
communication of new findings

42. SIGNS OF HEALTHY
DYNAMICS IN SYSTEMS
ENGINEERING
• The propagation of change as a design evolves is well
isolated much of the time, and if not fully isolated, the
propagation is well anticipated beforehand
• This is usually a good signal of system technological
sophistication and sufficient diffusion of know-how
throughout the R, D & E team
• The project hierarchy is not overburdened with detailed
decisions
• This is a sign of reasonable system architecture, and,
sufficient diffusion of sub-system and system wherewithal
creating sufficiently decentralized design and
troubleshooting behaviours

43. SIGNS OF HEALTHY
DYNAMICS IN SYSTEMS
ENGINEERING
• People do not suppress information, especially problems
• If this happens, it is highly corrosive to complex
development project success
• You can’t manage what you can’t see
• Everybody is free to speak; truth speaks to power
• Interfaces are rigorously documented from early in the
system design
• The interfaces will change, often dramatically
• The only way to synchronize change technically and
organizationally is to diligently document the evolving form
of the interface specification, starting from the beginning

44. SIGNS OF HEALTHY
DYNAMICS IN SYSTEMS
ENGINEERING
• Interfaces don’t just change, they move, as sub-system
and sub-domain technical jurisdictions expand, contract
and otherwise morph to most efficiently and robustly
deliver system performance
• This is often associated with the right kind of competition
for ideas with people wanting to expand their
responsibilities and take initiative
• In contrast, the wrong kinds of attitudes and behaviours
leave technical and responsibility gaps

45. SIGNS OF HEALTHY
DYNAMICS IN SYSTEMS
ENGINEERING
• Movement of domain boundaries improves systems-level
thinking at a sub-system level, and reveals latent gaps or
logical errors early which get more expensive to change over
time
• Movement of domain boundaries often also enhances
interdisciplinary stimulation of ideas that would otherwise go
unrealized and improves adaptability as technical and market
conditions develop
• Static and permanently exclusive partitioning of system
functionality holds back the development of technology,
people and management practices
• Fixed boundaries prevent specialists in sub-domains from
learning about and through adjacent technologies; rigidity can
start to set in

46. SIGNS OF HEALTHY
DYNAMICS IN SYSTEMS
ENGINEERING
• Progressive integration of subsystems takes place
starting early in the development
• Avoid big bangs of integration late in the development
cycle
• Instead, see creation of the ultimate system as a
progression of ever more capable systems
• This way, hypotheses and intrinsic design assumptions get
tested more quickly, allowing earlier and more flexible
course corrections when issues emerge
• People confront some cross-functional issues and become
more adept at this thinking early
• Progressive integration and system test is increasingly
important the more that the system incorporates
technologies operating beyond the prior state-of-the-art

47. SIGNS OF HEALTHY
DYNAMICS IN SYSTEMS
ENGINEERING
• The highest risk interfaces, the ones most likely to
undergo the most change, are put to test early
• Enterprise integration and communication are improved,
usually preemptively, where the most sensitive technical
interfaces of the product are
• Best: Co-location of collaborating staff
• Next best: Reciprocal resident or rotating engineers

48. SIGNS OF HEALTHY
DYNAMICS IN SYSTEMS
ENGINEERING
• Sub-systems are optimized with a view to overall system
performance, rather than more parochial interests
predominating which may optimize a sub-system at the
expense of the overall system
• System optimizing behavior is most tested when time,
budget, or inbound technological skills are most severely
stretched
• Consensus-building and collaborative decision making
has mutual trust as its foundations which is built on
multilateral technical excellence and good
communication, rather than less laudable social
currencies

49. SIGNS OF HEALTHY
DYNAMICS IN SYSTEMS
ENGINEERING
• There is simultaneously both intense commitment and
camaraderie to achieving the system development goals,
while having vigorous, authentic, multi-disciplinary
competition between and evolution of ideas
• Technical risks, and programmatic risks are identified
early
• There’s strong knowledge of major technological and
cross-functional sensitivities that will affect the
development
• Estimates of resources, time and cost to complete major
tasks bear a strong resemblance to what is ultimately
required

50. SIGNS OF HEALTHY
DYNAMICS IN SYSTEMS
ENGINEERING
• There is tolerance for failure, but not incompetence
• Experimentation is highly disciplined
• Truth speaks to power, and everyone is very candid
• Collaboration is high, but so is individual accountability
• Collaboration is not the same as consensus
• Teams may provide input, but individuals need to decide
• Leadership is strong, especially (and somewhat
paradoxically) the flatter the engineering organization

51. DESIGNING BEYOND THE
STATE OF THE ART
• Focus development by having clear statements about
target performance requirements, but let technological
advancements pace the system development effort
• A concrete target is necessary to provide a forcing function
to drive progress
• At the same time, listen to what new technological
knowledge reveals about component, sub-system and
architectural capabilities
• Yin-Yang: Be persistent up to a point, but also be
adaptable

52. DESIGNING BEYOND THE
STATE OF THE ART
• Define the boundaries of the performance-critical sub-
regions of the system within which intersecting technologies
collide in unpredictable ways
• These regions of the system are not just bottlenecks, but
areas of scientific or technological confusion, flux in thinking,
and partial information at the start of the systems engineering
R&D program
• The interim step to move forward is to transform these
regions into solvable problems that lead to analytical and
design models with predictive, verifiable value
• Often, solutions cut across previous sub-domains of
expertise, and introduce new ones
• Decomposition of such problems usually requires several
iterations to reach success
• The people who can do this well are rare, and very valuable

53. CULTURAL TIPS
• Greater recognition and esteem needs to flow to those who
are willing to take responsibility for full system performance
• Narrower purview technical specialists have a role, and a big
one, but technology and enterprise integration have to come
first
• Caution: Some technical cultures view movement away from
specialization as a sign of failure
• Synthesizers are seen as those not having been good
enough to cut it in specialization
• This is toxic to the ability to develop systems engineering
excellence
• Adverse selection and development then takes hold; the
people most impactful to overall system and enterprise
performance end up being not the strongest

54. CULTURAL TIPS
• The small things get done well, not just the big things that
have more visibility
• As much progress comes from the cumulative impact of
individually small improvements over time, as does from
the bigger architectural and technological leaps
• Typically: 50% to 75% of advancement comes from small
improvements vs. breakthroughs
• The big, bold steps in systems engineering can never be
done or consolidated better than the smaller things

55. CULTURAL TIPS
• When people need to take technical shortcuts, they do so
with a strong grasp of the fundamentals governing the
advisability and best way of doing so, rather than
guessing or disingenuously pleading the need for
expediency without sufficiently understanding the issues

56. CULTURAL TIPS
• There is widely diffused understanding of the evolving
overall goals for the development program
• Experience, knowledge and ability are the bases of power for
how most decisions get made, rather than formally appointed
authority
• The people in high profile roles need to be uniformly impelled
with a sense of urgency
• A sense of external competitive urgency and fear of missing
out is the only way to keep efficient, and develop reliable
bottom-up estimates of cost, schedule and resource
requirements upon which complex systems engineering
depends

57. CULTURAL DIVIDEND OF
SYSTEMS ENGINEERING
• Done well, systems engineering reinforces the multi-
disciplinary adaptability, learning, and co-opetition that
creates the right environment for rapid technological and
personal development progress
• Systems engineering prowess counters tendencies toward
more didactic management styles and sub-domain narrow
interests that can otherwise increase in rapidly growing
businesses

58. ALLOCATION MODEL
Allocation Skill Span Additional Comments
20% Systems
Engineering
Split ~half to Systems Engineering Group,
with the other ~half distributed among
major subsystem groups
30% Subsystems
Engineering
50% Unit/Component
Specialists
Typical allocation of staff resources in a large scale systems
engineering development program:

59. QUICK STARTING
PLACES
FOR
IMPROVING SYSTEMS
ENGINEERING
(EVEN FOR PROJECTS MID-DEVELOPMENT)

60. A3
• A standardized written and visual communication format
• The A3’s constraints and compulsory structure are the keys
to its power
• It is written to answer all questions management might
subsequently have about an issue and its resolution
• The A3 forces all sides of a complex technical and enterprise
integration issue to be expressed concisely, promoting
collaboration and ability to embrace divergent views
• Encourages refinement of multi-disciplinary thinking,
bringing problems down to their essential elements
• Tactical use is to solve problems and plan initiatives, but the
strategic leverage is to foster learning and systems thinking
• Serves as a record of the agreed upon plan

61. A3
• Standard elements:
• Background of issue at hand, including business context
• Fact based current conditions and problem definition
• Future state goals and targets
• Analysis of the gap between current and future
• Root cause analysis
• Proposed countermeasures (experiments)
• Requires talking to everyone who substantively touches the work
• Requires exploring multiple potential countermeasures, to activate a
wider dialog and analysis
• Effect confirmation
• Plan of action, time bound, including names, dates and deliverables
• Follow-up, to ensure that improvements are sustained
• Manager approval box: Tool for mentoring author and building
alignment

62. A3
• Cautions:
• Overuse of photographs to fill up the page, to the detriment
of compulsory elements which drive systems thinking
technologically and across the enterprise
• Root cause analysis being confused with assumptive quick
fixes

63. A3

64. TRADE-OFF CURVES
• Builds integration capability within and across constituent
technologies, as well as pan enterprise
• Fills technological knowledge gaps, and sometimes even
scientific knowledge gaps, improving knowledge of the
solution space
• Captures and preserves knowledge
• Generates awareness and articulates exchanges across
domains: technical, cost, reliability, UX/emotion, commercial
• Reveals design efficiency sensitivities to controllable factors
• Provides for rapid adaptability when some components
exhibit better than expected performance, or others worse, to
find offsetting adjustments in the system or more suitable re-
architecture

65. CONTINUOUS
IMPROVEMENT
• Goals: Increase signal, reduce noise, reduce defects or
errors
• Can be extremely profitable, for an extended period of time
• Reduces the effort to get the same result and boost
productivity
• Can be applied to product or process
• Highly contextual, internally and externally

66. CONTINUOUS
IMPROVEMENT
• Multi-disciplinary; encourages people to see all sides of
an issue or opportunity for improvement
• Continuous improvement -> Continuous Innovation ->
Continuous communication -> Keeps organizational
interfaces internally and externally open and exercised
• It is a lot easer to keep multi-disciplinary channels steadily
active, rather than trying to reopen them after a lengthy
quiescent period

67. CONTINUOUS
IMPROVEMENT
• Places emphasis on people and information interactions,
from where most improvement needs to come
• Bottom-up, helps build pragmatism, buy-in and
engagement
• Requires dis-aggregating every step of any process or
workflow to put it under a microscope for improvement
• Strong evolutionary analog to improve adaptability to the
competitive pressures of any ecosystem
• Institutionalizes widely shared and understood
mechanism for driving quick, frequent changes to capture
and activate the value of new knowledge
• Helps keep the innovation metabolic rate of the
organization high

68. SET-BASED
ENGINEERING
• Promotes the most constructive form of dealing with variability in
development, and bounded knowledge and rationality of people
• Increases adaptability, and optionality, tapping the strength of diversity
• Prevents prematurely falling in love with a single, early idea
• Each approach reveals insights about the challenge, deepening
understanding of the problem to be solved, and offers different risk
management possibilities for proceeding despite missing information
• Often leads to combination of approaches to achieve the best solution
• Promotes competition of ideas, fitness testing, and advantageous
mutations
• Provides fall-back positions
• Promotes rapid analytical capabilities and quick, effective experiments to
fill in multiple core and adjacent technological knowledge gaps
• Improves likelihood of obtaining the best system performance within any
given time period and budget

69. PEER REVIEW OF
GRANULAR EFFORT AND
TASK ESTIMATIONS
• Especially if people with stronger systems engineering
skill can review the task estimates of developing team
members
• Systems-aware peer review helps start diffusing systems
thinking and awareness, even at sub-system levels
• Detailed task planning (~one day increments for
individuals) brings out a level of detail to illuminate all
required work, which enhances ability to see and
communicate about technical and project interactions
• Dark work, which arises as a surprise as people get into
their tasks, creates schedule and synchronization havoc

70. PEER REVIEW OF
GRANULAR EFFORT AND
TASK ESTIMATIONS
• Having peer review helps developing team members get
better at anticipating all of the required work, and ways to
seek the right economies of effort when initial estimates
are too high
• A culture of having individual contributors expose
themselves to feedback when the cost of learning is
lowest pays dividends when similar amenability is
required for code and design reviews to achieve lowest
cost design quality improvement

71. SUSTAINING
ENGINEERING
• One Starting Point:
• How to do a proper ECN (h/w), or rapid fire unit, integration
and system test (h/w and s/w)
• A Second:
• Review and analysis of in-market system performance:
maintenance, reliability, design weaknesses, user
satisfaction, usage complexities – bring them all together
and analyze to devise and implement design, production,
training and support collateral improvements

72. CHANGE PROPAGATION
ANALYSIS OR FAULT
TREE ANALYSIS
• For starters, helps people to get good at analyzing the
propagation of change on both sides of an interface, not
just their preferred side or over a favoured sub-set of
system issues
• Later, have people move beyond one interface to change
and fault propagation analyses linking further through the
system
• Skill in change and fault propagation analysis is the
corollary skill of requirements propagation in systems
analysis as part of product management and system
architecture
• Typical starting point: The highest sensitivity areas of the
overall system

73. CHANGE
PROPAGATION
Simple example of a visualization tool:
Source: “Are Your Engineers Talking to One Another When They Should,”
Sosa et al., Harvard Business Review, Nov. 2007

74. CONFIGURATION
MANAGEMENT
• Can be applied to great effect even to projects already
underway
• Modus Operandi:
• Any necessary and approved change in a component or
sub-system is immediately reflected in the prevailing
system specification, and push-communicated to all
impacted groups

75. CORRECTIVE AND
PREVENTATIVE ACTION
(CAPA)
• Fosters both technical systems
engineering, and cross-functional
enterprise integration
• Root Cause Analysis (RCA) and
Five Whys analysis: When done
right often forces people across
technology and functional
business domains
• Immediate corrective measures are
usually the easy part

76. CORRECTIVE AND
PREVENTATIVE ACTION
(CAPA)
• More difficult is the double feedback loop of a sufficiently
broad set of preventative actions:
• Finding time and sustaining priority on this second
stage/systemic form of correction
• Doing preventative improvements in a way that is sufficient
and effective, without going overboard and introducing
overreaching low value bureaucracy
• A defined and understood CAPA playbook helps people to:
• Surface design and production problems transparently,
• Develop deep understanding of the issues,
• Engage the right resources to build a solution, and
• Turn the problem into an opportunity to bring performance
and competitiveness to a new level

77. PROJECT CONTROL
ROOM
A.k.a. System Management Centre / Obeya
• Nerve centre for all project information
• Immersive, collaborative, cross-functional, one-team environment
• Displays the latest:
• Delivery schedules, test schedules and operational/deployment
planning
• Visual status of anything that is delayed or has a high probability of
leading to a delay without further technical or programmatic change
• Gantt or other flow charts showing goals, schedules and tasks for
each major subsystem as well as the system as a whole
• Prototypes
• Work in progress
• Backlogs for each department or workgroup
• Supplier readiness
• Decisions required
• Chief concerns and alternatives for each component or subsystem

78. PROJECT CONTROL
ROOM
• Instant visual status distinguishing normal from abnormal
conditions, recent status changes, and responses initiated
to abnormal condition emergence
• Schedule: Identification of all critical tasks in support of the
timeline
• Product: Poster display of latest design and design
thinking for each subsystem, as well as major concerns or
investigations underway
• Integration: Change propagation visualization

79. PROJECT CONTROL
ROOM
• Quick look readings of all system engineering program
progress – tests, charts, trends, schedule, latest design,
prototypes, problems, components, sub-systems, and
system
• Push update requirement, so that anyone making a
change or aware of an update has to mark-up what is in
the project control room
• Place to go for spontaneous, ad hoc updates and
discussions, in addition to scheduled development
program meetings such as scrums and program reviews
• Place to go where people can signal that something
significant needs to change, or if they have a problem, and
need help – yellow and red pins or post-its help

80. PROJECT CONTROL
ROOM
• Creates interactivity, transparency and inclusiveness
• Speeds decision making by building common language
and understanding of the issues at hand
• Helps dramatically with rapid, continual onboarding of
new staff in high growth environments
• Keeps everyone focused on the same key issues
• Helps team anticipate problems before they get more
serious
• Contributes to achieving better integration of work
technologically and cross-functionally
• Unifies the system of engagement and the system of
record in all development program information

81. PROJECT CONTROL
ROOM

82. PROJECT CONTROL
ROOM
• A low tech, in-person forum builds personal accountability to
keeping the collaborative centre current
• Accountability to collaboration is more easily set aside by
some when relying entirely on electronic collaboration tools
• Test of project control room traction: Is this room where
people turn for rapid updates, daily/weekly stand-ups, and to
convene to solve emerging problems?
• If so, things are usually going well making the centre a
significant contributing and reinforcing element of the right
kinds of systems engineering behaviours
• If it is not where people are turning, consider using 5 Why’s
RCA followed by CAPA to increase utility of the project control
room

83. TEST ENGINEERING AND
TEST SYSTEMS
ENGINEERING
• Multi-disciplinary
• Requires deft improvisation, usually, to create good test
systems quickly without blowing big $ and time
• Gets quickly to the essence of how to abstract to an
effective test, one that preserves the critical attributes at
hand, while keeping things simple and quick:
• Minimum Effective Test
• Especially when working beyond the state-of-the-art,
devising an adequate test can be as much of a scientific
and engineering challenge as the design of the core
component, sub-system or system feature to be tested

84. TEST ENGINEERING AND
TEST SYSTEMS
ENGINEERING
• Common form of challenge to keep people trained on the
minimum effective form of test:
• If we had to test this idea in 24 hours or less, how would
we do it?
• Continuous improvement form of getting better at test
efficiency:
• What would bring out more of the systems-level test issues
economically in earlier component and integration test?
• Guiding idea: Always be minimizing the number of factors
that can only be evaluated during a full system test
• Drives skills in intermediate process monitor development

85. QUALITY, RELIABILITY
AND YIELD
ENGINEERING
• Shortfalls in these areas represent deficiencies in
technological knowledge, and enterprise integration
• Concrete work items to improve quality, reliability and
yield creates urgency and focus to build cross-discipline
analytical and design capabilities

86. INTERMEDIATE
STEPPING STONE
• Next generation concept system design
• Looking at new techniques for eliminating presently rate
limiting components or sub-systems, to develop sets of
breakthrough possibilities and flow-through of prospective
change to overall future system architecture

87. DIVIDENDS OF BUILDING
SYSTEMS ENGINEERING
CAPACITY
• Smaller team sizes, retaining agility at scale
• Easier ability to bring together sufficient interdisciplinary
and enterprise integration knowledge to solve emerging
technical and business issues quickly with small, flexible
teams
• Less delegation up to more senior, central decision
authority
• Less bloat from large teams, knowledge gaps, cross-
disciplinary translation issues, and overall sluggish issue
investigation and resolution dynamics

88. DIVIDENDS OF BUILDING
SYSTEMS ENGINEERING
CAPACITY
• The greater the number of people who can lead and
significantly contribute to the resolution of multi-
disciplinary, cross-functional issues, with a set of
contextualized tools, the scale-up business enhances:
• Ability to concurrently address a greater volume of
stresses that build up in a rapidly expanding businesses –
technology, product, markets, customers, services
• The capacity to shoulder a significant volume of issues
helps keep optimism high to drive energy and motivation,
while at the same time preserving the ability for the
organization to be realistic with itself about where it is
really at in its competitive environment and how to improve

89. SUMMARY
To Do Systems Engineering Well Requires:
• Technical excellence, both breadth and depth
• Lifecycle consideration, not just the sexy front end of
development
• Communication skill, both verbal and written
• Capacity to deal with a high rate of cascading change
• As much focus on social, political and customer
considerations as on technical and production matters
• The faster technology changes or the larger the
technological step sizes, the more technology integration
across domains and over time matters
• Leadership by example is the only sustainable model

90. SUMMARY
• Management has to be based on attention to a lot of detail
• A deliberate balance and co-existence needs to be
maintained between centralization and decentralization of
technical and business decisions
• A body of mutually reinforcing practices, both informal and
formal needs to be sustained
• Systems engineering is an organizational and management
challenge as much as a technical challenge because of the
impact of social interactions, especially at and beyond the
leading edge of technology
• Rising technical depth, uncertainty, and complexity requires
increasing technological and organizational integration
• There are many tractable, immediate starting points to
improve systems engineering wherewithal, even mid-project

91. FURTHER
DISCUSSION
For arrange further private discussion of any of today’s
topics or related matters:
dave.litwiller@communitech.ca

92. ABSTRACT
Systems Engineering will provide a comprehensive overview of the
most effective practices, tools and techniques to employ when carrying
out R&D and engineering of multi-disciplinary technologies operating at
the state-of-the-art, or even pushing beyond.
Dave Litwiller’s talk will be directed to scale-up stage technology
enterprises. Emphasis will be placed on how to build and reinforce
systems engineering capability spanning multiple complex
technologies, and achieve cross-functional enterprise integration with
large and growing development teams.
Collaboration, communication, building leadership, and agility at
increasing scale will be recurring themes. The seminar will also outline
the stepping stones most often used to move from good to great in
systems engineering capability.

93. TROUBLE REPORTING
• Defined protocol for reporting problems and their analyses
• Standardized reporting format:
• This isn’t bureaucracy;
• It forges consistency and transparency so that important
information doesn’t get lost in the vagaries of varied reporting
formats
• Categorization system for severity
• Distribution and escalation
• Achieving consistency across technology domains – often
the most difficult part
• Supplier or contractor penetration is often a soft spot, and
best addressed early through contract terms providing for
site and information access rights, as well as reporting
obligations