copyright © 2006, systems and software consortium, inc. sos acquisition and management critical...
Post on 21-Dec-2015
213 views
TRANSCRIPT
Copyright © 2006, Systems and Software Consortium, Inc.www.systemsandsoftware.org
SOS Acquisition and Management
Critical Success Factors
SOS Acquisition and Management
Critical Success Factors
Richard [email protected]
Convocation 2006USC Center for Systems and Software EngineeringOctober 25, 2006
22
Copyright © 2006, Systems and Software Consortium, Inc.
The Systems and Software Consortium
The Systems and Software Consortium
Beyond Process Improvement. Impacting Member Growth.Beyond Process Improvement. Impacting Member Growth.
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
33
Copyright © 2006, Systems and Software Consortium, Inc.
Topical Taglines as Taxonomy Topical Taglines as Taxonomy
• “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…Pay me now or pay me later…
Planning for Change
55
Copyright © 2006, Systems and Software Consortium, Inc.
Acquisition StrategyAcquisition Strategy
• 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
66
Copyright © 2006, Systems and Software Consortium, Inc.
ContractingContracting
• 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
dime-ing 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
77
Copyright © 2006, Systems and Software Consortium, Inc.
Integration and ValidationIntegration and Validation
• Be mindful of sustainment issues– Maintenance costs >> development costs– Involve logistics and maintenance personnel early – they
are success-critical 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?
What’s My Line?
Roles
99
Copyright © 2006, Systems and Software Consortium, Inc.
Acquisition vs. DevelopmentAcquisition vs. Development
• 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
1010
Copyright © 2006, Systems and Software Consortium, Inc.
Management vs. Systems/Software Engineering
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?Who’s on first?
Communications
1212
Copyright © 2006, Systems and Software Consortium, Inc.
Supplier chain(s)Supplier chain(s)
• 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
1313
Copyright © 2006, Systems and Software Consortium, Inc.
Independent systemsIndependent systems
• 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
1414
Copyright © 2006, Systems and Software Consortium, Inc.
SoftwareSoftware
• 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?
Truth or Consequences?
Monitoring progress
1616
Copyright © 2006, Systems and Software Consortium, Inc.
MeasurementMeasurement
• 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
1717
Copyright © 2006, Systems and Software Consortium, Inc.
Insight Insight
• 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?
What, me worry?
Actively managing risks
1919
Copyright © 2006, Systems and Software Consortium, Inc.
Active Risk ManagementActive Risk Management
• 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
2020
Copyright © 2006, Systems and Software Consortium, Inc.
Compound RisksCompound Risks
• 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
2121
Copyright © 2006, Systems and Software Consortium, Inc.
Summary/Questions?Summary/Questions?
• 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