DB#9 & DB#10.docx· · · · · · · · · DB#9 Cost.docx

DB#9 & DB#10.docx
·
·
·
·
·
·
·
·
· DB#9: Cost Management
·
· Many project managers ask the question "Why do I have to
do earned value management?". Kuehn (2007) states that the
reason why is that it works... if it is done well. After reading
the chapter and Kuehn's paper, what do you think are the
biggest hurdles project managers face when trying to
successfully use earned value management techniques?
Reference: Kuehn, U. (2007). Earned value management -
Why am I being forced to do it? AACE International
Transactions, EV5.1-5.11.
DB#10: Problems with IT Cost Estimates
Per the text, four of the main reasons behind inaccurate cost

estimates are 1) Estimates are done too quickly, 2) People lack
estimating experience, 3) Human beings are biased toward
underestimation, and 4) Management desires accuracy
(Schwalbe, 2016). Given today's tough economic client and the
trends you see in business and government, which of these four
causes do you think are the most significant? Describe one way
that a good project manager can help overcome that most
significant factor. Reference Schwalbe, K. (2016).
Information Technology Project Management (8th Edition).
Boston, MA: Course Technology. ISBN: 978-1-128-45234-0
Discussion Boards Rules:
Each week of the Management in IT course features mandatory
Discussion Board participation. Learners are required to post a
200-400 word, grammatically correct entry on the topic
presented. At least one scholarly reference - such as the course
text or peer-reviewed journal articles - should be cited in APA
format in each week's post (some exceptions are noted in the
discussion instructions). In addition, each week you are
required to post a response to at least two other students’ initial
post. These response posts must be substantial, not simply
“Great post!”, and should offer comments, questions, or
suggestions to promote further discussion. Initial posts are due
by the end of Tuesday of each week. Response posts are due by
the end of Friday of each week. Rubrics are presented with each
discussion to provide clarity on the grading criteria.
DUE TUESDAY OCTOBER 04TH @11PM

Earned Value Management - Why Am I Being Forced to Do
It(1).pdf
T
o many, earned value management seems to be a
recent requirement, but the technique has been
around for a long time. The original techniques were
conceived back in the early 1960s during the
Minuteman Missile Development Program, back when most of
the other, currently used, project management techniques were
developed. But why, you may ask, if it hasn’t caught on for all
of those years, is it being forced on me now?
The answer: If implemented properly, it really works!
Any project plan is similar to a flight plan that the pilot of an
airplane must submit before the flight. The pilot charts a course
that points to the destination of the flight. If you ask a pilot how
often he or she is exactly on the flight plan they will likely tell
you that they are on the plan at take-off and at landing, and then
they might happen to fly through it. Yet, they all seem to be
able
to fly to their destination with very few problems.
If the plane is not exactly on the flight plan, the pilot can usu-
ally steer the plane back. If not, the charts are brought out to
develop a new flight plan. Hovering close to the flight plan is
what allows the plane to reach its destination.
In project management, it’s not being exactly on the baseline
of the plan that counts - it’s that you can steer the project team
back toward the baseline. Using the tools and techniques of

earned value management allows the project team to identify
“control areas” around the baseline (like flight control lanes for
a pilot) both on the positive side and on the negative side that
the project status should stay in to be successful.
Borrowing from Quentin Fleming’s selection of the top ten
criteria? of the 32 criteria required to be ANSI/EIA-748-A com-
pliant that he believes will get any project to be using earned
value management techniques, let’s see how it works.
STEP 1—DEFINE THE PROJECT SCOPE VIA
A WORK BREAKDOWN STRUCTURE
To define the scope of the project’s deliverable, decisions
must be made about whether or not a deliverable or service will
meet the customer’s need and still fit within their budget. These
decisions should be based on the answers to such questions as:
• Does the customer need it?
• Does the customer want it?
• Will it benefit the customer to have it?
• Can the customer afford it?
• Do other stakeholders need or want it?
• Will it benefit other stakeholders?
• Will it enable the project to be executed more efficiently?
The answers to these and other fundamental questions allow
the project manager to truly focus this decision-making process
regarding “what” is in the scope of the project on true objec-
tives.
The most important tool of this process is the deliverable-ori-
ented work breakdown structure (WBS). The decomposition of
the scope is what forms the deliverable-oriented WBS into an
architectural breakdown of that product or service.

The central focus of a deliverable-oriented WBS is the over-
all deliverable of the project. For example, if you are construct-
ing a building, then the top block of the WBS would be the
building. If you are developing software, then the top block
would be the major function the software will perform for the
customer. My favorite example is building a pond in my yard,
where my top block would be “Ursula’s pond.” I would have to
develop a business case of sorts to justify why I need a pond. I
certainly would have to manage the pond. I know I’ll have to
design the pond and test the pond, but the rest of my sub-deliv-
erables are going to be the major parts of the pond.
To start my decomposition, I would need to perform a
requirements analysis. This is a process in itself where the proj-
ect as a whole and each part of the project are scrutinized to
make sure that they meet the need of the customer or stakehold-
er and, also, that the part fits into the budget. This analysis is
like “peeling an onion.” Through the analysis, the parts of the
scope are identified. Then through a structured tool of docu-
menting this decomposition of the scope (the WBS), the
requirements analysis can be focused down the structure to
each individual part.
Let’s see how the WBS can help me plan my pond. Let’s say
that I would like to complete the entire pond in a weekend. If I
were to use a task-oriented WBS, i.e., breaking down the proj-
ect into the tasks of design the pond, build the pond, and test
the pond, I can almost guarantee that I will not be able to com-
plete the project in a weekend. It is very difficult to identify all
the work - that is, anything that might take time - of the project
using this type of WBS. If I don’t identify all the work that
might
take time, I will not be able to plan for it in my schedule and by
the time it becomes obvious to me that that additional work will
need to be done, it will be too late.

2007 AACE International Transactions
EVM.05
Earned Value Management -
Why Am I Being Forced to Do It?
Ursula Kuehn, EVP
EVM.05.1
EVM.05.2
By doing a requirements analysis, I can identify the major
parts of the pond, such as a hole to place the pond in, a liner,
and water. Note that if a requirement for this project was to not
break the ground surface, then the basic major parts of the WBS
might be a plastic tub and water. The output of what is deter-
mined by my requirements analysis is the input to my deliver-
able breakdown, which in turn allows me to decide what goes
into the scope of the project and what does not.
For this example, let’s say that the basic requirements of my
pond are a hole, a liner, and water, plus some livestock and
some attractive plants. Our structure might look like the top-
level structure shown in figure 1.
There could have been several more major parts to my pond,
like a stone border, a water treatment, or external landscaping.
There also could be many logistical deliverables that relate to
the pond as a whole, such as training (possibly broken down

into
operation and maintenance), equipment needed to maintain
the pond, user documentation, supplies, etc. These decisions
are made based on the requirements and the budget.
The requirements analysis can now be focused on each of the
individual major parts of the project. Let’s take “hole” as an
example. What is required to have a hole? The basic two func-
tions that need to take place are to remove earth from the
ground and to dispose of the earth. We could look at each of
these functions as a sub-project in itself: “remove earth” and
“dispose of earth.”
Performing a requirements analysis on the sub-project “earth
removal” might include a requirement to study the geological
drawings of the area where the earth is to be removed. This
study would further define whether a backhoe or just shovels
will be needed, or maybe even dynamite, depending on the
matter to be removed. In other words, this study is part of the
requirements analysis but might never been identified as work
that would take time if we had not analyzed this part of the
WBS. This geological study may also identify other required
deliverables, like an environmental study.
A study to locate any utility lines, as well as many other time-
consuming activities, might need to be performed before any
earth is removed from the ground. But that is the whole point of
the WBS - it is the tool that helps identify anything that might
take time in the project, and since that time usually translates
into money, it helps determine if we really can afford to do the
project within our budget.
“Earth disposal” might be another sub-project. For example, a
decision may be to use the earth taken out of the ground to
build a garden in another part of the yard. This sub-project

would require its own breakdown of major parts.
Let’s take a look, in figure 2, at what the WBS of the hole
might look like.
Notice that the lines under sub-deliverable “hole” and the
two sub-projects extend further than what we’ve identified.
That’s because work packages, in this example those actions
that
need to be undertaken to remove the earth or dispose of the
earth, have yet to be added to our WBS. Work packages are the
lowest level of any branch of the WBS where resources will be
assigned responsibility. Let’s take a look at what types of
actions
or work packages can be identified so far in our structure.
Figure 1—High-Level Breakdown of Ursula’s Pond
Figure 2—WBS of Hole
The pond, as a whole, will need to be designed. This design
of the pond will probably be a drawing of what the entire pond
should look like once it is completed. The drawing should show
each of the major parts of the pond that we decide will be part
of the scope. Keep in mind that this work package can be bro-
ken down further into individual tasks, such as conducting a site
survey, developing a drawing, and having the drawing reviewed
and approved by the customer. You could almost say that this is
a project in itself.
The pond will need to be tested. Maybe this will involve noth-
ing more than an inspection that will take too small an amount
of time to track on the project, but it will take time nonetheless.
In other projects, a test might be further broken down into such

work packages as developing a test plan, identifying various
test
scenarios, performing the tests, writing the test reports, etc.,
each of which could be broken down further.
Now let’s take a look at the hole for the pond. The hole will
need it own design. This design is different from the pond
design because the hole needs a drawing that shows how long it
should be, how wide it should be, how deep it should be, and
where the shelves to hold those plants that need water but do
not like being at the bottom of the pond (“bog plants” needed
for filtration) should be constructed. A test will have to be con-
ducted to make sure the hole will hold the plants properly. This
test will take time and that time needs to be included in the
project plan, especially if you want the project completed over
a limited period of time, like a weekend.
The method for removing the earth has to be determined. An
environmental assessment may need to be performed before
any earth is removed. Do we need to buy a shovel, rent a back-
hoe, acquire some dynamite? If we build a garden with the
removed earth, then the garden will need to be designed, and so
on.
Now let’s look at the sub-deliverable “water.” The following
three major functions have to take place to have water in the
pond (which are very similar to any project that must deliver an
information system, often referred to as an information technol-
ogy, or IT, project).
• water has to get into the pond (input of information);
• water has to circulate (processing and storage of information);
and
• at times water has to be drained from the pond (distribution

of information), as displayed in figure 3.
Each of these can functions can be a sub-project. For exam-
ple, “water in” could mean an entire plumbing system that
pumps water from a water source to the pond. Often a land-
scape artist who specializes in ponds will contract this out to
someone who specializes in plumbing systems. The details of
this plumbing system should be broken down by someone who
is familiar with all the requirements of this kind of system.
Water circulating would require a pump, which in turn
requires electricity, which might be another sub-project where a
certified electrician might be needed to run a new electrical
line from the power source of the house to the area of the pond
for the pump to plug or tap into. A water treatment or waterfall
that might be one of the major components of the pond would
need to interface with this pump via a hose or tubing that would
have to be purchased. This water treatment may require a more
powerful pump. Filters for the pump will be required. In other
words, the circulation of water is a project in itself.
Water draining might also require an environmental study,
depending on how and where the water is to be drained. An
actual drain might need to be buried, which would change the
requirements of the sub-project for earth removal.
Again, the work of each of these identified sub-projects and
components takes effort that will cost money and will take time.
Accordingly, decisions about whether or not to include these
sub-projects and components in the scope of the project need to
be made before any of this work can be planned. I’m not sure
who first said it, but you can’t plan what you don’t know. The
WBS is the tool that helps us figure it all out - or at least as
much
of it as we can.

