Risk generated by instability
  ·   Instability in the system engineering process
  o   Requirements Instability 
Item §  Inappropriate requirements not yet eliminated Best Estimate Best Estimate Best Estimate   Comments And Suggestions
1 ·   Poorly defined or ambiguous requirements  
2 ·   Out of scope requirements  
3 ·   Non-verifiable requirements  
4 ·   Requirements that dictate a specific design approach  
5 ·   Informal requirements (usually pushed by high level
    or influential individuals)
 
  §  Requirements still in flux
6 ·   Original set of requirements was incomplete  
7 ·   Changing user awareness/knowledge driving new
     requirements/needs
 
8 ·   Poorly defined or ambiguous requirements are being
    redefined
 
9 ·   Informal requirements (usually pushed by high level
    or influential individuals) constantly morphing and
    persistently attaching themselves to the formal
    requirements process
 
10 §  Allocation of requirements is incomplete  
11 §  Acceptance/negotiation of requirements is incomplete  
12 §  Outstanding requirement allocation/acceptance issues
    remain
 
13 §  External and internal requirements creep  
  o   CONOPS Instability
14 §  Decision process does not converge to one clear
   concept
 
15 ·   CONOPS definition unclear, multiple options
    carried forward
 
16 ·   Trades are not comprehensive; results are
    incomplete, or non-conclusive - best technical
    approach is undefined 
 
17 ·   Unresolved conflict between political/management
    desires and best technical approach
 
18 §  Interfaces (up, down, and across) are in flux or at risk
    [up: GMD, MDA, DoD;  down: among MKV program
    elements (including government, contractors, and
    subcontractors); across: User, TRADOC, Army, SMDC,
    MSIC., etc] 
 
19 §  Detailed technical risk assessments (cost, schedule,
   performance) of various CONOPS approaches are
   incomplete or inadequate 
 
  o   Interface (up, down, and across) Instability
    
[up: GMD, MDA, DoD;  down: among MKV program
      elements (including government, contractors, and
      subcontractors); across: User, TRADOC, Army, SMDC,
      MSIC, etc]
20 §  Management initiatives and reciprocal processes
   required to formally define and completely specify all
   interfaces are not functioning or not working smoothly
   and efficiently.  There is little evidence of steady
   convergence to complete stable interface
   specifications/agreements.
 
21 ·   Definition not clear or complete  
22 ·   Specification not clear or complete  
23 ·   Formal written agreements not yet negotiated  
24 ·   Documentation missing or incomplete  
25 ·   Interface risk management not formalized  
  o   Design Instability
26 §  Approach is unclear, multiple design options carried
   forward
 
27 ·   Trades are not comprehensive; results are
    incomplete, or non-conclusive.  
 
28 ·   Simulations and models of sufficient fidelity,
    accuracy, and timeliness are unavailable.
 
29 ·   Unresolved conflict between political/management
    desires and best technical approach
 
30 ·   Unresolved conflict between historical (safe) and
    alternative (higher payoff but higher risk) approaches
 
31 §  Documentation and information flow down does not
    keep up with design changes
 
32 §  Detailed technical risk assessments of the various
    design options are incomplete or inadequate
 
33 §  Contingency planning not initiated  
  o   System baseline Instability
34 §  Definition is in flux due to management failure to
   generate stable funding, schedule, requirements,
   CONOPS, and design 
 
35 §  Documentation defining baseline requirements and
   design are not thorough or detailed enough, nor timely
   enough to provide necessary program stability through
   configuration control  
 
  ·   Instability in the program management process
  o   Resource Instability
36 §  Unexpected events/decisions – expectations that are not
    realized.  (Note: Although program instability can be
    generated at any level within the management process,
    higher levels of management have the capacity to
    generate higher levels of instability.)
 
37 §  Poor planning due to management inexperience   
  §  National priorities change
38 ·  Various GMD elements, THAAD, Patriot, and other
    MDA systems must continually compete for funds
 
39 ·   MDA, GMD, MKV Funding and schedules must be
    renegotiated and justified yearly if not continuously
 
  §  MKV program priorities change
