Project Management Tools

by Kim Pries and Jon Quigley

1 Delivery

1.1 Axioms of Program Management

We start off this chapter with a tongue-in-cheek collection of "axioms" that sum up some of the more critical realizations
we had during numerous projects.

1. All time lines belong to a directed graph

a. The network diagram has more importance than the Gantt chart because it more adequately represents the relations of
the tasks and deliverables.
b. Microsoft Project does a poor job of supporting the network diagram.
i. Fix this situation with PERT Chart Pro from CriticalTools.com, a Project® plug-in.

2. To calculate a critical path correctly, we must have

a. One entrance point

b. One exit point
c. All other tasks connected to at least one other task at the beginning and end of the task
d. Program managers who do not use the term "critical path" unless they understand what it means
e. Use Microsoft Project so that it does not provide an illusory critical path-BEWARE!

3. Baseline all time lines once the plan has approval.

a. Alter no plan without exposure at the executive level.

b. All functional managers must deliver a complete plan no later than the planning gate of the project.
c. Measure plans according to the standard metrics as defined in chapter 15 of Kerzner's Project Management, 8th or 9th
edition [Kerzner 2001].
i. Use earned value analysis-supported by Microsoft Project and Primavera Project Planner.
ii. If payroll dollars become a touchy topic (e.g., salaries), then use hours as a substitute.
d. Failure to meet the plan equals an annual evaluation issue.

4. The project manager should create plans at as fine a granularity as possible so that the completion of tasks becomes a
binary choice and the percentage completion indicator of the Microsoft Project software actually means something.

5. Program managers should manage deliverables not tasks.

a. Functional managers hold responsibility for task completion.

b. Delivery either exists or not (binary).

6. Hard-schedule all gates when the team agrees to take on the business.

7. All of the consensus management areas are the responsibility of the project manager, not just arbitrarily laid out in the
schedule.

8. Any launch process serves us better than no launch process.

9. Build slack into the time line from the start of the program and manage it with great care.

1.2 Supplier Selection

Whether the suppliers are outsourced services or actual manufacturing suppliers, they always remain significant to the
project because they participate just as much in the result as any other resource. In some cases, the corporate customer
may dictate the choice of suppliers, which can lead to major problems when those suppliers become unreliable.
The bases for choosing a supplier can vary, as in the following:

1. The supplier presents a service or part concept and customer selects them.
2. Internal engineering or process design generates the concept and out-sources to the supplier with appropriate
supporting information.

3. The enterprise selects the supplier due to an ongoing relationship.

The next section illustrates various methods of evaluating a supplier. We use a combination of in-house methods and
standards. However, while the acquisition function selects the supplier, the project manager should know and assess the
risk involved with each part or service and with each supplier.

1.2.1 Supplier Evaluation

Selection of a supplier relies on numerous factors-many of the evaluation criteria depend on the economic performance
and the stability of the supplier. Some companies have effective evaluation methods for the economics of the
organizations. Other organizations also have effective engineering evaluation criteria. However, often a gap exists in the
evaluation standards, particularly for embedded software development. Key development tool requirements may not
appear in these supplier evaluations.

In the case of services, obvious presentation of requirements in the form of mechanical drawings makes no sense. A
service company may need to create a specification or a statement of work to provide enough information for an
outsourced service to provide a quote.

The evaluation grades the supplier's capabilities. For each category, there may be multiple choices to quantify the
supplier's capability with respect to project requirements. The evaluation team will associate a score with each of these
possibilities, particularly in the case of government contracts. The sum of these scores represents the supplier's
capabilities.

The supplier evaluation does not select the supplier; rather, the scores developed during the acquisition process provide
an ordinal list of supplier capabilities. In the automotive industry, a group consisting of representatives from the Supplier
Quality Assurance (SQA) function, technical expertise from the design staff, and the acquisition function (for example, the
purchasing department) performs the supplier evaluation. Team members should participate in this evaluation in order to
provide the project manager with a preliminary understanding of the strengths and weaknesses of the supplier.

In the case of software acquisition, internal methods of selecting suppliers often do not evaluate the supplier in key
software practices. Instead, the review or critique relates more to the supplier's financial and production constraints. The
choice of software supplier based solely on financial data can be myopic and reflective of insufficient technical
involvement in the acquisition activity.