STEP —DETERMINE WHO WILL PERFORM THE
WORK AND WHAT IT MIGHT COST
For our example, let’s say our resources and materials choices
are as displayed in figure-4 and after the requirements analysis,
WBS, and these estimates are identified, the roll-up is as shown
in figure 5. Now let’s say the customer’s budget is $1,500. As
you can see, the plan is already over-budget. Either the budget
must be raised to afford all of this scope or the parts of the pond
must be eliminated or acquired at a lower cost.
This balance of scope to budget must take place before the
work identification is complete. If we were to go forward with-
out balancing the scope, the earned value analysis will do noth-
ing more than show us that we are over-budget at some point in
time during the project. The balance of the “triple constraint,”
i.e., the scope to the budget to the time, is crucial for earned
value management to be properly implemented.
STEP 3—PLAN AND SCHEDULE THE DEFINED
WORK FOR THE AGREED UPON SCOPE
Once we know the work that will produce the agreed upon
scope, we must now schedule that work using the standard
scheduling techniques?.
EVM.05.3
Figure 3—Breakdown of Water Sub-Deliverable
EVM.05.4

Figure 4—Resource and Material Estimates
Figure 5—Estimated Costs Rolled Up the WBS
STEP 4—DETERMINE POINTS OF
MANAGEMENT CONTROL
The level of the WBS above the work packages is commonly
referred to as the control account. In our example shown in fig-
ure 5, we form control accounts at the hole, at the liner, at the
water, at each of the plants, etc. This would allow us to collect
planned, earned, and actual data that can be analyzed to deter-
mine where problems are “cropping up” and to do something
about the problem before it erodes the project as a whole.
STEP 5—AUTHORIZE BUDGETS
FOR THE BASELINED PLAN
Once we have agreement on the scope, the estimates of the
costs, and the scheduling of our plan, i.e., a balanced triple con-
straint, we lock the costs and time estimates in, and turn them
into budgets for each work package. This is where the term
“budgeted cost of work” starts. Figure 6 shows the budgeted
work in a precedence diagram.
Now that the budgets are allocated and the schedule is base-
lined, what is called a performance measurement baseline (our
flight plan) can be developed, figure 7, by graphing what we
plan to spend over time.
As can been seen in our example, the performance measure-

ment baseline (PMB) is an accumulation of the individual
budgets of each work package over time. The final data point on
the PMB chart is the cumulative sum of the budgets of all the
work packages in the project. This data point is called the budg-
et at completion (BAC) and will be a data point that we will use
in our earned value analysis.
EVM.05.5
Figure 6—Budget Allocated to the Work Packages
Figure 7—The Performance Measurement Baseline
EVM.05.6
STEP 6—DEFINE METRICS TO MEASURE
PERFORMANCE OF WORK
WITHIN EACH CONTROL POINT
Essentially, calculating earned value of each work package is
a simple multiplication of the percent complete of the work
package, times the budget that we allocated for that work pack-
age. To determine that percent complete we need to pre-deter-
mine how we will measure the work package. The most com-
mon techniques are the following:
• effort/(effort + remaining);
• physical percentage complete;
• weighted milestones or inchstones; and

• 50/50 rule, 20/80 rule, 0/100 rule.
An example of effort/(effort + remaining) is when we original-
ly thought a work package would take us 80 hours worth of
work
and we allocated budget based on that estimate. The team
working on the work package have expended 40 hours and they
estimate that they will need another 60 hours to complete it.
That means our percent complete will be 40/100 or 40 percent
complete.
Physical percentage complete is based on a physical deliver-
able and what percent complete that deliverable exhibits. In
order to not be subjective, this type of measurement usually
requires identification of physical metrics that can be counted,
such as lines of code, components installed, etc.
When physical metrics can not be determined, another
method is to break the work package into lower level milestones
or inchstones and identify a weighted percent complete for
Figure 8—Baseline Schedule Showing Status Dat
Figure 9—PMB with Planned Value as of Day 10 Displayed
each, the total of which would equal 100 percent for the entire
work package.
When there is no metric available, a decision can be made to
use a “rule” that designates the work package as 50 percent
com-
plete at the time of actual start and the work package stays at 50
percent complete until an actual finish is recognized, at which
time the remaining 50 percent is granted for a total of 100 per-

cent of the work package – the 50/50 rule. The 20/80 rule
grants 20 percent at the actual start with the remaining 80 per-
cent granted at the actual finish of the work package. The 0/100
rule grants nothing until the work package is 100 percent com-
plete.
STEP 7—RECORD ACTUAL COSTS OF THE WORK
Recording actual costs for each work package, or even at the
control account level, is the challenge of an earned value man-
agement system. To many the idea of recording time or costs at
the lower levels of the WBS equates to “bean counting.” In
order for this criteria to be accomplished each team member
must enter their time on a timesheet, which is foreign and even
intrusive to many people. This stems from the lack of under-
standing of the value of completing this task on a regular basis.
This is where the “leadership” ability of the project manager is
called upon.
The actual cost (AC) is also known as the actual cost of work
performed (ACWP.)
STEP 8—MEASURE PERFORMANCE AND
DETERMINE PROJECT PERFORMANCE
Like the flight plan, the baseline sets up a guidance system for
the project. The baseline aids in directing the project execution
to the ultimate goal of accomplishing all the work on time and
within budget. Just as for the pilot, the idea is not to be precise-
ly on the baseline, but to be able to hover around the baseline.
To do this, we need to know where the baseline is.
The planned value (PV), also known as the budgeted cost of
work scheduled (BCWS), is the point on the baseline where the
line representing the date that status will be reported intersects
the baseline. This line is often referred to as a data date or sta-

tus date. The PV (BCWS) represents the portion of the budget
we expected to spend as of the status date if all work is accom-
plished exactly as we planned. Figure 8 shows how the PV is
determined for day 10 using our previous baseline example.
Task A is planned to be completed by day 10, so all of Task A’s
budget will be in the PV. Task B is planned to be 50 percent
complete by day 10, so 50 percent of Task B’s budget will be in
the PV. Task C is planned to be completed by day 10, so all of
Task C’s budget will be in the PV. Finally, Task D is planned to
have four days of its nine-day duration completed by day 10, so
4/9 of Task D’s budget will be in the PV. Table 1 shows the PV
for this project as of day 10.
The project PV can also be displayed using the PMB, as
shown in figure 9.
Remember, the basic formula for calculating the earned
value (EV), also known as the budgeted cost of work performed
(BCWP) is:
Table 2 demonstrates earned value data for our example.
To perform earned value analysis, we need to have collected
PV, AC, and EV, plus BAC (Figure 10 shows the cumulative
data graphed on the PMB.)
Variances are simple calculations that tell us whether the
project is ahead or behind schedule by calculating the schedule
variance (SV) and whether the project is showing signs of going
over or under budget by calculating the cost variance (CV). The
formulas for these two variance indicators are:
EVM.05.7

Table 1—Sample Calculation of Planned Value as of Day 10
Table 2—Sample Calculation of Earned Value as of Day 10
EVM.05.8
SV = EV - PV
CV = EV - AC
In both calculations a positive or negative result equates to the
status shown in table 3.
Figure 11 shows how the variances can be identified using the
PMB.
While variances are nice to know, they are not useful for com-
paring the performance of one project to another, nor can they
be used to isolate issues within a project, since they are not rel-
ative to the size of what’s being analyzed. For a relative indica-
tion of performance we would want to calculate the perform-
ance indexes.
The performance indexes calculate performance relative to a
unit, such as a dollar or an hour of effort. Here we calculate the
schedule performance index (SPI) to determine the perform-
ance for every dollar (or whatever unit of currency or effort is
being used in the analysis) scheduled to be spent according to
the baselined plan. The cost performance index (CPI) tells us
the performance for every dollar that has been spent at this time
in the project. The formulas for these indexes are:

Figure 10—PMB with Earned Value Analysis Data as of Day 10
Displayed
Table 3—Variance Status Results
Figure 11—PMB Showing Earned Value Analysis Variance
EV
SPI = --------
PV
EV
CPI = --------
AC
Let’s look at an example:
PV = $45,000
EV = $35,000
AC = $40,000
SV = -$10,000
CV = -$5,000
SPI = 0.78
CPI = 0.86
The SV and the CV, both negative, tell us that the project is
behind schedule and over budget. The SPI tells us that for every
dollar we planned to spend on this project, we are getting 78
cents worth of performance. The CPI is telling us that for every
dollar we have spent so far on this project, we are getting 86
cents worth of performance. If our tolerance is +10 percent, we
would expect either performance indicator to be between 0.90

and 1.10 to be in control. Since neither is within the thresholds
of our control area, we can say our project is out of control,
both
in terms of schedule and cost.
Let’s look at a similar example:
PV = $145,000
EV = $135,000
AC = $140,000
SV = -$10,000
CV = -$5,000
SPI = 0.93
CPI = 0.96
The SV and the CV are exactly the same as in the previous
example and only tell us that the project is behind schedule and
over budget. The SPI tells us that for every dollar we planned to
spend on this project, we are getting 93 cents worth of perform-
ance. The CPI is telling us that for every dollar we have spent
so far on this project, we are getting 96 cents worth of perform-
ance. With a tolerance of +10 figure, both are within the thresh-
olds of our control area, so we can say this project is in control
both in terms of schedule and cost.
Thus, the performance indicators are relative to the size of the
project and produce much more useful information than the
variances alone. Because they are relative to size we can use
the
performance indexes and the WBS to isolate problems at the
control accounts of the project, before the project is out of con-
trol and formulate actions proactively to resolve these problems.
As shown in Figure 12, the project is doing quite well with a
per-
formance index of 0.98, which is well within a +10 percent tol-
erance. However, if we look at the control accounts, we see