40 ·   MKV Funding of its various elements and functions is
    reassessed and therefore formally or informally
    re-competed, continuously.
 
41 ·   Management funding reserve is insufficient to
    cover the unexpected.
 
42 ·   Risk mitigation and contingency options often
    introduce unexpected cost or delay
 
  §  Schedule instability (Consider time as a managed
    resource) 
43 ·   Management schedule reserve is insufficient to cover
    the unexpected.
 
44 ·   Deploying risk mitigation and contingency options
    often introduces unexpected delay
 
  §  Expertise instability (Consider expertise is a managed
    resource) 
45 ·   Contracting issues that could potentially force
    contractor to work at risk may quickly dissipate
    much of the MKV corporate knowledge and
    experience base
 
46 ·   Highly competitive and robust job market generates
    too much turnover – Government and MKV corporate
    knowledge and experience is lost
 
47 ·   Poor management, working conditions, attitudes,
    facilities, or support services creates an environment
    of low morale or an uninviting culture that generates
    excessive turnover among the best, most productive
    employees while the deadwood remains entrenched.
 
  §  Facility instability (Consider facilities as a managed
    resource) causes inefficiencies that are costly in both
    time and money
48 ·   Moves of personnel are disruptive  
49 ·   Moving, updating, and changing computing hardware
    and software are especially disruptive
 
  o   Management Instability
  §  Quality is variable and uncertain
50 ·   Excessive management turnover breeds
    inconsistency and loss of focus.  Good managers
    are more likely to leave than poor ones.
 
51 ·   Upper level Management interfering with or forcing
    lower level technical decisions
 
52 ·   Upper level Management imposing arbitrary due dates   
53 ·   Competing managers trying to make a shared
    outcome suit their individual needs
 
54 ·   Turf wars, egos, and prima-donnas: failure of
    management to quickly force cooperation and
    integration between interdependent elements,
    functions, and individuals that are interacting
    dysfunctionally
 
55 ·   Critical-experience turnover creates delays and loss
    of program continuity. 
Critical MKV program
    experience and knowledge (managerial, technical,
    and support) should be defined and then always
    maintained at two deep
 
  Risk generated by sub-optimal process
  ·       Risk generated by inefficiency and ineffectiveness in the systems engineering process
  o   Outside pressure imposing sub-optimal program constraints
56 §  Technical, political, or personal needs of critical
    interface conflict with MKV program needs
 
57 §  Higher level DoD, MDA or GMD management forces
    dysfunctional decision, requirements, policy, ideology,
    or constraints
 
58 §  Funding instability  
59 §  Schedule instability  
  o   Inside pressure imposing sub-optimal constraints
60 §  Program management imposes unnecessary or
    dysfunctional constraints upon the program in response
    to corporate/government needs, higher level authority,
    personal career goals, ideology, historical precedent,
    unrealistic expectations, or incompetence.
 
61 §  Technical leaders impose unnecessary constraints on
    the technical approach due to the pressure of
    corporate/government needs and higher level authority,
    or because of personal career goals, ideology,
    historical precedent, unrealistic expectations, or
    incompetence.
 
62 §  Infighting within the organization or at upper levels of
    management – control/funding issues and/or
    personal/ego issues
 
  §  Sub-optimal organizational culture
63 ·   Stifled communications; openness, creativity, risk
    taking, critical thinking and constructive criticism
    are not widely encouraged or supported; outside
    scrutiny and ideas are unwelcome (NIH syndrome);
    lax integrity and getting box checked are more
    important than producing quality product; cynical
    attitudes and low morale are not uncommon; and
    the program has difficulty retaining top talent.
 
  o   Sub-optimal requirements flow down
64 §  Allocation and acceptance process bogged down
    with conflict
 
65 §  Conflict resolution – appeal process inadequate to deal
    with case load decisively and in a timely fashion
 
66 §  Poor information/Documentation distribution &
    communications create confusion, timeliness and
    clarity problems
 
67 §  Adversarial or weak Government-Industry interface
    creates delay and much re-work
 
  §  Requirements are of poor quality