The following list provides some of the factors for consideration in the supplier evaluation:

 Company ownership
 Affiliated organizations or parent organizations

 Facilities (global or regional)

 Sales turnover

 Net income

 Management expertise

o Customer satisfaction

o Risk philosophy

 Production material

o Material management

o Logistical systems
 Organizational structure

 Customers (most volume)

 Organizational awards

 Quality system

o Quality philosophy

o Quality planning

o Quality assurance methods

o Problem solving methods

 Research and development expenditures

 Existing product Parts Per Million (PPM) figures

 Existing product warranty statistics

 Historical product and project delivery information

o On-time delivery

o Cost of project

 Tools

o Computer aided drafting (CAD)

o Computer aided manufacturing (CAM)

o Simulation and emulation tools

o Verification tools

 EDI capabilities

 Supplier reliability

 Product development

o Development personnel (skills)

o Product development processes

o Development tools and systems

o Prototype availability

o Design change handling

 Project management

o Organization

o Project processes

o Human resources

o Project change management

 o Subcontractor performance management

1.2.2 Capability Maturity Model Integrated

Developers use the capability maturity model integrated (CMMI) method in evaluating software or engineering suppliers.
The model purports to assess the maturity of various tasks within an organization-not only software-and applies a score. A
complete auditing standard exists for this approach. However, little research supports this model as a significant
evaluation tool for assessing the software development of a supplier; that is, the project manager or team can assess
maturity of the development process, but it cannot directly assess the software itself.

Table 1 CMMI Levels and Characteristics

Maturity Level Level Name Process Characteristic

1 Performed process Chaotic
2 Managed process Disciplined
3 Defined process Repeatable
4 Quantitatively managed process Controlled via statistics
5 Optimizing process Continually improving

1.2.3 Software Process Improvement and Capability dEtermination

Software Process Improvement and Capability dEtermination (SPICE) has evolved into ISO/IEC 15504, a model similar to
the CMMI. In fact, the SPICE effort in Europe probably influenced the older capability maturity model (CMM) to evolve into
the CMMI.

1.3 Work Breakdown Structure

Initial scope containment actions identify those activities needed to ensure the scope of the project does not submerge
within the processes of the project.

The work breakdown structure (WBS) takes the top-level deliverables of the project and functionally decomposes these
items into a hierarchical representation of the final product. In U.S. Department of Defense (DoD) vernacular, the WBS
provides cost centers for cost and schedule tracking of the project. The team should refer to the lowest element in the
WBS as a work package. The decomposition of tasks needed to produce the project objectives allows for detailed
estimations of project costs.

Additionally, the team can match the work packages against available resources to provide a more complete assessment
of the feasibility of the project. Decomposing cost centers to some atomic level, for example, where we have estimates
between eight hours and eighty hours usually improves the accuracy of the forecast. What follows is a benefits list for any
WBS when allied with a bill of resources:

1. Breaks the project down into the lowest components

2. Helps with the development of duration estimates

3. Aids development of resource assignments and responsibilities (identifies skills and skill acquisition needs)

4. Facilitates risk identification and mitigation

5. Identifies tasks supporting activities for the design

6. Identifies tasks for support plans such as configuration management, quality assurance, and verification and
validation plans.

In order to perform effective estimation of the duration of a task, the project manager needs an in-depth understanding of
both the requirements and the required actions. Therefore, the estimates should flow up from those resources that
execute these tasks; that is, the team members and their managers provide their own estimates. The estimates may be
measured by:

 Time, in the form of hours or days,

 Money, in the form of dollars,

 Person-hours, a combination form.

Work package estimation occurs more quickly with the use of a complete WBS-these atoms simplify the process of
estimation because they depict small, comprehensible actions. Sometimes, the team member (executor) does not
estimate, but rather a technical expert or the project manager will estimate. Bringing in a "pinch hitter" adds little value to
the derivation of good estimates-the person who will complete the task should perform the estimates! In so doing, the
team increases the likelihood of commitment to that task; participation in the estimation process encourages ownership of
the results, converting the players on the team from victims to participants.

Note that we posit work package estimation as a dynamic process designed to produce meaningful results. Having the
project manager dictate the desired schedules to the team while ignoring contributions from team members demotivates
the project team. We see an example WBS in Figure 1.

Figure 1 Part of a work breakdown structure (WBS).

1.4 Resource Breakdown Structure

