Peacock Programming, Inc.
|Project Number||Success Parameter||Challenged Parameter||Revenue/Loss (Millions $’s)|
Reynold Peacock, owners of Peacock Programming, Inc., knows that he faces a daunting task. With
several potential customer projects waiting to be accepted and limited resources at his disposal, some
difficult choices lay ahead. Though the agile programming strategies that his company has adopted have
greatly increased the success rate of software projects (see Exhibit 1), a large portion still fall short
(either partially or completely) of their stated goals.
Exhibit 1 – Comparison of Software Development Methods
After consulting with area experts within the organization, Peacock was able to generate a table of
probabilities and payoffs for the various options (see Appendix 1). A key factor in determining the
chance of success for each project is the number of programmers allocated to its development. Given
the Success Parameter (SP) and Challenged Parameter (CP) in Appendix 1 and the number of
programmer assigned to a project (N), the chance of a Success or Challenged completion are given by:
With 50 programmers employed by the company, where to apply their talents is a critical decision for
the short-run performance of Peacock Programming.
Though, the maximum number assigned to a project is only limited by the total number employed, a
long standing company policy has been to assign no fewer than five programmers to any project
initiated. Any programmers not assigned to a project can be utilized for various small projects, resulting
in $40k per programmer over the timeframe of these projects.
Assignment Questions for Part 1: What is the optimal set of projects to initiate and
number of programmers to allocate to each? What is the expected profit of this
With the projects selected and committed to, Peacock has had the chance to further analyze and
discuss the potential for success and the associated revenues. Two factors that he has learned seem
critical to determining the potential profits from these projects and he would like to be able to better
describe the potential outcomes.
First, the actual revenues for each case listed in Appendix 1 are not actually expected revenues, but
rather their “most likely” values. The actual revenue from each case can vary from these values and
seem to (at least approximately) follow a triangle distribution with maximum and minimum values
determined by the multipliers given in Appendix 2. For example, if the “most likely” revenue is $1.50M
and the maximum and minimum multipliers are 0.9 and 1.2, then the actual revenues will follow a
triangle distribution with L = 0.9(1.5) = $1.35M, H = 1.2(1.5) = $1.80M and M = $1.50M.
Exhibit 2 – Generating Random Values in the Triangle Distribution
Second, the final revenues are fairly predictable approximately 2/3 of the way through the
development project. At this point, the company can choose to terminate the project and reassign the
programmers to small projects. For complete failures, doing so would cut the loss by approximately
20%; for partial (“Challenged”) or complete successes, the forecasted revenue would be cut in half. In
any case, the reassigned programmer would each generate $10,000 in small projects.
L M H
# ! ! “!
$% & ‘”!
$% ( ‘”!
Where U is a random value from a Uniform distribution over [0,1]
and F(M) = (M – L)/(H – L).
Assignment Questions for Part 2: What is your estimated mean revenue for each
project with programmers allocated to it in Part 1 and in total*? What is estimated
standard deviation of revenue for each and in total*? What does the distribution of
revenue for each look like? Do not try to calculate these; use simulation instead.
* Note: assume that the project’s revenues are independent, so that the means and variances (not
standard deviations) are additive.
Bonus Question: Can you develop a simple method (i.e., a heuristic, not actually
resolving Part 1) utilizing the machinery above to make improvements in the
allocations to those projects with programmers assigned? Show your process even if
it tells you that no improvements may be made.