68 ·   Ill-defined, not sufficiently specified, or ambiguous  
69 ·   Out of scope   
70 ·   Non-verifiable   
71 ·   Dictates a specific design approach  
72 ·   Informal or ad hoc requirements keep creeping
    into process
 
  o   Sub-optimal CONOPS definition
  §  Simulation and modeling
73 ·   Facility and equipment are inadequate to produce
    accurate timely results
 
74 ·   Accuracy, depth, quality, and completeness are
    sacrificed to meet schedule
 
75 ·   Simulation turn around time is too slow to answer
    questions quickly, consequently issues fall through
    crack after spotlight is removed
 
76 ·   Simulation programming methodology, assumptions,
    and scope of effort limit results to unrealistic (usually
    too simplistic) scenarios, and/or too few scenarios
    are run to effectively explore all important issues.
 
77 §  Cost, performance and schedule conflicts -- between
    management & political desires (both government and
    contractor) versus what makes most technical/practical
    sense.
 
  o   Sub-optimal Interface definition (up, down, and across
     organization – also government to contractor
     interfaces)
78 §  Inadequate formal, documented interface Definition
    and specification
 
79 §  Inadequate communication & Information flow between
    otherwise stove-piped and/or funding competitive
    organizations, components, and elements
 
80 §  Inadequate and untimely interface documentation
    generation and distribution 
 
81 §  Staying plugged in and current on interface issues
    requires a pro-active effort on the part of all parties
    that rarely occurs without upper management on both
    sides constantly pushing cross-organizational
    cooperation
 
  o   Sub-optimal Design process
82 §  Creative, innovative, and open minded approach to
   
design is often at odds with schedule pressure and with
    the conceptual inertia of experienced management
    and technical leads who may be (particularly in large
    corporate or government bureaucracies) risk and
    change adverse.
 
83 §  Design by committee or design by bureaucracy.  Design
    implemented as a democratic or consensus process
    usually fails or is mediocre. 
 
84 §  Creative, innovative, and open minded approach to
   
trades (opening the trade space) is often at odds with
    schedule pressure, and the conceptual inertia of
    experienced management and technical leads who
    may be (particularly in large corporate or government
    bureaucracies) risk and change adverse 
 
85 ·   Trades are often greatly restricted by informal
    assumptions – i.e., they are often designed and
    implemented to prove a point (to support an existing
    opinion or to make a limited choice) rather than
    independently determine the best of multiple
    approaches 
 
  ·   System designers sometimes forget to design in:
86 o   Upgradeability paths  
87 o   Growth margin  
88 o   Ease of hardware/manufacturing implementation   
89 o   Simplified, low cost, efficient, quick maintenance   
90 o   Built in test and comprehensive user friendly
    error coding, also built in redundancy of most
    critical or unreliable processes
 