After the planning team creates the WBS, the project manager in concert with the team will identify and assign the
resources needed to undertake the individual work packages, identifying skills and assigning responsibilities. A resource
allocation matrix (sometimes called a "bill of resources"), Figure 2, can help to convey the areas of responsibilities to the
project team.

It may be naive to believe that people assigned to the project work solely on their project tasks. Personal efficiency and
normal interactions consume part of each working day, implying full utilization as impossible even under ideal
circumstances. If a person works half-time on a deliverable, one can assume it will take at least twice as long to complete
that task. In this case, the team assumes little or no disruption in the transition from the other tasks, a possibly unrealistic
option.
Figure 2 Example of resource breakdown structure.

The project manager would be wise to document utilization assumptions. These assumptions allow for more accurate
predictions and also give visibility to the actual workloads. Keep in mind that the cost and schedule assumptions represent
a model of what the project manager desires.

The project manager should be wary of cases where an individual with a penchant for overwork takes on all tasks and
fails-the principal defect of infinite-loading models. Our approach to the management of human resource constraints
appears in Figure 3.
Figure 3 Example of accumulated Human Resource (HR) expense.

1.5 Project Estimating and Scheduling

When the project manager estimates a project with his team, he can usually estimate cost and schedule while setting
target values for quality. Figure 2.3 shows an example of how the cost of a project accumulates.

1.5.1 Top-Down Estimating

Top-down estimating relies on historical project budgeting. The project manager can apply this method when the historical
project attributes resemble the current project. If an instrument cluster development project always costs $2 million then
this amount would be budgeted and distributed among project phases, distributed in the proportions suggested by past
projects. Below we illustrate a possible budget distribution using this method.

Table 2 Budget by Phase (Top-Down Estimating)

Project Phase Percent of Budget Dollar

Voice of customer 5% $100,000
Product development 30% $600,000
Process development 30% $600,000
Product and process validation 35% $700,000
Total 100% $2,000,000

1.5.2 Bottom-Up Estimating

Bottom up estimating rolls up the WBS task durations. Once the project manager and team assign a duration and cost to
each task, the project manager compiles this information into a schedule and a budget. Individual team members
participate in the bottom up approach, while higher-level managers and the project manager have editorial responsibility
over the estimates, providing a filter against wild inaccuracies and simple mistakes.

1.5.3 Phased Estimating

As each phase terminates, the project manager and team revise or recalculate estimates with additional information from
the previous phase. Each subsequent phase increases the details for the next and improves the estimates. In short,
actual events consume the forecast (schedule and cost).

We describe project management as a process of progressive elaboration. In the early phases of a project, the entire
team moves into the unknown. They may have nebulous scoping details. As events consume the forecast, the project
manager replaces vague estimation with real data and the remaining forecast improves in quality.
If upstream management interferes with the project by dictating a compressed schedule or a reduced budget, the
likelihood of a successful project diminishes. Unrealistic due dates degrade the quality of the schedule and unrealistic
budgets degrade the value of project costing. Higher-level interference can destroy the sense of ownership in a team by
shrinking the perception of participation and demeaning the contribution of team members.

Additionally, crashing (or reducing) the schedule generally fails to account for the effect of random variation on the project
plan. In retaliation or expectation, some project managers react by padding their estimate; that is, inserting safety lead
time to increase the likelihood of task completion.

Unfortunately, padding produces a distortion in the estimates of both time and cost. An even worse situation occurs when
the upstream managers begin to assume the project managers padded the budgets and routinely call for schedule and
budget attenuation.

1.5.4 Project Evaluation and Review Technique

While some elements of a project may recur from project to project, such as a well-defined software release process,
many elements occur as "one-off" activities. The project manager can use recurrent elements to enhance the accuracy of
the forecast due to the reduced uncertainty of the estimates.

Asserting the duration of a non-recurrent task as a single value implies extensive foreknowledge. Describing the task
duration as a range of possibilities reflects the uncertainty of project execution. The program evaluation and review
technique (PERT) uses a network analysis based on events defined within the project and addresses one-off durations; it
allows the project team to express durations as a span of likelihoods. The U.S. DoD classifies estimates as pessimistic,
optimistic, and probable. The team weighs its classifications with the heaviest weight going to the most probable scenario.

The PERT equation appears as follows:

Duration = [(Pessimistic + 4 * Most probable + Optimistic)/6]

Note that the formula hints at a potentially unjustified normal distribution around the most probable scenario.

