copyright © 2006, systems and software consortium, inc. sos acquisition and management critical...

21
Copyright © 2006, Systems and Software Consortiu www.systemsandsoftware.org SOS Acquisition and Management Critical Success Factors Richard Turner [email protected] Convocation 2006 USC Center for Systems and Software Engineering October 25, 2006

Post on 21-Dec-2015

213 views

Category:

Documents


0 download

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