91 o   Security hardened information, processes, and
     technology (e.g., anti-tamper, software
     vulnerabilities, visual covers, built in protection
     devices and processes, simplified HW &
     SW sanitation to support eventual export, resale,
     or technology transfer
 
92 §  Up to date design Information/Documentation distribution
    & communication is often unavailable to those
    downstream in the information flow causing much
    confusion and rework
 
93 §  Risk assessment and risk flow down (also flow up to
    GMD) often does not occur early enough nor is it
    reassessed often enough, nor is it communicated well
    enough to be a valuable tool to the design process.
 
94 §  Risk mitigation design and implementation often does not
    occur early enough nor is it reassessed often or
    thoroughly enough to be a valuable input or tool-set for
    the design trades process.
 
95 §  Contingency planning to cover each potential mitigation
    failure needs to be worked concurrently with mitigation
    design and planning.  If one waits until the first-choice
    mitigation begins to fail, before starting this process, it
    is often too late to effect a cost-effective solution
 
  ·   Sub-optimal program management: risk generated by
    inefficiency and ineffectiveness in the management
    process
  o   Resource problems that often produce serious
     program risks
96 §  Documentation defining baseline requirements and
    design are not stable or detailed enough, nor timely
    enough to provide effective configuration control  
 
97 §  Non-responsive or non-timely contracting,
    disbursements, legal decisions, personnel actions,
    hiring, etc. often delays important business activities,
    dissipates assets, or degrades accomplishments
 
98 §  Failure to program sufficient management reserves
    leaves a program without options when the unexpected
    happens.  The unexpected seems to always happen
    when you can least afford it
 
99 §  Maintaining multiple CONOPS and design approaches
    is usually more expensive in both time and money than
    expected.  Final choices are often forced by attrition due
    to cost, schedule or risk issues (as opposed to technical
    issues) – a slow decision process is often expensive --
    one must regularly verify that the flexibility gained is
    worth the risk.
 
100 §  Failure to immediately inform all stake holders of program
    changes (requirements, design, funding, management,
    risk, etc) creates confusion, inefficiency, and much
    re-work 
 
  §  Problems finding, recruiting, and keeping best expertise
101 ·   Non-competitive pay and benefits  
102 ·   limited promotion opportunities  
103 ·   Unattractive corporate/government culture  
104 ·   Mediocre to low morale among professional and
    hourly workers 
 
  §  Problems attracting, acquiring, and maintaining an
    adequate technical knowledge base and adequate
    facility, tools, and services to support that knowledgebase
105 ·   Insufficient hardware, software, office space, quality
    working environment, and support creates much
    inefficiency in the typical work place
 
106 ·   If contracting issues either force or threaten major
    contractors to work at risk, much of the MKV
    corporate knowledge and experience may be
    permanently lost along with focus and positive attitudes
 
107 ·   Poor management, working conditions, attitudes,
    facilities, or support services creates an environment
    of low morale or an uninviting culture that generates
    excessive turnover among the best, most productive
    employees while the marginal producers remain
    ensconced in place forever.  Over time, this trend will
    doom a program to mediocrity or failure 
 
108 ·   Highly competitive and robust job market generates
    too much turnover – Government and MKV corporate
    knowledge and experience is lost.
 
  o   Sub-optimal Facility issues
109 §  Non co-location of highly interactive individuals,
    functions, and services creates delays
 
110 §  insufficient conference rooms, telecom rooms, projecting
    equipment, and video teleconferencing rooms is a major
    driver of inefficiency and boost travel costs
 
111 §  Facility and personnel security services need to be
    customer focused with a “can do” rather than a “can’t do”
    attitude.  Creative solutions that maintain security while
    facilitating business activity can produce tremendous
    process efficiency as well as better security
 
  o   Management problems that often produce serious
    program risks
112 §  When politics trumps good technical decisions  
113 §  When ego, personal conflict, and competitiveness
    trumps good technical decisions
 
114 §  When bureaucracy drives or dictates design  
  §  When appearance trumps reality
115 ·   The “real” task is to get the box checked and look
    good to the next level up
 
116 §  When corporate interests/profits trumps product
    performance, cost, and quality
 
117 §  When government is out of the technical decision loop  
118 §  When government is being lead through the acquisition
    process rather than leading or managing the process
 
  §  When management is incompetent (at any level – but
    higher is worse)
119 ·   Establishes poor corporate or government culture --
    working environment
 
120 ·   Management decisions are primarily self promotional  
121 ·   Management, continually pressured to do more with
    less, presses employees for uncompensated services
    and scrimps on tools, services, and promotions.
 
122 ·   Management micromanages – asserts too much
    control at lower levels (low morale, little loyalty)
 
123 ·   Management is estranged from its employees (low
    morale, little loyalty)
 
124 ·   Due dates are arbitrary (never enough time to do it
    right, always enough time to do it over)
 
125 o   Upper level Management imposing lower process schedules
    (due dates) that provide for plenty of review time but not
    enough time to do the work adequately.  If schedules need
    to be squeezed, shorten the review time first.
 
126 ·   Poor, stilted, or stifled communications up and down
    the organizational chain
 
127 ·   A “not invented here” problem stifles innovation  
128 ·   Risk taking and new approaches are penalized  
129 ·   Honesty about pointing out management  or technical
    problems is penalized instead of encouraged
 
130 ·   Personal integrity is less important than being a
    team player
 
131 ·   There is an adversarial relationship between
    government and contractor
 
132 ·   There is an adversarial relationship between MKV
    elements
 
133 §  Organization structure is too flat  
134 §  Organization structure is too Hierarchal   
  o   Risks associated with Higher level MDA/GMD
     management
-- uncertainty of, dysfunctionality in,
     or not enough attention paid to:
135 §  Management interface, program visibility, and
    program risk assessment 
 
136 §  Managing and defining political goals, technical
    goals/needs/requirements 
 
137 §  Clearly defining program interfaces & limiting scope   
138 §  Funding & congressional connections  
139 §  Insufficient political visibility/support  
140 §  Mismatch between expectations and what the actual
    schedule can realistically deliver
 
141 §  Mismatch between expectations and what the actual
    funding can realistically deliver
 
142 §  Mismatch between expectations and what the actual
    system performance can realistically deliver
 
143 §  The time and dollar burden upon MKV personnel of
    higher level management inquiries and demands
 
  o   Risks associated with MKV Program management --
    uncertainty of, dysfunctionality in,
    or not enough attention paid to:
144 §  Managing and defining program goals, effectively
    limiting scope to define a doable program
 
145 §  Standardizing an effective program management
    approach/style throughout the MKV program –
    management consistency breeds process efficiency
 
146 §  Explicitly defining the desired (optimal) attributes of the
    MKV organizational culture; additionally by defining
    organizational quality metrics, a venue for critical
    comment, and a regular re-assessment of progress
 
147 §  Maintaining a secure, flexible data sharing structure
    common and available to all MKV elements
 
148 §  Defining and managing optimal information flow &
    communications strategies (up, down, and across) –
    developing metrics to measure success
 
149 §  Defining and managing critical events timing – avoiding
    a “scheduling by crisis” mentality
 
150 §  The time and dollar burden upon MKV personnel of
    program level management inquiries and demands for
    management support
 
151 §  Ensuring top notch (better than adequate) manpower --
    expertise, availability, and continuity
 
152 §  Maintaining schedule coherence – minimizing sources of
    schedule instability
 
153 §  Maintaining funding coherence – minimizing sources of
    funding instability
 
154 §  Program planning -- anticipating changes, requirements,
   problems, and issues, and developing solutions for each 
   before they become critical – avoiding a “management by
   crisis” mentality
 
155 §  Long Range planning -- Clearly defining and outlining
   future critical decision points and developing contingency
   plans for each  
 
156 §  Long range security and logistics planning; implementing
    program protection and availability requirements into the
    program’s hardware and software designs from day 1
    – instead of after-the-fact patches and fixes
 
157 §  Developing a robust, demanding, continuous, and 
    independent review process to ensure both engineering
    and management quality
 
158 §  Define and manage a technically focused, technically
    optimized test schedule and explicitly develop expected
    technical issues and results of each test.  Testing, being
    critical to program success, should remain a purely
    technical exercise -- do not let the test program get
    hijacked by  political needs, PR needs, “showmanship”
    or credibility issues.  These PR functions should never
    influence or drive test schedules or goals
    (see last bullet for a better alternative).
 
159 §  Clearly defining and enumerating the expected attributes of
    quality contracting, legal and public relations functions
    and review goal status often
 
160 §  Planning, staffing, and executing a full time MKV
    marketing/lobbying initiative to build program credibility,
    visibility, and apparent value (image) by continually
    promoting the MKV concept and its cost effective
    significance to GMD, MDA, DoD, congress, and
    the general public.
 
           
161 Which best describes your current  position within MKV?      
  "Technical support" refers to those directly involved in defining and implementing the technical development of the program -- e.g., those applying skills such as engineering, science, math, programming, program management, etc
  "Non-Technical " refers to program support services personnel -- such as contracting, human resources, Information systems, accounting, payroll, legal, security, clerical & administrative, etc.
   
162 Years of professional experience in this (or similar) position