The PERT technique provides a framework for simulation. A software tool (@RISK®) exists that provides simulation
capability to Microsoft Project. The PERT estimation technique also provides the project manager with a glimpse of the
uncertainty of the estimates. However, the range of values (Pessimistic-Optimistic) provides a strong indicator of the
certainty used by the estimator. The project manager will convert this value into the task variance using the equation
below. The larger the task variance, the more uncertain the estimate:

TaskVariance = [(Pessimistic - Optimistic)/6]2

Variations in the three PERT estimates imply uncertainty. However, if the project manager assumes the estimate of time
follows a normal distribution, then he can refine or broaden the estimates. Taking the individual estimates to the one, two,
three, or six standard deviations (sigma or ?) spreads the available time and improves the probability that the estimate lies
within the range of dates. See the table below:

Table 3 Sigma and Probability

1-sigma 68.26%
2-sigma 95.46%
3-sigma 99.73%
6-sigma 99.99+ %

The following Figure 4 illustrates the effect of variation. For a confidence interval of 99.73 percent, the range of
possibilities varies from 3 hours to 19.7 hours. Estimates with substantial variation should be removed from the critical
path or receive risk mitigation. Critical path dates with high variation represent risky goals. PERT models become
complicated because the software must iterate through permutations of the three levels-the more tasks/deliverables, the
longer it takes for the model to converge.
Figure 4 Duration estimation technique.

1.5.5 Critical Path Method (CPM)

We define the critical path as the longest duration path in the network diagram-the longest cumulative, connected,
slackless lead-time through the project-which means it represents the shortest period of time in which the project can be
completed. Those tasks on the critical path remain key to delivering the project. The critical path approach calculates the
earliest project finish date. The critical path behaves dynamically and may change during the project. The critical path
possesses no slack time (the amount of time an activity can be delayed without delaying the early start date of the next
task).

The critical path approach suggests that management of slack becomes crucial to the success of a project. The
measurement of slack provides us with a risk indicator. As slack dwindles, the project moves toward collapse.

The critical path approach may focus too much on problems as they arise, and less on preventing potential problems.
Modern project management software can calculate the critical path quickly and represent it graphically. Software that
calculates multiple critical paths treats the project as a metaproject composed of other projects.

1.5.6 Network Diagram in General

For planning purposes, the network diagram becomes more important than the more common Gantt chart seen in
software programs that support project management. Mathematically, the network diagram derives from the concept of a
directed graph.

The failure to properly connect the network diagram is probably the single most common scheduling failure by project
managers. We started this chapter with some axioms specific to this problem. If the program manager does not connect
the tasks based on dependencies, A must complete before B can start, then the software will inaccurately represent the
critical path (see Figure 5). Alternatively, an independent task has no dependencies and the team can execute it
immediately. If such is not the case, the task is not independent.

Figure 5 Task dependencies.

Figure 6 shows the network diagram for the same pseudoproject we used to show the WBS.
Figure 6 Network diagram.

1.5.7 Constructive Cost Model II

Even using the aforementioned techniques, duration estimation is still a guess activity. It is possible to develop an
association between the activity, the person conducting the activity, and the organization processes. Compiling this
information over time allows the project manager or the line organization manager to be able to make some qualifying
statements about the validity of the estimates.

Dr. Barry Boehm and a team of others have created mathematical models for just this sort of estimation methodology on a
grand scale with a process known as Contructive Cost Model (COCOMO), and COCOMO II. 1 This model is very complex
and cannot be adequately handled within a section of a project management book. However, we provide the list below
(not exhaustive) to get a perspective on the number of variables that impact the estimation process. Each variable has a
number of possibilities or grades. It is no wonder software schedule estimates have accuracy issues.

 Product attributes
o Required software reliability

o Size of application code

o Complexity of the product

 Hardware attributes

o Performance demands

o Memory demands

o Required turnabout time

 Personnel attributes

o Software team capability

o Application type experience

 o Programming experience

o Level of teamwork

 Organization attributes

o Communications

o Team distribution (collocated or distributed)

o Process maturity

 Project attributes

o Amount of code reuse

o Use of software tools

o Application of software engineering methods

o Required development schedule

2 Product Integrity and Reliability

2.1 Risk Management

Figure 7 illustrates, in general, the relationship between the project phase risk probability and financial effect. This may
seem to run counter to expectations. However, consider the longer the time the project runs, the more is invested in terms
of time and money. Further, the more decisions are made and directions taken, the fewer alternatives or solutions are
possible. Therefore, while risk may go down as the project progresses, the consequences of those risks have more at
stake.