Plants has a performance index of 0.87, which is outside our
+10 percent tolerance and indicates a problem in that area.
Relevance-to-size indicators also lend themselves very well to
being charted individually over time. Figure 13 shows the SPI
and CPI charted over time using “stoplight” type colors of green
when things are going very well; yellow, when the problem res-
olution should start to be considered; and red, when the project
EVM.05.9
Figure 12—Using Performance Indicators With the WBS
EVM.05.10
or control account is out of control and actions need to be put
in place to gain control.
STEP 9—FORECAST FUTURE PERFORMANCE
Just like the pilot of a plane, a project manager must monitor
the resources needed for the future of the project. The second
category of earned value analysis formulas helps us do just that.
The earned value analysis formula for predicting what the
total project costs could be if things do not change is called the
estimate at completion (EAC). The following are two formulas
(of a multitude available) for various analytical situations:
• A simple way:

BAC
EAC = --------
CPI
• A more complex way:
BAC-EV
EAC =AC + --------------
CPI*SPI
Using our sample data:
PV = $45,000
EV = $35,000
AC = $40,000
SV = -$10,000
CV = -$5,000
SPI = 0.78
CPI = 0.86
BAC = $100,000
Our EAC using both formulas would be:
EACSimple = $100,000/0.86 = $116,279
EACComplex = $40,000 + ($100,000 - $35,000)/0.86*0.78
= $40,000 + $65,000/0.67
= $40,000 + $97,015
= $137,015
Keep in mind that all this forecasting analysis is still trying to
predict the future and should always be qualified with the
caveat
“if things do not change.”
A calculation of how much money or effort might be needed

to complete the project, if things do not change, is known as the
estimate to complete (ETC):
ETC = EAC-AC
For our sample using the complex EAC:
ETC = $137,015 - $40,000 = $97,015
In this example we might need almost as much as our origi-
nal budget to complete the rest of the work of the project.
Another simple calculation that will tell us if the project is
likely to overrun or underrun the budget if things do not change
is the variance at completion (VAC):
VAC - BAC-EAC
With our sample data:
Figure 13—Performance Indicators Charted Over Time
VAC = $100,000 - $137,015 = -$37,015
Again, if the VAC is negative, the project could go over budg-
et.
The to-complete-performance-index (TCPI) is calculated by
taking the money, or effort hours, remaining and dividing it by
the work remaining:
For our sample data:
TCPI = ($100,000 - $40,000)/($100,000 - $35,000)

= $65,000/$60,000 = 1.08
This represents the amount of performance needed, from the
data date forward, to complete the project for the budget that
was baselined.
Step 10—Manage Changes to the Agreed Upon Baseline
One of the primary steps in controlling the cost and schedule
during execution of the project is to establish a certain disci-
pline on the project baseline, i.e., the baseline never changes
unless a formal change management process has taken place.
This does not mean that the work packages of the baselined
scope cannot be replanned and rescheduled; however, many
circumstances that cannot be controlled by any project manag-
er can cause the project to be out of control. If the reality of the
cost or schedule status of the project happens to be out of the
control area of the baseline, then it is not this reality that is
incorrect. The original plan that is represented by the baseline
is incorrect and therefore may need to be changed.
The change management process should incorporate the fol-
lowing types of activities:
• An agreement of by both the customer and the project team
on the level of change management control required.
• A form documenting that the change (e.g., a change
request form).
• A team to analyze the change.
• A governing board.
• An agreed amount of budget and time for all approved
changes. And,
• A rebaselining of the approved replan.

The baseline is the guidance system that makes the integrat-
ed process of earned value management work.
SO WHY SHOULD WE DO IT?
Because earned value management is just basic good project
management.
Ursula Kuehn, EVP
UQN and Associates
1515 Richie Lane
Annapolis, Maryland, 21401, US
Phone: +1.443.822.7400
Email: [email protected]
EVM.05.11
Reproduced with permission of the copyright owner. Further
reproduction prohibited without permission.
Table of Contents
DB#8 Time Management.docx

DB#8: Time Management
The research of Nan and Harter (2009) suggests that there is a
"beneficial range of budget pressure" (p. 636) resulting in
improved software development efficiency. Does this
perspective make sense to you? How might this concept be
realized within IT department management plans? Discuss the
risks and benefits of working to find this 'beneficial range'.
Reference:
Nan, N., & Harter, D.E. (2009). Impact of budget and schedule
pressure on software development cycle time and effort. IEEE
Transactions on Software Engineering, 35(5), 624-637.
Discussion Boards Rules:
Each week of the Management in IT course features mandatory
Discussion Board participation. Learners are required to post a
200-400 word, grammatically correct entry on the topic
presented. At least one scholarly reference - such as the course
text or peer-reviewed journal articles - should be cited in APA
format in each week's post (some exceptions are noted in the
discussion instructions). In addition, each week you are
required to post a response to at least two other students’ initial
post. These response posts must be substantial, not simply
“Great post!”, and should offer comments, questions, or
suggestions to promote further discussion. Initial posts are due
by the end of Tuesday of each week. Response posts are due by
the end of Friday of each week. Rubrics are presented with each
discussion to provide clarity on the grading criteria.
DUE TUESDAY SEPTEMBER 27TH @11PM

Assignment 4. Project Time Management.docx
Assignment 4 - Project Time Management
Complete Exercise #2 parts a-d on page 257 of the Schwalbe
text. Submit a single Word document containing the AOA
network diagram and the answers to the questions.
DUE TUESDAY OCTOBER 06TH @11PM
Impact of Budget and Schedule Pressure on Software
Development Cycle Time and Effort(1).pdf
Impact of Budget and Schedule Pressure on
Software Development Cycle Time and Effort
Ning Nan and Donald E. Harter, Member, IEEE
Abstract—As excessive budget and schedule compression
becomes the norm in today’s software industry, an
understanding of its
impact on software development performance is crucial for
effective management strategies. Previous software engineering
research

has implied a nonlinear impact of schedule pressure on software
development outcomes. Borrowing insights from organizational
studies, we formalize the effects of budget and schedule
pressure on software cycle time and effort as U-shaped
functions. The
research models were empirically tested with data from a $25
billion/year international technology firm, where estimation
bias is
consciously minimized and potential confounding variables are
properly tracked. We found that controlling for software
process, size,
complexity, and conformance quality, budget pressure, a less
researched construct, has significant U-shaped relationships
with
development cycle time and development effort. On the other
hand, contrary to our prediction, schedule pressure did not
display
significant nonlinear impact on development outcomes. A
further exploration of the sampled projects revealed that the
involvement of
clients in the software development might have “eroded” the
potential benefits of schedule pressure. This study indicates the
importance of budget pressure in software development.
Meanwhile, it implies that achieving the potential positive
effect of schedule
pressure requires cooperation between clients and software
development teams.

Index Terms—Cost estimation, time estimation, schedule and
organizational issues, systems development.
Ç
1 INTRODUCTION
RAPID advances in technology have enabled more andmore
individuals and companies to compete in the
global marketplace [1], [2], [3]. To succeed, companies must
constantly look for new ways to act faster and incur less cost
than other players in the business. Software companies are
not exceptions. Globalization, outsourcing and open-source
movements have intensified the competition in the software
industry [4], [5], [6], [7]. To succeed, software companies
strive to get their jobs done faster for less money.
Consequently, schedule and budget compression has
become the norm in today’s software industry [8].
In this study, we attempt to understand how the pressure
created by budget and schedule compression affects the
actual cycle time and cost of software development.
Particularly, we intend to see whether improved software
schedule and cost can be achieved with proper management
of the budget and schedule pressure. An understanding of
when and how budget and schedule pressure will positively
(or negatively) affect cycle time and cost of software
development projects enables managers to rationalize their
budget and schedule setting policies. More importantly,
software management can leverage the beneficial effect of
budget or schedule pressure on software development to
gain more competitive advantage in the global market.
In activities such as sales or sawmill operation, organiza-
tion researchers have long recognized a potential positive

effect of job-related pressure on task performance [9], [10],
[11], [12], [13], [14]. Compared with work examined by
organizational studies, software development is different in
that it tends to have higher level of uncertainty and
variability [15]. The distinct characteristics may confound
the effect of pressure on performance. For example, knowing
that management might reduce a software development
team’s estimate, a team could increase its estimate by a safety
factor (i.e., “padding”) [8]. Such practice is enabled, and
maybe encouraged, by the uncertainty of software develop-
ment. The estimation bias diminishes effects of schedule or
budget pressure because it creates artificial resource com-
pression without actually increasing the task demand. In
addition, product size, process maturity, and software
complexity may vary substantially across different projects.
The variability of software development has caused incon-
sistent results about the effect of schedule pressure on project
cost (e.g., among [16], [17], [18], [19]). Given the special
characteristics of software development, a study with proper
control of the confounding variables is needed to evaluate
the applicability of the positive effect of pressure identified in
the organizational studies to software management.
Furthermore, our concern with effects of pressure is
motivated by the uneven research attention paid to schedule
versus budget pressure. Compared with the literature on
schedule pressure, budget pressure has received little
attention. Extant studies often view budget as a fixed value
(e.g., [20] and [21]). However, it’s very likely for software
clients to reduce a vendor’s estimated budget during contract
negotiation. This warrants a study looking at effects of
budget pressure to identify the beneficial or excessive range
of budget compression.
624 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
VOL. 35, NO. 5, SEPTEMBER/OCTOBER 2009

. N. Nan is with the Price College of Business, University of
Oklahoma,
307 West Brooks, Norman, OK 73019. E-mail: [email protected]
. D.E. Harter is with the Whitman School of Management,
Syracuse
University, 721 University Avenue, Syracuse, NY 13244.
E-mail: [email protected]
Manuscript received 28 July 2007; revised 3 July 2008;
accepted 17 Feb. 2009;
published online 20 Mar. 2009.
Recommended for acceptance by D. Rombach.
For information on obtaining reprints of this article, please send
e-mail to:
[email protected], and reference IEEECS Log Number TSE-
2007-07-0229.
Digital Object Identifier no. 10.1109/TSE.2009.18.
0098-5589/09/$25.00 � 2009 IEEE Published by the IEEE
Computer Society
By borrowing insights from organizational studies, we
propose nonlinear relationships between budget and
schedule pressure and development outcomes. With data
collected on software projects from a $25 billion/year
international technology firm, this study empirically tests
the relationship between budget and schedule pressure and
project performance. The data set had adequate information
to control for several critical confounding variables, such as
the estimation bias, product size, process maturity, software
complexity, and conformance quality.
The scope of the current study is described by the
following concepts and research questions. Budget and

