1. 4/26/2010
SOFTWARE
PROCUREMENT:
COORDINATION AND
DOD CONTRACTS
Lauren L. Calhoun
ISYE 6230Q
26 Apr 10
Outline
 Motivation
 Software Project Management
 Game Theory Application
 Quantitative Analysis
 Qualitative Analysis
 Author’s Conclusions
 Professional Experience
p
 Requirements Development Process
 Achieving Coordination
 Conclusions
1

2. 4/26/2010
Motivation
 Even if you’ve never typed a line of code…you
may be involved in a software procurement
effort.
 Examples of Large Programs…related to ISYE:
 FederalAviation Administration – Air Traffic
Mgmt System
 Sainsbury’s Grocery – Supply Chain Mgmt
System
 Kmart Corporation – Integration of Sales,
Marketing, Supply Chain and Logistics
Software Project Management
 Enterprise firm seeks to start new IT project
I
Investing
ti in software t l makes i
i ft tool k improvements t
that increase revenue to enterprise
 Assumes enterprise doesn’t have the skills to
develop software internally
 Developer selected through a bid process, after
enterprise publishes request for proposals
2

3. 4/26/2010
 Software developer bids for work
A
Assesses technical risk b d on requirements set
t h i l i k based i t t
forth in request for proposal
 Assumes that the developer has organic capability
to meet the need
Game Theory Application
 “Analysis on Enterprise's Software Project
Management Based on Game Theory”
Theory
 Provides analysis for how game theory can
model this situation and lead to “dual win” for
enterprise and developer
3

4. 4/26/2010
Quantitative Analysis
 Players: 1. Enterprise, 2. Developer
 Dynamic Game, Perfect Information
 First Stage: Enterprise starts project based on
need/anticipated revenue from implementation
 Invests $x to analyze requirements
 Solicits bids based on ability to meet enterprise requirements
 Second Stage: Developer wins contract
 Developer succeeds OR
 Developer fails to meet contract requirements
 Third Stage: If developer does not satisfactorily complete
the software (fails):
 Developer defaults on contract and gives up effort OR
 Developer and enterprise work to rebuild program with
additional investment/cost
Notation
 Rq = Revenue Generated by Software
Implementation for Enterprise
 c = Enterprise’s Cost of Purchasing Software
 c1 = Cost of incomplete development (c1< c)
 x = Amount Invested to Determine Requirements
 x1 = Additional enterprise investment to rebuild (x1>0)
 e = Developer’s Cost of Production
 e1 = Additional developer cost to rebuild (e1>0)
 δ = Discount factor for subsequent phases
4

5. 4/26/2010
 Payoffs (Enterprise, Developer):
 If enterprise d
t i does not start d l
t t t development: ( )
t (0,0)
 If enterprise seeks development and it succeeds:
(Rq-c-x, c-e)
 If enterprise seeks development, developer fails
and rebuilds: (Rq-c-x-x1, c-e-e1)
 If enterprise seeks d
t i k development, d l
l t developer f il
fails
and developer gives up: (-c1-x, c1-e)
 Author’s Conclusion:
Giving Up in Phase 3
is strictly dominated
by Rebuilding and
Succeeding.
 Enterprise’s
revenue is zero, so
profit for the
enterprise is
negative.
 De eloper’s
Developer’s
income is also less
than in the other
two strategies
because c1<c.
5

6. 4/26/2010
 Equilibrium revealed by backward induction.
 Comparing Ph
C i Phase 2 SStrategy (S
(Succeed) with
d) i h
remaining Phase 3 Strategy (Rebuild):
 Enterprise: (Rq-c-x)≥δ(Rq-c-x-x1) for δ<(Rq-c-x)/
(Rq-c-x-x1)
 Developer: (c-e)≥δ(c-e-e1) for δ<(c-e)/(c-e-e1)
SSuccess yields greater pay-off for b h
i ld ff f both.
 Comparing Phase 1 Strategies to either start or not
start the development:
 Enterprise: δ(Rq-c-x)≥δ2 (Rq-c-x-x1)≥0 for δ<(Rq-c-x)/
(Rq-c-x-x1)
 Developer: δ(c-e)≥δ2(c-e-e1)≥0 for δ<(c-e)/(c-e-e1)
 Starting the development, then succeeding in Phase 2