Figure 7 Risk probability and effect potential.

2.1.1 Risk Taxonomy

Risk management takes a significant amount of time and effort from a project manager. In fact, from one perspective,
project management is the art of risk management. The following brief list shows common internal risk areas:
1. Engineering

a. Requirements
i. Stability
ii. Completeness
iii. Clarity
iv. Validity
v. Feasibility
b. Design
i. Functionality
ii. Degree of difficulty
iii. Interfaces to other subsystems
iv. Performance
v. Testability
vi. Hardware constraints
vii. Software
c. Coding and testing
i. Feasibility
ii. Coding
iii. Testing efficiency
iv. Implementation
d. Integration testing
i. Test environment (availability)
ii. Product
iii. System
e. Other Disciplines
i. Maintainability
ii. Reliability
iii. Producibility
iv. Safety
2. Development
a. Development process
i. Formality
ii. Suitability
iii. Process control
iv. Familiarity
v. Product control
b. Development system
i. Capacity
ii. Suitability
iii. Usability
iv. Familiarity
v. Reliability
vi. System support
vii. Deliverability
c. Management process
i. Planning
ii. Project organization
iii. Management experience
iv. Program interfaces
d. Management methods
i. Monitoring
ii. Personnel management
iii. Quality assurance
iv. Configuration management
e. Work environment
i. Quality attitude
ii. Cooperation
iii. Communication
iv. Morale
3. Program constraints
a. Resources
i. Schedule
ii. Human resource
iii. Budget
iv. Facilities
v. Equipment
b. Contract
i. Type of contract (fixed, etc.)
ii. Restrictions
iii. Dependencies
c. Program interfaces
i. Customer
ii. Contractors and subcontractors
iii. Corporate management
iv. Vendors
v. Politics

2.1.2 Risk Methodology

We itemize some ways to manage exposure to risk in the list below. The strategy selected depends on the organization
and the risk management philosophy.

1. Identify potential risks

2. Analyze risk effect

3. Plan and develop mitigation methods

4. Track or monitor for risk occurrence

5. Control the risk by invoking planned risk response

Risk mitigation is the art of reducing potential effects on the project. Below we show four ways to cope with risk:

1. Risk acceptance - accepting the risk as it matures.

2. Risk transference - assigning the risk to another (the other may be more capable)

3. Risk avoidance - using other strategies to remove the risk

4. Risk mitigation - executing actions to reduce the risk

2.1.3 Risk Quantification

A probabilistic concept composed of the following: defines risk

Risk = event probability × event effect

Risk = probability × cost

Usually, the estimate of the event occurrence has coarse granularity. However, this kind of preliminary quantification
provides managers with enough information to make a decision.

The project manager can estimate multiple risks by multiplying estimates if he assumes independent events. He can look
at an example of how this might work. Let's say it becomes necessary to write the specification for the product before a
review with key personnel. To achieve the delivery date, he must have the specification written in a specific period Risk1
and have the review Risk2 within a certain period also.

Risktotal = Risk1 × Risk2

Risktotal = 0.90 × 0.90
Risktotal = 0.81

In this example, the probability of achieving the objective of having the specification completed and reviewed amounts to
81 percent.
The project manager can use probabilistic tools such as @RISK and Crystal Ball® to model the project/program using a
spreadsheet such as Microsoft Excel® or a project management tool like Microsoft Project. These tools allow the user to
run Monte Carlo simulations of the sequences of events and earned value. If the enterprise has a policy of retaining
historical data of various projects, the project manager can choose the appropriate distributions to represent various
activities in the project (note: not everything follows the so-called "normal distribution"). If he does not know the
distributions or knows them poorly, the project manager can estimate some worst-case scenarios and apply a random
walk approach to the Monte Carlo simulations by modeling to uniform distributions.

2.2 Assessment of Product Risk

2.2.1 Simulation and Modeling

Simulation makes verification-like activities possible without the material costs. Simulation allows for testing theories and
product possibilities without making the actual part. This means it is possible to learn about the product, before much
money, time, and opportunity have been sunk into the product (see Figure 8). Simulation allows you to adjust the product
to better meet customer needs without great tooling costs. However, simulation is only as good as the material of which it
is built. The advantages of simulation are great and allow for risk and cost reductions early in the project.