schedule pressure is defined by the discrepancy between
budget and schedule estimated by the development team
and those negotiated with the client. Software development
refers to all the stages starting from initial design through
final product acceptance testing. Based on the tradition of
software engineering research, the cost of software devel-
opment is measured by the total number of person months
logged by the development team [22] and is referred to as
development effort throughout this paper. Cycle time, or
project duration, is measured by the calendar months
elapsed from the first day of design to final customer
acceptance of the product. Our research question is: What is
the impact of budget and schedule pressure on software
development cycle time and effort controlling for software
process, size, complexity, and conformance quality?
The rest of the paper is organized as follows: In the next
section, we review the software engineering literature about
the pressure-performance relationship. In Section 3, we
develop the theoretical foundation and hypotheses of this
study. Section 4 describes our research method. Section 5
presents the statistical analysis and results. Section 6
examines the results. In the last section, we discuss
conclusions of the study.
2 LITERATURE REVIEW
In the software engineering literature, researchers have long
recognized the critical impact of resource constraints (e.g.,
project schedule or budget) on software development
outcomes. Particularly, with respect to project schedule, a
stream of research has shed light on its effects on
development cycle time or effort. For example, in The
Mythical Man-Month, Brooks pointed out that schedule and
manpower were not interchangeable because software
developer productivity may deviate significantly from a

constant rate as complexity of software projects increases.
He stated the viewpoint as Brooks’ Law: “adding man-
power to a late software project makes it later” [19]. With
Brooks’ Law as the underlying assumption, Putnam
proposed a trade-off function between time and effort in
the Rayleigh curve model [17]. The function indicates that
any compression of schedule has to be compensated by an
increase of effort to maintain the same project cost.
Similarly, the COnstructive COst MOdel (COCOMO) [18]
predicted that there existed an optimal schedule value; any
compression or lengthening from the optimum would lead
to higher cost. Together, Brook’s Law, Putnam’s Rayleigh
curve model, and COCOMO represent the early “trade-off”
view about impacts of project schedule. As summarized by
Jeffery [16], these early studies concerned the sensitivity of
project cost to variation in overall elapsed development
time (including both schedule compression and expansion).
Although they disagreed on the effect of schedule expan-
sion on project cost, all three studies predicted “increased
total effort when the manager’s constraint on elapsed time
available for development is compressed below the ‘opti-
mum’” [16, p. 852].
Subsequent studies in the literature offered more insights
into the effect of schedule compression on software develop-
ment. For example, Jeffery [16] questioned the general-
izability of the negative effect of schedule compression
predicted by earlier studies. By analyzing data from
commercial software projects in Australia, he found that a
compressed schedule could lead to either increased or
decreased development effort. Following Jeffery’s work,
Kitchenham [23] found similar results by analyzing another
data set from a European software project. Moreover, by
reanalyzing the data set behind COCOMO, she found that
there were schedule-compressed projects that were also

effort compressed, although COCOMO predicted a negative
relationship between the two. These studies attributed the
contradictory findings to difference among research sites,
variation among measures of schedule pressure, and missing
control variables in the relationship between schedule
pressure and development effort [16], [23]. In general, these
subsequent studies enriched our understanding of the
relationship between schedule pressure and development
outcomes. Empirically, we see that reduced schedule is not
always achieved at the expense of increased effort; a proper
level of schedule pressure may have beneficial effects on
project outcomes.
In recent years, a few studies have tried to explain the
underlying mechanisms of the impact of schedule pressure.
For example, Austin [24] employed an agency framework to
characterize the strategic behavior of software developers
under schedule pressure. He reduced the concern of soft-
ware developers to two main aspects: 1) being singled out as
the only one who cannot finish task on time and 2) being
penalized for taking quality compromising shortcuts.
Results derived from the mathematical model indicate that
contrary to casual intuition, schedule pressure could
maintain or even improve software project performance.
The underlying mechanism was that software developers
took quality impairing shortcuts to avoid being singled out
as the only few who could not meet deadlines. Very tight
schedules made it impossible for anyone to meet deadlines.
When software developers did not worry about being
singled out, they would be less likely to take shortcuts and
concern more about quality improvement. Higher quality
incurred less rework, and thereby, reduced development
cycle time and effort [25], [26], [27].
Using a system dynamics model, Abdel-Hamid et al.
[28], [29], [30], [31] proposed multiple causal pathways

between schedule pressure and software development
outcomes. They recognized that schedule pressure not only
had a direct impact on productivity by driving developers
to work long hours but also produced an indirect impact by
affecting the error generation rate of a project. Results from
the system dynamics model suggested that contrary to
NAN AND HARTER: IMPACT OF BUDGET AND SCHEDULE
PRESSURE ON SOFTWARE DEVELOPMENT CYCLE TIME
AND EFFORT 625
Brooks’ Law, adding more people to a late project did not
always make it completed later; only aggressive compres-
sion of schedule could cause higher development effort and
longer cycle time.
Compared with studies about schedule pressure, re-
search on budget pressure is rather scanty in the software
literature. Budget constraint is usually discussed as a given
condition (e.g., [20] and [21]) or a value to be minimized
subject to certain outcomes (e.g., [32]). The few exceptions
only provide brief arguments about possible impacts of
budget compression without performing any formal ana-
lysis. For example, the gap between original estimate and

current budget is discussed as one of the questions for
software feasibility review [33]. In addition, budget
compression is briefly mentioned as a potential cause of
higher development cost [34].
The software literature is summarized in Table 1. Taken
together, the literature has three important implications.
First, the impact of schedule constraint on project outcomes
is nonlinear. Particularly, depending on the degree of
schedule compression, schedule pressure may have either
positive or negative effect on development cycle time and
effort. Second, due to difference in research sites and
measures, empirical findings alone may be inconclusive
(see the discussion in [16]). Thus, theoretical explanation of
the underlying mechanisms is warranted to improve the
generalizability of previous findings. Although the recent
studies have offered some theoretical insights, there is a
need for more fine-grained understanding about the
fundamental forces beneath the nonlinear relationship
between pressure and job performance. Third, there is a

knowledge gap regarding the impact of budget pressure on
software development outcomes. While clients commonly
reduce a development team’s proposed budget during
project negotiation, the impact of budget pressure has not
been sufficiently addressed in the literature.
To formally characterize the nonlinear impact of schedule
pressure and explore the effect of budget pressure, we borrow
insights from organizational studies. Researchers have
identified fundamental forces underlying the relationship
between job-related pressure and employee performance
[35]. The fundamental forces are an employee’s natural
responses to stress such as budget or schedule pressure. The
aggregation of the fundamental forces can generate a
TABLE 1
Summary of the Software Literature
nonlinear relationship between pressure and performance
[9], [10], [11], [36], [37], [38], [39], [40], [41], [42], [43].

3 THEORETICAL DEVELOPMENT
Nearly a century ago, researchers found that performance
could increase with intensity of task demand, but only to a
certain point [9]. When intensity of task demand became too
high, performance would decrease. Overall, optimal per-
formance tended to occur at an intermediate level of task
demand while very low or very high level of task demand
often led to poor performance. This nonlinear relationship
between task demand and performance is often referred to
as Yerkes-Dodson Law.
Organization researchers have shown the generalizabil-
ity of Yerkes-Dodson Law to the relationship between job-
related pressure (e.g., budget or schedule pressure) and
employee performance [35]. For example, drawing on the
theoretical framework of Yerkes-Dodson law, Singh [35]
hypothesized curvilinear impacts of role stressors (i.e., role
conflict, ambiguity, and overload) on salespeople job
outcomes such as performance, job tension, and satisfac-
tion. Empirical data from a range of small and large firms
supported the curvilinear effect of role stressors on
salespeople job tension. Meanwhile, in a field experiment
about sawmill workers, researchers found that both work
underload (e.g., mechanically controlled work pact, repeti-
tion of short-cycle operations) and overload (e.g., piece-
rate rush and high demands of attention) could cause long-
term negative effects on workers’ well-being, health, and
job satisfaction. Once workers were given control of the
pace and methods of their work, they experienced a
moderate level of pressure and showed significantly better
health and job satisfaction results. Moreover, in a labora-
tory experiment, researchers varied the level of goal
difficulty in a perceptual speed test. They found that the
relationship between performance and goal difficulty

changed from positive to negative as researchers raised
the goal difficulty level [44].
In general, the applicability of Yerkes-Dodson law is
based on the understanding of the mechanisms behind the
nonlinear relationship between pressure and performance.
Researchers have realized that employees’ fundamental ego-
needs, such as challenge and pride in their work, mediate the
pressure-performance relationship [14]. They see that a low
level of job-related pressure often means a lack of challenge.
When employees (e.g., software developers) cannot fulfill
their fundamental need for challenge, they tend to be
inattentive and bored and, thus, do not perform well [45],
[46]. On the other hand, a high level of pressure often creates
too much challenge for employees to handle. Their pride in
work may be threatened [14]. Consequently, they tend to feel
anxious and frustrated and, hence, perform poorly. Only
under an intermediate level of pressure, employees are more
likely to fulfill both needs for challenge and pride in work.
Optimal performance usually follows the fulfillment of
fundamental ego-needs.
Goal setting theory (see [47] for a review) implies another
mechanism for the nonlinear relationship between pressure
and job performance. A goal is the object or aim of a job
(e.g., to complete a software product) with a specified
amount of resources (e.g., time and budget) [47]. Higher
budget or schedule pressure means more difficult goals
[48], [49]. A major implication of the goal setting theory is
that goal acceptance interacts with goal difficulty and leads
to a nonlinear relationship between goal difficulty and job
performance [44]. Specifically, goal acceptance is negatively
related to goal difficulty, with the transition from accep-
tance to rejection usually occurring at an intermediate level
of goal difficulty. Goal difficulty has a positive effect on

