4/26/2010

1

SOFTWARE PROCUREMENT:COORDINATION AND DOD CONTRACTSLauren L. Calhoun

ISYE 6230Q

26 Apr 10

Outline

Motivation Software Project Management Software Project Management Game Theory Application

Quantitative Analysis Qualitative Analysis Author’s Conclusions

Professional Experiencep Requirements Development Process Achieving Coordination

Conclusions

4/26/2010

2

Motivation

Even if you’ve never typed a line of code…you may be involved in a software procurement may be involved in a software procurement effort.

Examples of Large Programs…related to ISYE: Federal Aviation 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 projectI ti i ft t l k i t Investing in software tool makes improvements 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 proposalsenterprise publishes request for proposals

4/26/2010

3

Software developer bids for workA t h i l i k b d i t t Assesses technical risk based on requirements set 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”Management Based on Game Theory

Provides analysis for how game theory can model this situation and lead to “dual win” for enterprise and developer

4/26/2010

4

Quantitative Analysis

Players: 1. Enterprise, 2. Developer Dynamic Game, Perfect Information 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 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 EnterpriseImplementation 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/26/2010

5

Payoffs (Enterprise, Developer):If t i d t t t d l t ( ) If enterprise does not start development: (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 t i k d l t d l f il If enterprise seeks development, developer fails and developer gives up: (-c1-x, c1-e)

Author’s Conclusion: Giving Up in Phase 3 is strictly dominated 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.

4/26/2010

6

Equilibrium revealed by backward induction.

C i Ph S (S d) i h Comparing Phase 2 Strategy (Succeed) with 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)

S i ld ff f b h Success yields greater pay-off for both.

Comparing Phase 1 Strategies to either start or not start the development: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.

4/26/2010

7

Qualitative Analysis

To achieve low risk, successful outcome:E t i t h l l d ll d fi d Enterprise must have clear goals, and well defined requirements

Developer must be forthright about capability when bidding

Enterprise

Software Developer

Correct Incorrect Enterprise

Solution/Product Solution/Product

Clear Goal/Reqs(Low Risk/Successful,Low Risk/Successful)

(High Risk/Unsuccessful,Temporary Success/Fail)

Unclear Goal/Reqs(High Risk/Successful,High Risk/Successful)

(High Risk/Unsuccessful,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:

C i t t l bilit t t ti Consistent, clear, ability to manage expectations Information Asymmetry:

Enterprise: May conceal management problems that led to weak requirements/goal setting

Developer: May misjudge complexity/cost of project

4/26/2010

8

Professional Experience

Project Manager for US Air Force Software Development program is an upgrade 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 ground site locations0 g o o o Hundreds of contacts daily.

Users: DoD Units, Government Agencies, Research Agencies

Current contract has several failed preceding effortsefforts Multiple developers Canceled for feasibility/cost overruns

Current contract nearly doubled in cost and schedule, with reduction in requirements Produces less utility to user (Revenue)y ( )

Current contractor is working with second subcontractor on this effort after previous failed subcontract effort

4/26/2010

9

Requirements Development

Multiple stakeholders provide inputs – users, headquarters program managersheadquarters, 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 yrequirements to functional coding, but…

…investments in requirements development upfront directly correlates to outcome.

Illustrates influences on requirements

(difficult to achieve stability/please everyone):

AF S

Contract PartiesPrime

ContractorPrime

ContractorSubcontractorSubcontractor

External Users/Systems

Stakeholders

Existing AFSCN Systems

(difficult to achieve stability/please everyone):

AF Space Command/A5

(Requirements)

22 SOPS(Operations)

Satellite Control and Network Systems Group

(Acquisition)

4/26/2010

10

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.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 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 backlogsemployees hired to manually correct backlogs

Kmart Corporation – Integration of Sales, Marketing, Supply Chain and Logistics $1.4B spent; Implementation revenue overestimated

4/26/2010

11

Requirements stability and feasibility key to achieving program successachieving 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