Figure 8 Simulation.

When there are many variations of the system under design, or when the system under design has to interface or is part
of a system with many variations, simulation can reduce the logistics around obtaining each of these variations for
verification.

There are three types of simulations:2 1. Virtual simulations represent systems both physically and electronically. 2.
Constructive simulations represent a system and its employment. 3. Live simulations simulated operations with real
operators and real equipment.

Virtual simulation is used to develop requirements by getting feedback on the proposed design solution. Virtual
simulations put the human-in-the-loop. The operator's physical interface with the system is duplicated, and the simulated
system is made to perform as if it were the real system. The operator is subjected to an environment that looks, feels, and
behaves like the real thing.2

Constructive simulation is just that, simulating the construction of the proposed solutions. This approach allows quick
design changes to be reviewed for impact. Performance information can be distributed to the rest of the team.

Live simulation require the hardware and software to be present. In these simulations, the situations or ambient
environment is simulated allowing the system to be checked out under various operational situations. The intent is to put
the system, including its operators, through an operational scenario, where some conditions and environments are
mimicked to provide a realistic operating situation.2
Simulation pitfalls Simulation and modeling are only as good as the input data. Models must represent the key variables
that produce the appropriate systems performance. Additionally, modeling and simulation are specialty knowledge areas.
This means the skill set is not often readily available and can be very industry specific. Still, starting earlier, clarifying
concepts and requirements means this is a wonderful tool to help produce the product in a timely fashion and at the
desired quality.

2.2.2 Verification
Any verification of the product, process, or service will provide some data about these products. The project manager
must understand that the product, process, or service is a prototype that may not represent the result. However, the
purpose of material and process prototypes lies in the reduction of risk to the production of the product or service.

2.2.3 Validation
Validation further reduces risk by examining the product or service under more realistic conditions and at a further stage
of development. If the embedded team has the software product built, it can model the defect arrival rate with a Rayleigh
model and provide the program manager with a statistical basis for final release.

2.2.4 Stress Testing

In addition to verification and validation, the team may opt to stress the product or service beyond design limits to
characterize performance. Stress testing also yields important data about weak points in the product or service.

2.2.5 Reliability Testing

Reliability testing attempts to assess the behavior of the product or service at some specified time. The goal of reliability
testing is observable degradation. Under special conditions, the team can model the rate of degradation and predict the
life of the product or service.

3 Cost

3.1 Project Acceptance Criteria

The evaluation of economic gain from a project resembles other corporate investments. The typical criteria are return on
investment (ROI), internal rate of return (IRR), or other financial requirements (see Figure 9). Some organizations use
multiple acceptance criteria, for example IRR and payback period. However, sometimes the enterprise will drive a project
for a new strategic relationship with a customer, while not meeting financial expectations. Understanding the rationale for
a project allows the project team to comprehend the purpose of the project.

Figure 9 Project acceptance.

3.2 Payback Period

The payback period is the amount of time it takes to return the money spent for the project. If the enterprise spends
$100,000 and it makes $20,000 in profit on the product every year, it would take five years to return all of the development
monies incurred by the project with the assumption of no effect from inflation. The sooner this payback happens, the more
quickly the company makes a profit on the product. Payback period provides a quick means for assessing the cost of a
project especially if the payback period calculates to less than one year. Inflation, taxation, and other accounting period-
related issues become less significant for short durations.

3.3 Return on Investment

Return on investment (ROI) in its simplest form is the ratio of the return or income from the project undertaken to the
investment in the project.

Return / Investment = %ROI

20,000 / 100,000 = 0.2

3.4 Internal Rate of Return (IRR)