performance for accepted goals and a negative effect on
performance for rejected goals. Overall, performance first
increases with goal difficulty and then levels off or
decreases when goals are too difficult to be accepted.
Optimal job performance usually occurs under an inter-
mediate level of pressure.
Previous research has extended the pressure perspec-
tives from an individual level to a team level. For example,
numerous studies have shown that individual-level goal
setting effects can be generalized to teams [47], [50], [51],
[52]. The resemblance between individual and team-level
pressure effects is most evident when teams are temporarily
assembled and each member’s expected and actual con-
tribution is identifiable. Temporarily assembled teams are
exempted from confounding effects of a number of team
contextual variables such as team history or team culture
[51]. Meanwhile, visibility of individual member’s expected
and actual contribution prevents social loafing [53], which
may cause deviation in a team’s reaction to pressure due to
the individual members’ lack of effort [51].
In this study, we extend the nonlinear relationship
between pressure and performance from an individual level
to a team level. This extension is based on two premises. First,
in the software industry, an essential strategy of project
management is the contracting of IS professionals on a
temporary basis [54]. This strategy helps organizations to
remain responsive to economic and technological changes by
reducing the fixed cost of permanent staff [55], [56]. It makes
temporarily assembled software development teams very
common in the software industry. As discussed above,
temporary teams are less affected by team contextual
variables and, therefore, are more likely to show a nonlinear
pressure-performance relationship similar to that on an
individual level. Second, the basic methodology of software

programming is divide-and-conquer, that is, dividing the
overall task into parts and working on each part individually
[57]. The divide-and-conquer method makes each team
member’s expected and actual contribution identifiable.
Thus, the confounding effect of social loafing on the
pressure-performance relationship is minimized.
In summary, the organizational studies provide fine-
grained understanding of mechanisms underlying the
nonlinear relationship between pressure and performance.
They have indicated the generalizability of the nonlinear
relationship to studies about effects of continuous task
demand, such as budget or schedule pressure, on project
team performance.
3.1 Hypotheses
In the software development context, better performance is
indicated by shorter cycle time and less development effort.
Based on the nonlinear view, shortest cycle time and lowest
AND EFFORT 627
development effort tend to occur under an intermediate
level of budget or schedule pressure while longer cycle time
and higher development effort are associated with very low
or very high level of pressure. Overall, we propose
U-shaped relationships between budget/schedule pressure
and software development cycle time and effort. With the
U-shaped view between pressure and software develop-
ment performance outcomes, we hypothesized the follow-
ing answers to our research question regarding impacts of

budget or schedule pressure on software development cycle
time and development effort (see Table 2).
4 RESEARCH METHODOLOGY
4.1 Construct Measures
4.1.1 Budget and Schedule Pressure
In the scope of this study, we see three requirements for
effective measures of budget and schedule pressure. First,
according to their definition, proper measures should
indicate the discrepancy between development team-esti-
mated budget or schedule and the customer-negotiated
budget or schedule. Second, the literature on the pressure
effect implies that people have to first perceive the pressure
and then respond to it through their performance. As
Robert pointed out that “Software’s problems . . . are about
expectations established at the outset of a project much
more than they are about trouble that happens along the
way” [58, p. 19]. Therefore, measures should be taken at the
onset of a project rather than at the completion of it. Third,
they should be quantitatively comparable across projects
and teams. This requires a formula that can standardize and
quantify the pressure level of a development team.
The literature has not established a consistent measure
for budget or schedule pressure. Budget pressure, often
referred to as “budget constraint” or “cost constraint,” is
usually measured as the total amount of capital available to
a project (e.g., [18]). This measure does not reflect the
discrepancy between team-estimated budget and customer-
negotiated budget. Moreover, it is difficult to compare
budget constraints across projects.
Schedule pressure has been assessed by the elapsed time

of a project (e.g., [17], [18]), the ratio between actual elapsed
time and estimated elapsed time (e.g., [16]), the ratio
between scheduled completion date and forecasted com-
pletion date [30], or self-reported values by software
developers and managers [35]. None of these measures
fulfills the three requirements discussed above. The metrics
based on actual elapsed time [16], [17], [18] are post hoc
rather than ex ante. They do not indicate the pressure level
prior to performance. The self-reported values [35] depend
on people’s subjective opinions. It is difficult to compare
personal assessments across development teams.
Due to a lack of established measures of budget or
schedule pressure, we developed an ex ante measure of
pressure:
Budget Pressure ¼
Team-Estimated Budget � Customer-Negotiated Budget
Team-Estimated Budget
;
Schedule Pressure ¼
Team-Estimated Time � Customer-Negotiated Time
Team-Estimated Time
:
Budget refers to the number of person months of effort
allocated for a development project. Cycle time (or project
duration) is the number of calendar months elapsed from
the first day of design to final customer acceptance of the
product. At the research site, development teams first
proposed their estimated budget and cycle time with the
assistance of an estimation tool. During the negotiation

