SOS Acquisition and
Management
Critical Success
Factors
www.systemsandsoftware.org
Richard Turner
turner@software.org
Convocation 2006
USC Center for Systems and
Software Engineering
October 25, 2006
Copyright © 2006, Systems and Software Consortium, Inc.
The Systems and Software Consortium
2
Founded to facilitate collaboration
among our members, who are
leaders in Federal/Commercial
marketplace
Focused on the challenges of
complex system and software
development
Committed to the business
performance of our members
Structured to provide “neutral
ground” and a voice for industry
Beyond Process Improvement. Impacting Member Growth.
Copyright © 2006, Systems and Software Consortium, Inc.
Topical Taglines as Taxonomy
3
•
•
•
•
•
“Pay me now or pay me later”
“What’s my line?”
“Who’s on first?”
“Truth or Consequences?”
“What, me worry?”
NB: Most of you are WAY too young to recognize these
Copyright © 2006, Systems and Software Consortium, Inc.
www.systemsandsoftware.org
Pay me now or
pay me later…
Planning for Change
Copyright © 2006, Systems and Software Consortium, Inc.
Acquisition Strategy
5
• Let the risks drive your strategy
– Use CTD to identify and remove/mitigate risk
– Don’t prejudice the solution
• Leave room for trades
– Negotiate requirements/capability levels
– Fight the “system” and get realistic cost/schedule estimates
• Think agilely
– Change is not bad – it is part of the job
– Use incremental/evolutionary approaches, don’t fake them
– Plan for achievable, deployable capabilities in 12 to 18
month cycles; internal capability demonstrations every 3
months; time-certain delivery
Copyright © 2006, Systems and Software Consortium, Inc.
Contracting
6
• Make sure the contracting vehicle matches the
acquisition strategy and the program risks/needs
– Fixed prices with evolving requirements break the bank
– May need multiple contracts rather than one all-inclusive
• Don’t hamstring your supplier
– Pay for good engineering (e.g. CM, IV&V); nickel and dimeing will alienate the supplier and cost more in the long run
• Define incentives that make sense and use them
– Use incentives to mitigate risks
– Base incentives on delivering capability, not documents
• Don’t let the Contacting Officer drive
– Find/recruit COs with a “let’s find a way” rather than a “no
way” attitude
Copyright © 2006, Systems and Software Consortium, Inc.
Integration and Validation
7
• Be mindful of sustainment issues
– Maintenance costs >> development costs
– Involve logistics and maintenance personnel early – they are successcritical stakeholders; plan for their roles/responsibilities
– Resolve conflicts between evolutionary acquisition and O&M
• Integrate and test early and continuously
–
–
–
–
Plan for the costs and availability of test/simulation facilities
Avoid dependence on specifications for integration
Plan along-the-way partial fielding and exercises where possible
Plan for multiple-baseline management where necessary
• Get OT&E involved early
– Promote ownership by funding participation
– Really listen to them when they do
Copyright © 2006, Systems and Software Consortium, Inc.
www.systemsandsoftware.org
What’s My
Line?
Roles
Copyright © 2006, Systems and Software Consortium, Inc.
Acquisition vs. Development
9
• Both the government and the Prime/LSI are essentially in
the acquisition business
– Most components supplied by others
– Most development done by others
• Don’t do the developer’s job
– Focus on coordination, contracting, integration
– Suppliers should be significant part of architecting
• Maintain the larger view
– Developers often manifest tunnel vision
– Acquirer’s have to understand and maintain the
operational and strategic context
Copyright © 2006, Systems and Software Consortium, Inc.
10
•
•
•
•
Management vs. Systems/Software
Engineering
All three disciplines are critical
Considerable overlap of functions
Encourage (force?) them to play well with each other
Balance their influence and authority according to
program phases and risks
Copyright © 2006, Systems and Software Consortium, Inc.
www.systemsandsoftware.org
Who’s on first?
Communications
Copyright © 2006, Systems and Software Consortium, Inc.
Supplier chain(s)
12
• Communication and coordination up and down deep
supplier chains is difficult but critical
– Make sure schedules include sufficient time to propagate
changes, concerns, risks, problems
– Efficient change management is also key
• Coordination between multiple system supplier chains is
nearly impossible
• Standards are essential; ensure they are interpreted
consistently
Copyright © 2006, Systems and Software Consortium, Inc.
Independent systems
13
• Change happens – flexibility is a critical attribute
• Beware Independent as opposed to Integrated Product
Teams
• Maintain C4ISR attitude
– Command and Control where you can – flatter, cajole,
plead, manipulate where you can’t
– Intelligence, Surveillance, and Reconnaissance of separately
evolving systems is critical
Copyright © 2006, Systems and Software Consortium, Inc.
Software
14
• The worm has turned – software is the critical driver
– Balancing attributes (safety, security, performance) within
and between software and system is difficult and must be
managed; critical area for requirement trades
• Ensure that software is part of all decisionmaking and
trade analyses
– Early, front end decisions are critical to the success of the
software development
• Increase profit motive for quality, on-schedule software
– Beware incentivising mediocrity because the profit is all in
the hardware or sustainment
• Caveat Emptor – COTS is (often) NOT the answer
Copyright © 2006, Systems and Software Consortium, Inc.
www.systemsandsoftware.org
Truth or
Consequences?
Monitoring progress
Copyright © 2006, Systems and Software Consortium, Inc.
Measurement
16
• Measure based on risk
– Establish core metrics for the acquisition; development
measures are necessary but not sufficient
– Don’t watch/require low-level metrics unless there is a
problem
• Be careful of precision versus accuracy
• Make sure you use the measures you request
– If they aren’t input in making decisions, don’t pay for them
• Beware of EVM in software-intensive systems
– Difficult to do well; usually a waste of time
– Tracking operational functions/capabilities is a better
measure
Copyright © 2006, Systems and Software Consortium, Inc.
Insight
17
• Big reviews (PDR/CDR) are (pretty much) worthless
– 500 of your closest friends watching 1,000 viewgraphs is
expensive and of no obvious value
• Concentrate on demonstrating operational capabilities
– Better and easier to evaluate than documents
– Feedback is much richer
• Use Independent Expert Reviews to gain insight
– Cross-discipline team without bias (sometimes difficult)
– Helps maintain the broad view
Copyright © 2006, Systems and Software Consortium, Inc.
www.systemsandsoftware.org
What, me
worry?
Actively managing risks
Copyright © 2006, Systems and Software Consortium, Inc.
Active Risk Management
19
• Beware the risk bureaucracy
– Risk tools are great but can be very slow
– Risk aversion is the 8th deadly sin
• Develop mechanisms to avoid “risk admiration”
– Don’t simply track mitigations; evaluate their effectiveness
upon completion
– Constantly question mitigation strategies
– Don’t call existing problems risks – handle problems
outside the risk tool
• Manage risk at every level
– Continuously scan for new risks
– Quickly migrate risks identified or with increasing
probability of occurrence
Copyright © 2006, Systems and Software Consortium, Inc.
Compound Risks
20
• Exist across systems
–
–
–
–
Closely coupled tasks with one or both high risk
Separately evolving but dependent technologies
Incompatible standard interpretations
Inconsistent/inflexible contracted requirements
• Compound risks are pernicious
– Difficult to detect
– Are often architecture, budget and/or schedule breakers
• Must be addressed hierarchically
– Intentional system-level de-coupling of risks for reduced
exposure
– Each level must scan across its components to identify
Copyright © 2006, Systems and Software Consortium, Inc.
Summary/Questions?
21
• Acquisition and management issues are legion and wicked
• You will live and die by your contract vehicles
• Systems engineering, software engineering and engineering
management are closely coupled - balance their influence
based on risks
• Streamline processes wherever possible
• Eliminate death-by-viewgraph reviews for the masses
• Mitigate personnel burnout with agile approaches
• Plan performance measures and incentives carefully
• Don’t trust measures alone – use outside assessments
Copyright © 2006, Systems and Software Consortium, Inc.