Internal rate of return or IRR, is the annualized compounded return rate for the investment. If a project's rate of return is
better then the alternative uses of the funds, the project is deemed to be a good investment and acceptable. Will we make
more money investing in this project then another, or even another type of investment (bank or stocks)?
For Internal Rate of Return NPV = 0
-100 + (120 / ((1 + IRR / 100)1) = 0
IRR = 20

3.5 Market Share

Sometimes projects are not undertaken for a particular dollar amount, such as a ROI or IRR. Projects can be a useful
tactic for grabbing market share from a competitor or for achieving a long-range organizational strategy. The results may
be more difficult to quantify than ROI and IRR; however, given the investment, it has tremendous significance for the
future of the enterprise. Even when the project evolves into a strategic initiative, the board of directors will normally require
a link to the long-term profitability of the enterprise-board-level governance of corporations usually requires a rationale for
an initially unprofitable strategy and is frequently a regulatory obligation.

4 Project Cost Management

4.1 Earned Value Management

The cost control procedures define the process interactions and the tasks needed to manage the delivery of the project
costs. The team will need to deliver the product and process within the identified cost boundaries. Any change initiatives
should also be managed to the same limitations.

To be able to use earned value management (EVM) techniques, the processes and systems in place must at a minimum
have the following characteristics:

1. Sufficient breakdown of budget allowing linking of the WBS to the budget

2. Correct billing of hours to tasks

3. Quick response from the hour billing system (latency between when time is put in and when it is visible)

4. Definition of task progress, for example use 0 percent (not started)-50 percent (started)-100 percent (completed)
to quantify task disposition

4.1.1 Budget Controls

Some organizations do not have tight controls over the hours recorded by employees nor do they have links to the WBS.
The actual monetary status of the project may be indeterminate. Only those people working on specific WBS elements
should bill hours to those elements. It is just as important that those working on the WBS elements know the accounts to
which to bill the effort and do so. Failure to follow these provisos makes it challenging, if not impossible, to use EVM.

EVM arose from U.S. DoD cost accounting and is not unique to automotive development. Project managers use the
technique to assess the current cost/schedule status of the project. The tool evaluates the project schedule and cost
expenditures against the planned time and cost to determine the status of the project. The system requires detailed
preparatory work, most important of which is the WBS.

Let's assume that the project team has identified the scope, tasks, and estimates for the project. The most common name
for these variables is planned value since it shows expected expenditures for any given time. Other documents refer to
planned value as budgeted cost of work scheduled (BCWS). Once we have the planned value, we can compare it to the
actual cost. Other resources may refer to actual cost as actual cost of work performed (ACWP). The time reporting
systems have rigid constraints. The project manager must ensure that the people doing the work record their time
accurately.

The earned value is the budget at completion (BAC) multiplied by the percentage of completion of the project:

EV = BAC ? %Complete

4.1.2 Cost Performance Index

The cost performance index (CPI) is the ratio of earned value to the actual cost.

CPI = EV/AC

Table 4 CPI and Interpretations

CPI Description Project Status
CPI > 1 The money spent is less than the estimated amount to accomplish Cost estimates suspect
CPI = 1 The money spent is equal to the estimated amount to accomplish Project approval
CPI < 1 The money spent is greater than the estimated amount to accomplish Cost overrun

4.1.3 Schedule Performance Index

The schedule performance index (SPI) is the ratio of the work performed to the value of the work planned. An SPI of 1
means the project executes as planned.

Table 5 SPI and Interpretations

SPI Description Project Status

SPI > 1 The time to accomplish is less than the estimates Schedule estimates suspect
SPI = 1 The time to accomplish is equal to the estimates Project approval
SPI < 1 The time to accomplish is more than the estimates Behind schedule

Example: We plan four weeks to execute a given set of tasks and constrain planned cost to $16,000. After two weeks of
work, we accomplish 25 percent or $4,000 of the task

SPI = EV/PV
SPI = $4,000/$8,000
SPI = .5

4.1.4 Cost Variance (CV)

Cost variance (CV) is the dollar amount difference between actual spending and planned spending at specific points in the
project. The calculation provides quick feedback on whether the project spending occurs according to plan.

CV = EV - AC

Example: A certain set of tasks was budgeted to cost $4,000. When the tasks were accomplished, the money spent was
$6,000.

CV = EV - AC
CV = $4,000 - $6,000
CV = -$2,000

Table 6 CV and Interpretations

CV Description Project Status

CV > 1 The amount of money spent is less than the budget Budget estimates suspect
CV = 1 The amount of money spent is equal to the budget Budget approval
CV < 1 The amount of money spent is more than the budget Under budget

This means that the secured budget for this project is in trouble. There is a shortfall for this set of tasks that may perturb
the remainder of the project.

4.1.5 Schedule Variance (SV)

Schedule variance is much like cost variance in concept; however, in this case the dollar amount represents the specific
amount spent in relation to the project schedule.

SV = EV - PVR

4.1.6 Estimate at Completion

The project manager ensures that the stakeholders understand the project status. This includes informing those
stakeholders whether the present budget to complete the project is profitable and elucidating any significant trends.
$EAC = AC / % Completed

Table 7 SV and Interpretations

SV Description Project Status

SV > 1 The amount of time to accomplish is less than the allotted time Schedule estimates suspect
SV = 1 The amount of time to accomplish is equal to the allotted time On schedule
SV < 1 The amount of time to accomplish is more than the allotted time Behind schedule

Example: A project is budgeted to cost $200,000. It is not at the 20 percent completion mark and has spent $60,000.

$EAC = $60,000 / 20%

$EAC = $300,000

This simple equation provides a back-of-the-envelope check to see if the program is on, over or under budget. Clearly, the
project is in trouble.

4.1.7 Estimate to Complete

The amount of money needed to complete the project from the previous calculated project example is

$ETC = EAC - AC
$ETC = $300,000 - $60,000
$ETC = $240,000

4.1.8 Variance at Completion

Variance at completion (VAC) provides the dollar amount of the difference between what was originally planned to
accomplish the project to new realities discovered as a result of project execution.

$VAC = BAC - EAC

VAC = $200,000 - $300,000
VAC = -$100,000

Now, the example project will require an additional $100,000 to complete, if nothing else changes (for example, scope or
feature reduction).

4.2 Quality, Function, Deployment, and Cost Status

The project team may create custom tools due to pressures from within the project, a simple matter of creativity matching
needs. Figure 10 illustrates the key tasks by project phase. The figure does not present an exhaustive list but, rather, core
tasks identified in the automotive industry action group (AIAG) advanced product quality planning (APQP).
Figure 10 Project status.

5 War Story

5.1 Human Resource

At a critical point in the late stage of developing a new product, a key participant can leave the team or the enterprise.
This person may have been responsible for the design of the printed circuit board for a high-profile customer. The board
had already been laid out and was on its way to the board fabricator. (Note: this situation occurred before the auto-layout
feature was available to printed circuit board designers.) When the boards came back from the manufacturing facility, the
engineers discovered an error. An argument ensued about whose responsibility it was to verify the printed circuit boards.
Rather than finger-pointing, it would be more productive to focus on recovery instead of squabbling about responsibility.
The project manager should record incidents like this one so that it can be used for instruction:

1. The program manager needed a contingency plan to handle lost member situations.
2. The subsequent counterproductive arguing added no value to the product or project and had a negative impact
upon team morale.

3. The launch or change process had no control point in this portion of the process (control points generally involve
inspection of work), so the error propagated through the system.

5.2 Systems Thinking

A truck company launched a vehicle with the component outlay as shown below. The square component was a device
that converted the signals from one type of data communications to another. In addition, the green component worked
with a number of data busses and had the hardware on board the micro-controller to handle the bus interface. Software
would be required to make these components work together and omit the $30 module from the vehicle build while
retaining the functionality (see Figure 11).

Figure 11 Systems view.

This redundant and costly situation was avoidable by using a design review at the system or metalevel. Metalevel reviews
provide an opportunity for developers of embedded software, services, or manufacturables to reassess their work in light
of a higher-order systems approach. The review team assesses components for cooperative behavior. This cost reduction
should have been available earlier and would have been less than the cost to develop two different components to meet
the functional requirements.

5.3 Project Manager Words

In the course of a postproduction cost evaluation and improvement exercise, the project manager of the supplier made
statements regarding the cost of a particular component (a liquid crystal diode or LCD) within the product. The customer
had identified a supplier of the LCD as having a component of similar quality for much less. The prospect of using a much
less expensive component while maintaining the same level of performance and design requirements excited the
customer. After a quick investigation of the actual cost by the supplier, the money saved was much less and would not
have been cost effective to change within the product considering the cost of product qualification (testing, FMEA review,
etc.). In short, any time the project team makes a change, the total cost of change is a significant consideration.
Additionally, the team should review the impact of purchased components on the supply chain, given the difficulty of
planning for items with weeks- or months-long lead times.

Footnotes

1
Dr. Barry Boehm, Bradford Clark, Ellis Horowitz, Ray Madachy, Richard Shelby, and Chris Westland. April 1995.
Software Technology Conference, An Overview of the COCOMO 2.0 Software Cost Model.
http://sunset.usc.edu/research/COCOMOII/ (accessed February 16, 2008).
2
Defense Acquisition University Press, Systems Engineering Fundamentals, (Fort Belvoir, Virginia, Dau 2001) p. 118.