yields highest pay-off.
 Maximum profit for both is achieved when they
cooperate and deliver the successful software
program in Phase 2.
6

7. 4/26/2010
Qualitative Analysis
 To achieve low risk, successful outcome:
E t
Enterprise
i must h
t have clear goals, and well d fi d
l l d ll defined
requirements
 Developer must be forthright about capability
when bidding
Software Developer
Correct Incorrect
Enterprise
Solution/Product Solution/Product
(Low Risk/Successful, (High Risk/Unsuccessful,
Clear Goal/Reqs Low Risk/Successful) Temporary Success/Fail)
(High Risk/Successful, (High Risk/Unsuccessful,
Unclear Goal/Reqs High Risk/Successful) High Risk/Unsuccessful)
Author’s Conclusions
 Key: Win-Win only achieved if both clearly reveal
capability and need.
p y
 Feasibility:
 Enterprise: Objective judgment of project feasibility,
realistic expectation of revenue
 Developer: Objective judgment of ability to meet
technical requirements, realistic expectation of cost
 Communication:
 Consistent, clear, ability to manage expectations
C i t t l bilit t t ti
 Information Asymmetry:
 Enterprise: May conceal management problems that led
to weak requirements/goal setting
 Developer: May misjudge complexity/cost of project
7

8. 4/26/2010
Professional Experience
 Project Manager for US Air Force
 Software Development program is an upgrade
to a legacy system – different developer and
operating system.
 Purpose: Schedules user requested Dept of
Defense (DoD) satellite contacts
 10
0ground site locations
g o o o
 Hundreds of contacts daily.
 Users: DoD Units, Government Agencies,
Research Agencies
 Current contract has several failed preceding
efforts
 Multipledevelopers
 Canceled for feasibility/cost overruns
 Current contract nearly doubled in cost and
schedule, with reduction in requirements
 Produces less utility to user (
y (Revenue)
)
 Current contractor is working with second
subcontractor on this effort after previous
failed subcontract effort
8

9. 4/26/2010
Requirements Development
 Multiple stakeholders provide inputs – users,
headquarters,
headquarters program managers
 Often influenced by non-technical users who ask
for too many “nice to haves”
 Software requirements are by nature dynamic
 Captures ever changing technology shifts
 Rigorous documentation to flow system level
g y
requirements to functional coding, but…
 …investments in requirements development
upfront directly correlates to outcome.
Illustrates influences on requirements
(difficult to achieve stability/please everyone):
External Users/Systems Contract Parties
Prime
Subcontractor
Contractor
Existing AFSCN Systems
Stakeholders
AF S
Space
Command/A5
(Requirements)
Satellite Control and
Network Systems Group
(Acquisition)
22 SOPS
(Operations)
9

10. 4/26/2010
Achieving Coordination
 Cost Plus Contracts: Allow contractor to bill government for costs of
development. Profit either fixed or percentage of cost.
 In terms of model, cost to develop (e) never exceeds revenue to
Developer (c)
 Fixed Cost Contracts: Cost overruns would be paid for out of
developer’s profits. Worse case developer works for no profit, and
defaults on contract.
 Cost Plus Incentive Fee Contract: In addition to covering costs, offers
fee amounts as additional revenue to incentivize outcomes.
 Rewards developer for meeting key technical/schedule milestones
 Feedback mechanism from government program office to
contractor, in the form of money/written reports
 Increases Developer revenue (c) by fee amounts earned, and while
this cost to Enterprise increases, in theory the utility of
implementation (Rq) increases.
Conclusions
 Recall motivation:
 Federal Aviation Administration – Air Traffic Mgmt
System
 $50B cost in air traffic delays; Cost/schedule overruns due
in part to ill defined requirements
 Sainsbury’s Grocery – Supply Chain Mgmt System
 $526M invested; Glitches in delivered program led to 3000
employees hired to manually correct backlogs
 Kmart Corporation – Integration of Sales, Marketing,
Supply Chain and Logistics
 $1.4B spent; Implementation revenue overestimated
10

11. 4/26/2010
 Requirements stability and feasibility key to
achieving program success
 Can utilize game theory model to examine
impact of revenue, cost, and requirements
development on program success
 Optimal Outcome – get it right the first time
 Realistic Outcome – iterative process, requires
contractual mechanisms to maintain flexibility
and requirements stability
11