between the corporation and clients, the customer usually
reduced team-estimated budget, with an average reduction
of 9.5 percent but never an increase in the budget. The
customer was more flexible in negotiations on schedule.
The average schedule reduction was 11.6 percent, but with
both expansion and compression of schedules occurring in
negotiations. The customer-reduced budget and modified
cycle time are recorded in the final contracts after the
completion of negotiation with the client. The ratio of the
change to the budget or schedule to the original budget or
schedule is the measure of pressure. For example, if a team-
estimated budget is $10;000 but the negotiation reduces the
budget to $8;000, the budget pressure is 20 percent
(($10;000 � $8;000Þ=$10;000 ¼ 0:2 or 20 percent). The nu-
merators of the two measures reflect the discrepancy
between team estimates and customer-negotiated budget
or cycle time. We use team-estimated budget or cycle time
as the denominator because taking the ratio between the
discrepancy and the initial team estimates can quantify and
standardize pressure levels across projects and teams.
TABLE 2
Budget and Schedule Pressure Hypotheses
Precisely speaking, our measures of budget and
schedule pressure only capture the postestimation budget
and schedule compression. They do not account for budget
and schedule pressure that arises and evolves during a
software development project. Expectations established at
the beginning of a project can be a significant source of
variations in software development teams’ performance

during a project [58]. In this paper, we focus on the
postestimation budget and schedule compression while
acknowledging that the pressure occurring during a project
can provide a different perspective of the relationship
between pressure and performance.
4.1.2 Cycle Time
Cycle time is one dimension of the project performance. It is
the time to develop the software product, i.e., the number of
calendar months elapsed from the first day of design to
final customer acceptance of the product.
4.1.3 Development Effort
Development effort is another dimension of project perfor-
mance. In this study, the total number of person months
logged by the development team from initial design
through final product acceptance testing constitutes the
development effort.
4.1.4 Control Variables
Software conformance quality is defined as the extent to
which a software product meets quality standard and initial
customer specifications. Prior studies have found that
software conformance quality, usually measured by the
number of defects, affects the amount of rework. Subse-
quently, the amount of rework has a significant impact on
development cycle time and effort [25], [26]. Given the
importance of conformance quality in development perfor-
mance, we controlled for its effect in the data analysis. Here,
conformance quality is measured as the number of lines of
source code in the product divided by the sum of defects
found in system testing. Three stages of system testing using
a formal test plan were contractually mandated for all

products: vendor’s system testing, client system testing with
a sample database, and client stress testing with a production
database. Vendor testing was performed by a test group
independent of the development team. Client testing was
performed by the client’s technical and user community,
supported by a contractor with expertise in testing complex
systems. This measure of quality is the inverse of the defect
density [59] used in many previous quality studies. This
paper adopts the inverse defect density because it offers a
more intuitive understanding of the conformance quality
values: Higher values mean better conformance quality.
Product size has been recognized as a significant factor
in cycle time [60], [61] and development effort [62], [63]. In
this study, product size is measured by thousand lines of
source code in a product. All projects in this study used the
same language, ensuring comparability.
Past research indicated that process maturity [64], [65]
and product complexity [66], [67] have significant impacts
on software development performance. Process maturity is
measured by the SEI’s CMM level of maturity. The CMM
framework includes 18 key process areas such as quality
assurance, defect prevention, peer review, and training [68].
The more CMM process areas that are adopted, the higher
the maturity level is.
Product complexity captures three important dimensions
of complexity: domain, data, and decision complexity [66]
(see the Appendix, which can be found on the Computer
Society Digital Library at http://doi.ieeecomputersociety.
org/10.1109/TSE.2009.18, for details). Domain complexity is
the level of functional complexity as determined by engineer-
ing from the user requirements specification. Data complex-
ity refers to the anticipated level of difficulty in developing

the system because of complicated data structures and
database relationships. Decision complexity measures the
degree of difficulty in the decision paths and structures
within the product. Software teams assessed the three
dimensions of product complexity using the criteria specified
in the Appendix, which can be found on the Computer
Society Digital Library at http://doi.ieeecomputersociety.
org/10.1109/TSE.2009.18. Each software product manager
was trained in the assessment of complexity by senior
management used in the estimation model [66]. The three
dimensions of complexity were assessed ex ante by the
software product manager, monitored by quality assurance
to ensure compliance with the estimation process, verified by
senior management for consistency with other projects, and
validated by an independent assessment of the client’s
technical staff and managers. The three scales of complexity
showed high intercorrelation. Scores of the product complex-
ity were computed by taking an average of the three
complexity scales.
4.2 Regression Models
We developed four research models to test the effects of
budget or schedule pressure on development cycle time
and effort of software projects. Their function forms are
the following:
CycleTime ¼ fðprocess maturity; size; complexity;
quality; budget pressureÞ;
ðaÞ
Effort ¼ fðprocess maturity; size; complexity;
quality; budget pressureÞ;
ðbÞ

CycleTime ¼ fðprocess maturity; size; complexity;
quality; schedule pressureÞ;
ðcÞ
Effort ¼ fðprocess maturity; size; complexity;
quality; schedule pressureÞ:
ðdÞ
4.3 Data Collection
To test the hypotheses, we collected cross-sectional data on
software projects performed by a $25 billion/year interna-
tional technology firm. The company contracts commercial,
international, and government clients. The software pro-
jects in our data set were developed for a material
requirements planning information system to manage spare
parts acquisition.
In the technology firm, assessment of process maturity
was performed by government auditors and corporate
AND EFFORT 629
personnel in divisions outside of systems integration. These
independent groups used the SEI’s CMM [68] to assess the
maturity of the firm’s software development and support-
ing activities. We collected process maturity data from these
independent groups.

Other data were collected by the technology firm and
were audited by the clients to ensure accuracy and
accountability. Cycle time data were retrieved from the
project management scheduling system. Effort data were
tracked by the corporate time reporting system. Software
defect data were extracted from the Configuration Manage-
ment (CM) database. Information related to the estimated,
budgeted, and actual duration and cost of software
development was manually coded from the electronic and
paper files maintained by the firm.
The technology firm provided an ideal site for this
research because its estimation method and management
strategies can help us eliminate alternative explanations of
the impacts of budget or schedule pressure on development
performance. First, by using the Software Productivity
Quality and Reliability (SPQR20) automated tool, the firm
minimized the “padding” effect. In software industry,
development teams often extend their “rational” estimates
of cycle time or cost by a safety factor to counteract the high
levels of pressure [8]. The magnitude of this padding effect
varies across project teams and is hard to assess. As a result,
many earlier research findings were confounded by the
padding effect. At our research site, development teams
estimated function point counts and complexity based on
user task requirement specification. These estimates were
validated by the client to ensure accurate interpretation of
the requirements. The function point counts, complexity,
and environmental variables were submitted to SPQR20 for
budget and schedule projection. SPQR20 provides a
consistent methodology for estimation of budget and
schedule, preventing distortion of the estimates.
To ensure estimation accuracy with SPQR20, develop-
ment teams used historical data to calibrate budget and
schedule projections. Senior management examined the

accuracy of the methodology annually prior to estimation
of the next year’s product development. Historically, the
estimation tool underestimated budget by 6.2 percent, i.e.,
the teams averaged 6.2 percent budget overruns compared
to estimates. The calibration of SPQR20 with the organiza-
tion’s historical data ensured that development team
productivity was accurately reflected in the model estimates.
Furthermore, the technology firm implemented a series
of management practices to prevent bias in software
schedule and cost estimates. These practices corresponded
to the bias reduction strategies identified by Peeters and
Dewey [69]. Each of these practices was performed in the
estimation of schedule and budget by the firm during the
time frame of the study. Table 3 summarizes the strategies
recommended by Peeters and Dewey [69] and how the
technology firm implemented the corresponding practices.
We found 66 projects with suitable data for the study of
budget and schedule pressure (see Table 4 for the descriptive
statistics, and the Appendix, which can be found on the
Computer Society Digital Library at http://doi.ieeecompu-
tersociety.org/10.1109/TSE.2009.18, for the correlation ma-
trix). The sample size of our study is comparable to previous
studies about software development. In a recent study,
Agrawal and Chari [67] reviewed 18 published software
studies and found a median sample size of 37 (see the study
for more detail).
5 ANALYSIS AND RESULTS
To test the existence of the U-shaped pressure-performance
relationship, we included quadratic terms of budget or
schedule pressure as independent variables in the statistical
models. This method has been proved effective by previous

studies (e.g., [70]). Researchers have found economies and
diseconomies of scale [61] in software development. As a
result, a log-log relationship has generally been used to study
software effort and cycle time. The appropriateness of a log-
log model to our data set is further supported by the
Davidson and MacKinnon’s specification test for non-nested
models (J-test) [71]. The J-test result shows that a log-log
model is preferred over semilog and linear models. In the log-
log model, we did not take log-transformation of the pressure
terms because it is possible for budget or schedule pressure
values to be 0 or negative. Moreover, since our models focus
on the U-shaped relationship between pressure, effort and
cycle time, we operationally define the U-shaped function
using a quadratic term. In this formulation, taking the
logarithm of a quadratic would simply reduce it to twice
the linear term. The specific regression models for budget
pressure analysis are the following:
ln ðCycle TimeÞ¼ �01 þ�11 ln ðprocess maturityÞ
þ�21 ln ðproduct sizeÞþ�31 ln ðcomplexityÞ
þ�41 ln ðconformance qualityÞ
þ�51 ðbudget pressureÞþ�61 ðbudget pressureÞ2;
ð1Þ
ln ðEffortÞ¼ �02 þ�12 ln ðprocess maturityÞ
þ�52 ðbudget pressureÞþ�62 ðbudget pressureÞ2:
ð2Þ
The statistical models for schedule pressure analysis are
the following:
ln ðCycle TimeÞ¼ �03 þ�13 lnðprocess maturityÞ

þ�43 lnðconformance qualityÞ
þ�53ðschedule pressureÞþ�63ðschedule pressureÞ2;
ð3Þ
ln ðEffortÞ¼ �04 þ�14 ln ðprocess maturityÞ
þ�54ðschedule pressureÞþ�64ðschedule pressureÞ2:
ð4Þ
The models were initially tested with ordinary least
squares (OLS). However, because data in this study are all
from the same company, it may be possible that the error
terms are correlated as a result of some common effect. A
Breusch-Pagan test of independence indicated that the error
terms are significantly correlated for both the budget pressure
equations ((1) and (2)) (�2 ¼ 5:29;p ¼ 0:02) and the schedule
pressure equations ((3) and (4)) (�2 ¼ 14:96;p ¼ 0:00).
Therefore, we estimated the seemingly unrelated regres-
sion (SURE) parameters using a feasible generalized least
squares (FGLS). Tables 5 and 6 display SURE estimates for
the budget pressure models ((1) and (2)) and the schedule
pressure models ((3) and (4)), respectively.
We performed Cook’s Distance test [72] with 1 as the
threshold to look for outliers and influential points in both
budget and schedule pressure data samples. The results

indicated that no outlier existed in the schedule pressure
data and four outliers existed in the budget pressure data.
To ensure the validity of the test results, we removed the
outliers and performed statistical tests on the budget and
schedule pressure data sample. The normality assumption
was not rejected using the Kolmogorov-Smirnov test [73].
No evidence was found of heteroskedasticity using White’s
[74] test. Multicollinearity of explanatory variables was
tested using the condition index and variance inflation
AND EFFORT 631
TABLE 4
Descriptive Statistics
TABLE 3
Bias Reduction Strategies
factor. All condition indexes and variance inflation factors
were within acceptable ranges.
The results suggest strong support for our hypothesized
U-shaped relationship between budget pressure and devel-
opment cycle time. As shown in Table 5, there is a positive
and significant coefficient (�61 ¼ 11:38;p ¼ 0:05) for the
quadratic term and a negative and significant coefficient
(�51 ¼�3:80;p ¼ 0:02) for the linear term of budget pres-

sure in the cycle time equation (1). The statistical results
indicate that budget pressure has a significant U-shaped
effect on development cycle time. Thus, H1 is supported.
Statistical results also show strong support for our
hypothesized U-shaped relationship between budget pres-
sure and development effort. In Table 5, the coefficient for
the quadratic term in the effort equation (2) was positive and
statistically significant (�62 ¼ 31:39;p ¼ 0:01). Meanwhile,
the coefficient for the linear budget pressure term in the
same equation was negative and significant (�52 ¼�12:23;
p ¼ 0:00). These results suggest that budget pressure has a
significant U-shaped effect on development effort. Hence,
H2 is supported.
The results do not support the U-shaped effect of
schedule pressure on development cycle time. Although
the coefficient of the linear schedule pressure term in (3) is
negative and significant (�53 ¼�0:43;p ¼ 0:01), the coeffi-
cient of the quadratic term in the cycle time equation (3) is
not significant (�63 ¼�0:25;p ¼ 0:40) (Table 6). The results
do not support H3 that predicts schedule pressure has a
significant U-shaped effect on software development cycle

time.
Finally, we did not find statistical support to the
hypothesized U-shaped relationship between schedule
pressure and development effort. As shown in Table 6,
the coefficient of the quadratic term in the effort equation
(4) is negative but not significant (�64 ¼�0:87;p ¼ 0:06).
Also, the linear pressure term in (4) is negative and not
significant (�54 ¼�0:43;p ¼ 0:07). The results do not sup-
port the U-shaped curve for H4.
In summary, we see that budget pressure has sig-
nificant U-shaped relationships with software develop-
ment cycle time and development effort, controlling for
software process, complexity, and conformance quality. In
contrast, schedule pressure does not show a significant
TABLE 5
Parameter Estimates of the Budget Pressure Models
U-shaped relationship with development cycle time or
development effort.
6 DISCUSSION
To gain intuition of the nonlinear effect of budget pressure,
we plot the components of the linear and squared budget

pressure terms and their combined effect on log-trans-
formed cycle time and effort (see Figs. 1 and 2). The linear
representations of cycle time and effort appear in Figs. 3 and
4. As indicated in the figures, the negative linear term
initially reduces the cycle time and cost; the positive squared
pressure term eventually offsets any time and cost reduction
due to the linear term. The most significant improvement
due to budget pressure occurs in the range of 0-10 percent
pressure, identified as beneficial range in the figures. The
combined curves tend to flatten and become shallow over
10 percent, noted in the limited difference range. Excessive
budget compression results in rapidly increasing cycle time
and costs, shown as the excessive compression range.
The nonsignificant effect of schedule pressure is some-
what surprising. To further interpret the result, we examined
the estimates, contracts, and detailed activity schedules of
the sampled projects. An interesting finding is that user
involvement in the software development process might
have attenuated the improvement of development cycle time
in response to schedule pressure. Specifically, the clients of
the projects were involved in the development process by
conducting periodic reviews of the deliverables (e.g., design
specifications, test plans, and user manuals), formal life cycle
phase reviews (design, detailed design, code development,
and testing), and audits. This review and audit time ranged
from 10 to 20 percent of the product development schedule.
When comparing the client review time specified in the
estimates with the actual length shown in the schedule
charts, we noticed that clients never shortened their review
time even when the projects were under schedule pressure.
In addition, the client reviews generally appeared on the
critical path for the product schedules. The lack of elasticity
of client review time reduced the variability of the develop-
ment cycle time in response to schedule pressure. This

implies that achieving the potential positive effect of
schedule pressure requires cooperation between clients and
software development teams.
In contrast, the lack of effect of schedule pressure on
effort can be attributed to other causes. Specifically, when
AND EFFORT 633
TABLE 6
Parameter Estimates of the Schedule Pressure Models
schedule pressure was not accompanied by significant
budget pressure, the project manager had the flexibility of
increasing manpower over a shorter period of time without
affecting the budget. For example, a project planned for five
months with four software developers, when shortened to
four months, could increase staff to five software devel-
opers, maintaining 20 person months of effort. The benefit
of schedule pressure on effort was negated by the increase
in staff by management.
Investigation into whether the performance of the
estimation tool affected the results reveals an interesting
pattern. For all projects, the estimation tool underestimated
projects, i.e., the average project resulted in a 6.2 percent
budget overrun compared to the original estimate. How-
ever, for projects with beneficial pressure, those with less
than 10 percent budget pressure, projects, on average,
experienced a 7.7 percent budget underrun. Projects with
more than 10 percent budget pressure had average budget
overruns of 18.8 percent.

Furthermore, to deepen our understanding of the
mechanisms underlying the observed pressure effects, we
examined development teams’ reaction to extremely high-
and low levels of budget and schedule reductions. At the
research site, management used the Earned Value approach
to track performance against the project baseline during a
software development project. The baseline is the planned
schedule and budget of the project from final negotiations.
The actual schedule and cost performance were monitored
monthly against this baseline to determine if the project was
tracking to the planned schedule and budget. We utilize the
earned value charts generated during this management
process as the lens to open up development teams’ reaction
to budget and schedule compression.
Figs. 5 and 6 are the earned value charts for low- and
high- pressure projects, respectively. In the figures, planned
value (PV) is the dollar value of work scheduled. Earned
value (EV) is the actual value of work completed; actual cost
(AC) is the dollar expenditure that was used to accomplish
the work to date. The latest revised estimate (LRE) reflects
management projection of an underrun or overrun. The
contract line represents what was negotiated in the contract;
adjustments to the contract can occur when functionality is
changed, altering the contract value.
Fig. 5 is an earned value chart for a project with budget
pressure in the 0-10 percent range. Under the lower
pressure scenario, the AC exceeded the PV in the first
month, but the development team appeared to be motivated
by this cost overrun and able to recover in the second
month. In the sixth month, the EV lagged the PV, indicating
schedule slippage. Again, the team was able to correct
before the end of the project. The latest revised estimate was

stable, a sign that the development team was able to react
positively to any temporary schedule or cost slippage and
make adjustments throughout the life of a project to
accommodate low levels of pressure.
Under a higher pressure scenario, as seen in Fig. 6, the
effect of pressure on budget and schedule resulted in cost
and schedule overruns. In the figure, it appears that there
Fig. 1. Linear and squared component effects of budget pressure
on
log(cycle time).
Fig. 2. Linear and squared component effects of budget pressure
on
log(effort).
Fig. 3. Effect of budget pressure on cycle time.
Fig. 4. Effect of budget pressure on effort.
were several points in time when the development team
recognized that schedule and budget goals were too
challenging to achieve, as indicated in changes in the
LRE line: after the first few months and again approxi-
mately 50 percent through completion of the project. The
problems were exacerbated by functional changes to the
product baseline late in the life cycle at months 13 and 14,
resulting in a final spiking of the LRE in month 14. Overall,

in this high pressure scenario, the development team’s
attempt to catch up with schedule or budget goals was
overwhelmed by the accumulated schedule and cost
overruns, which further discouraged the team’s effort to
make adjustment. Meanwhile, adding personnel late in the
project simply increased the cost overrun and further
delayed the schedule, consistent with Brook’s Law.
The statistical analysis and the follow-up investigation
offered several important implications to research and
practice. First, the finding about the development team’s
reaction to extremely low/high pressure implies the
generalizability of the theoretical development of this study
(i.e., the Yerkes-Dodson Law and its underlying mechan-
isms) to the software development context. For example, the
development team’s reaction to low levels of pressure
conforms to the goal setting theory [44] that, for acceptable
goals, goal difficulty has a positive effect on performance.
Meanwhile, high levels of pressure generate a negative
reaction because they create too much challenge for the
development team [14]. The finding about the development
team’s reaction also helps us gain deeper understanding of
previous studies on schedule pressure. For example,
Putnam’s Rayleigh curve model [17] might have captured
the negative reaction of management to high levels of
schedule pressure. At the same time, the seemingly contra-
dictory findings from Jeffery’s study [16] may be attributed
to the development team’s positive reaction to low levels of
schedule pressure. To practitioners, knowing that different
levels of budget or schedule pressure can generate dis-
tinctive reactions can help them anticipate and interpret
development team performance.
Second, the strong statistical support for the U-shaped
relationships between budget pressure and development
cycle time and effort suggests that in a software development

context, budget pressure may be a more robust indicator of
the impact of job-related pressure on performance. Schedule
pressure did not exhibit similar effect because its effect on
cycle time was reduced by the inelasticity of customer
review activities; the effect on manpower was offset by
management’s ability to increase staffing when schedules
were reduced.
Furthermore, when previous studies imply a nonlinear
impact of resource constraints on software development
outcomes, results of this study suggest that such nonlinear
impacts can be formalized as a U-shaped function. Our data
analysis indicates that budget pressure has a positive
impact on software development performance when it is
within a beneficial range of 0-10 percent. Beyond this
beneficial range, there is a range of limited difference in the
effect of pressure as the cycle time and effort curves flatten.
The detrimental effects of extremely high levels of pressure
are evident when pressure continues to increase beyond
this range. To software management, the U-shaped view
and the beneficial or excessive range associated with it
provide valuable guidance for feasible budget and deadline
setting policies. Our results suggest that, with a properly
tightened budget, software management can save time and
manpower simultaneously. The reduced cycle time under
budget pressure is not offset by an increased workforce.
Management can use historical data to estimate the
beneficial range of budget pressure. With the knowledge
of beneficial pressure range, software management can be
more effective in contract negotiations.
The lack of support for the hypotheses regarding the
effect of schedule pressure reveals a unique requirement for
software projects to harvest positive effects of schedule
pressure: the cooperation between clients and software

development teams. Observation from our research site
indicates that clients may not sympathize with develop-
ment teams in schedule pressure. The behavior of clients
can diminish the effect of schedule pressure found in
previous studies. For future research about software
development schedule, this study implies the importance
of examining client involvement as a significant factor in
development cycle time. Meanwhile, for software manage-
ment, it is critical to motivate the clients to share schedule
pressure and cooperate with development teams in redu-
cing development cycle time.
When interpreting the results, we were aware of several
caveats. First, the results are based on data from a single
organization. This could affect the generalizability of the
findings, particularly the beneficial/excessive budget or
schedule ranges. However, pooling data from multiple
organizations could introduce confounding effects of
different estimation methods and different measures of
key variables. Moreover, structural and environmental
AND EFFORT 635
Fig. 5. Project with beneficial pressure. Fig. 6. Project with
high pressure.
variations of different organizations could confound the
relationship between pressure and software development
performance. Future research that pools data from multiple
organizations can seek to validate and extend the results of
this study by adequately controlling the confounding
variables discussed earlier. Second, the pressure measures

only capture the postestimation budget and schedule
compression rather than pressure arising during a project.
That prevented us from examining the dynamic impacts of
schedule and budget pressure throughout a project. In
future work, budget and schedule pressure can be
evaluated at several points during a development project.
An interesting question to examine is whether the effect of
pressure found in this study can be applied to later phases
of a project.
7 CONCLUSION
In this paper, we formalize the nonlinear effect of manage-
ment pressures on project performance as U-shaped
relationships. The relationships are tested with data from
a research site, where estimation bias is consciously
minimized and information about the potential confound-
ing effects such as software process, complexity, and
conformance quality is properly tracked. The data analysis
supports the U-shaped relationships between budget
pressure and software development cycle time and devel-
opment effort. On the other hand, hypotheses about the
U-shaped impacts of schedule pressure on development
cycle time and effort are rejected.
In the highly competitive software engineering industry,
companies are looking for ways to make software produc-
tion more efficient. The main contribution of this study is to
rigorously assess the possibility of achieving improved
cycle time and effort with proper management of pressure

in software development. The analysis suggests that there
exists a beneficial range of budget pressure. Such beneficial
effects may also be realized from schedule pressure if
software clients cooperate with development teams in
dealing with schedule compression. In addition to the
empirical findings, this study sheds light on the funda-
mental mechanisms underlying the U-shaped relationships
between development pressure and software performance.
By connecting software development with organizational
studies, this study not only helps to improve the general-
izability of related findings from the software literature
(e.g., [16], [17], [19], [23]) but also enriches the organiza-
tional literature by extending its theories to the software
context. For software management, the theoretical under-
standing as well as the empirical findings from this study
can help them attain more effective negotiation strategies,
deadline, and budget setting policies, which ultimately
adds to the competitive advantage of a software company.
ACKNOWLEDGMENTS
The authors would like to thank Dr. Dieter Rombach and
the three anonymous reviewers for their insightful com-
ments. They would also like to thank Tara Thomas for her
assistance in data collection.
REFERENCES
[1] D. Burdick, “Celestica Transforms Competitiveness with
C-Commerce,” Gartner Case Study, Jan. 2000.

[2] D. Chatterjee, R. Grewal, and V. Sambamurthy, “Shaping
Up for
E-Commerce: Institutional Enablers of the Organizational
Assim-
ilation of Web Technologies,” MIS Quarterly, vol. 26, no. 2, pp.
65-
90, 2002.
[3] T.L. Friedman, The World Is Flat: A Brief History of the
Twenty-First
Century. Farrar, Straus and Giroux, 2006.
[4] B. Fitzgerald, “The Transformation of Open Source
Software,”
MIS Quarterly, vol. 30, no. 3, pp. 587-598, 2006.
[5] B. Ives and S.L. Jarvenpaa, “Applications of Global
Information
Technology: Key Issues for Management,” MIS Quarterly, vol.
15,
no. 1, pp. 33-50, 1991.
[6] N. Levina and J.W. Ross, “From the Vendor’s Perspective:
Exploring the Value Proposition in Information Technology
Outsourcing,” MIS Quarterly, vol. 27, no. 3, pp. 331-364, 2003.
[7] K.J. Stewart and S. Gosain, “The Impact of Ideology on
Effectiveness in Open Source Software Development Teams,”
MIS Quarterly, vol. 30, no. 2, pp. 291-314, 2006.
[8] E. Yourdon, Death March: The Complete Software
Developer’s Guide to
Surviving “Mission Impossible” Projects. Prentice Hall PTR,
1997.

[9] R.M. Yerkes and J.D. Dodson, “The Relation of Strength of
Stimulus to Rapidity of Habit Formation,” J. Comparative and
Neurological Psychology, vol. 18, pp. 459-482, 1908.
[10] W.E. Scott, “Activation Theory and Task Design,”
Organizational
Behavior and Human Performance, vol. 1, pp. 3-30, 1966.
[11] R.A. Dienstbier, “Arousal and Physiological Toughness:
Implica-
tions for Mental and Physical Health,” Psychological Rev., vol.
96,
no. 1, pp. 84-100, 1989.
[12] H. Anisman and Y. LaPierre, “Neurochemical Aspects of
Stress
and Depression: Formulations and Caveats,” Psychological
Stress
and Psychology, R.W. Neufeld, ed., McGraw-Hill, 1982.
[13] J. Schaubroeck and D.C. Ganster, “Chronic Demands and
Responsivity to Challenge,” J. Applied Psychology, vol. 78, no.
1,
pp. 73-85, 1993.
[14] M. Frankenhaeuser and B. Gardell, “Underload and
Overload in
Working Life: Outline of a Multidisciplinary Approach,” J.
Human
Stress, vol. 2, no. 3, pp. 35-46, 1976.
[15] R.W. Zmud, “Management of Large Software Development
Efforts,” MIS Quarterly, vol. 4, no. 2, pp. 45-55, 1980.
[16] D.R. Jeffery, “Time-Sensitive Cost Models in the
Commercial MIS

Environment,” IEEE Trans. Software Eng., vol. 13, no. 7, pp.
852-
859, July 1987.
[17] L.H. Putnam, “A General Empirical
Solution
to the Macro
Software Sizing and Estimating Problem,” IEEE Trans.
Software
Eng., vol. 4, no. 4, pp. 345-360, July 1978.
[18] B.W. Boehm, Software Engineering Economics. Prentice-
Hall, 1981.
[19] F.P. Brooks, The Mythical Man Month: Essays on Software
Engineer-
ing. Addison-Wesley, 1974.
[20] C.S. Raghavendra and S. Hariri, “Reliability Optimization
in the
Design of Distributed Systems,” IEEE Trans. Software Eng.,
vol. 11,
no. 10, pp. 1184-1193, Oct. 1985.

[21] G. Ruhe and M.O. Saliu, “The Art and Science of Software
Release
Planning,” IEEE Software, vol. 22, no. 6, pp. 47-53, Nov./Dec.
2005.
[22] Q. Hu, R.T. Plant, and D.B. Hertz, “Software Cost
Estimation
Using Economic Production Models,” J. Management
Information
Systems, vol. 15, no. 1, pp. 143-163, 1998.
[23] B.A. Kitchenham, “Empirical Studies of Assumptions That
Underlie Software Cost-Estimation Models,” Information and
Software Technology, vol. 34, no. 4, pp. 211-219, 1992.
[24] R.D. Austin, “The Effects of Time Pressure on Quality in
Software
Development: An Agency Model,” Information Systems
Research,
vol. 12, no. 2, pp. 195-207, 2001.
[25] K.T. Abdel-Hamid and E.S. Madnick, “Lessons Learned
from
Modeling the Dynamics of Software Development,” Comm.
ACM,

vol. 32, no. 12, pp. 1426-1455, 1989.
[26] W.S. Humphrey, A Discipline for Software Engineering.
Addison-
Wesley, 1995.
[27] R.D. Banker, G.B. Davis, and S.A. Slaughter, “Software
Develop-
ment Practices, Software Complexity, and Software
Maintenance
Performance: A Field Study,” Management Science, vol. 44, no.
4,
pp. 433-451, 1998.
[28] K.T. Abdel-Hamid, “The Economics of Software Quality
Assur-
ance: A Simulation-Based Case Study,” MIS Quarterly, vol. 12,
no. 3, pp. 395-411, 1988.
[29] K.T. Abdel-Hamid, “The Dynamics of Software Projects

Staffing:
A System Dynamics Based Simulation Approach,” IEEE Trans.
Software Eng., vol. 15, no. 2, pp. 109-119, Feb. 1989.
[30] K.T. Abdel-Hamid, K. Sengupta, and D. Ronan, “Software
Project
Control: An Experimental Investigation of Judgment with
Fallible
Information,” IEEE Trans. Software Eng., vol. 19, no. 6, pp.
603-612,
June 1993.
[31] K.T. Abdel-Hamid, K. Sengupta, and C. Swett, “The
Impact of
Goals on Software Project Management: An Experimental
Investigation,” MIS Quarterly, vol. 23, no. 4, pp. 531-555,
1999.
[32] M.E. Helander, Z. Ming, and N. Ohlsson, “Planning
Models for
Software Reliability and Cost,” IEEE Trans. Software Eng., vol.
24,
no. 6, pp. 420-434, June 1998.
[33] S. McConnell, “Feasibility Studies,” IEEE Software, vol.

15, no. 3,
pp. 119-120, May/June 1998.
[34] K. Srinivasan and D. Fisher, “Machine Learning
Approaches to
Estimating Software Development Effort,” IEEE Trans.
Software
Eng., vol. 21, no. 2, pp. 126-137, Feb. 1995.
[35] J. Singh, “Striking a Balance in Boundary-Spanning
Position: An
Investigation of Some Unconventional Influences of Role
Stressors
and Job Characteristics on Job Outcomes of Salespeople,”
J. Marketing, vol. 62, no. 3, pp. 69-86, 1998.
[36] M.G. Weinberg, The Psychology of Computer
Programming. Van
Nostrand Reinhold Company, 1971.
[37] H. Selye, The Stress of Life. McGraw-Hill, 1956.
[38] R.G. Stennett, “The Relationship of Performance Level to
Level of
Arousal,” J. Experimental Psychology, vol. 54, no. 1, pp. 54-62,

1957.
[39] R.N. Berry, “Skin Conductance Levels and Verbal Recall,”
J. Experimental Psychology, vol. 63, pp. 275-286, 1962.
[40] E. Duffy, Activation and Behavior. Wiley, 1962.
[41] J.E. McGrath, “Stress and Behavior in Organization,”
Handbook of
Industrial and Organizational Psychology, M.D. Dunnette, ed.,
pp. 1351-1395, John Wiley, 1976.
[42] H. Sjoberg, “Interaction of Task Difficulty, Activation and
Work
Load,” J. Human Stress, vol. 3, no. 1, pp. 33-38, 1977.
[43] J.R.P. French Jr., R.D. Caplan, and W. Harrison, The
Mechanisms of
Job Stress and Strain. John Wiley, 1982.
[44] M. Erez and I. Zidon, “Effects of Goal Acceptance on the
Relationship of Goal Setting and Task Performance,” J. Applied
Psychology, vol. 69, no. 1, pp. 69-78, 1984.
[45] M. Csikszentmihalyi, “Play and Intrinsic Rewards,” J.
Humanistic

Psychology, vol. 15, no. 3, pp. 41-63, 1975.
[46] M. Csikszentmihalyi, Beyond Boredom and Anxiety.
Jossey-Bass,
1977.
[47] E.A. Locke and G.P. Latham, “Building a Practically
Useful
Theory of Goal Setting and Task Motivation,” Am.
Psychologist,
vol. 57, no. 9, pp. 705-717, 2004.
[48] C.N. Parkinson, Parkinson’s Law and Other Studies in
Administra-
tion. Random House, 1957.
[49] G. Gutierrez and P. Kouvelis, “Parkinson’s Law and Its
Implica-
tions for Project Management,” Management Science, vol. 37,
no. 8,
pp. 990-1001, Aug. 1991.
[50] R. Rodgers and J. Hunter, “Impact of Management by
Objectives
on Organizational Productivity,” J. Applied Psychology, vol.

76,
no. 2, pp. 322-336, 1991.
[51] A. O’Leary-Kelly, J. Martocchio, and D. Frink, “A Review
of the
Influence of Group Goals on Group Performance,” Academy of
Management J., vol. 37, no. 5, pp. 1285-1301, 1994.
[52] R. Baum, E. Locke, and K. Smith, “A Multi-Dimensional
Model of
Venture Growth,” Academy of Management J., vol. 44, no. 2,
pp. 292-
303, 2001.
[53] K.H. Price, “Decision Responsibility, Task Responsibility,
Iden-
tifiability, and Social Loafing,” Organizational Behavior and
Human
Decision Processes, vol. 40, no. 3, pp. 330-345, 1987.
[54] S. Ang and S.A. Slaughter, “Work Outcomes and Job
Design for
Contract versus Permanent Information Systems Professionals
on
Software Development Teams,” MIS Quarterly, vol. 25, no. 3,

pp. 321-350, 2001.
[55] S. Nollen and H. Axel, Managing Contingent Workers. Am.
Management Assoc., 1996.
[56] J. Pfeffer and J. Baron, “Taking the Workers Back Out:
Recent
Trends in the Structuring of Employment,” Research in
Organiza-
tional Behavior, B. Staw and L.L. Cummings, eds., JAI Press,
1988.
[57] D.P. Darcy, C.F. Kemerer, S.A. Slaughter, and J.E.
Tomayko, “The
Structural Complexity of Software: Testing the Interaction of
Coupling and Cohesion,” IEEE Trans. Software Eng., vol. 31,
no. 11,
pp. 982-995, Nov. 2005.
[58] L.G. Robert, “Evolving a New Theory of Project Success,”
Comm.
ACM, vol. 42, no. 11, pp. 17-19, 1999.
[59] N.E. Fenton and S.L. Pfleeger, Software Metrics: A
Rigorous and

Practical Approach. Int’l Thompson Computer Press, 1997.
[60] R.D. Banker, H. Chang, and C. Kemerer, “Evidence on
Economies
of Scale in Software Development,” Information Software
Technol-
ogy, vol. 36, no. 5, pp. 275-282, 1994.
[61] R.D. Banker and S.A. Slaughter, “A Field Study of Scale
Economies in Software Maintenance,” Management Science,
vol. 43, no. 12, pp. 1709-1725, 1997.
[62] A.J. Albrecht and J.E. Gaffney, “Software Function, Source
Lines
of Code, and Development Effort Prediction: A Software
Science
Validation,” IEEE Trans. Software Eng., vol. 9, no. 6, pp. 639-
648,
Nov. 1983.
[63] C.F. Kemerer, Software Project Management Readings and
Cases.
McGraw-Hill, 1997.
[64] M.S. Krishnan, C.H. Kriebel, S. Kekre, and T.

DB#9 & DB#10.docx· · · · · · · · · DB#9 Cost.docx

DB#9 & DB#10.docx· · · · · · · · · DB#9 Cost.docx

Recommended

Recommended

More Related Content

Similar to DB#9 & DB#10.docx· · · · · · · · · DB#9 Cost.docx

Similar to DB#9 & DB#10.docx· · · · · · · · · DB#9 Cost.docx (20)

More from simonithomas47935

More from simonithomas47935 (20)

Recently uploaded

Recently uploaded (20)

DB#9 & DB#10.docx· · · · · · · · · DB#9 Cost.docx