Project Management Tools
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.
d. Failure to meet the plan equals an annual evaluation issue.
ii. If payroll dollars become a touchy topic (e.g., salaries), then use hours as a substitute.
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:
- The supplier presents a service or part concept and customer selects them.
- Internal engineering or process design generates the concept and out-sources to the supplier with appropriate supporting information.
- 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
- Customer satisfaction
- Risk philosophy
- Production material
- Material management
- Logistical systems
- Organizational structure
- Customers (most volume)
- Organizational awards
- Quality system
- Quality philosophy
- Quality planning
- Quality assurance methods
- Problem solving methods
- Research and development expenditures
- Existing product Parts Per Million (PPM) figures
- Existing product warranty statistics
- Historical product and project delivery information
- On-time delivery
- Cost of project
- Computer aided drafting (CAD)
- Computer aided manufacturing (CAM)
- Simulation and emulation tools
- Verification tools
- EDI capabilities
- Supplier reliability
- Product development
- Development personnel (skills)
- Product development processes
- Development tools and systems
- Prototype availability
- Design change handling
- Project management
- Project processes
- Human resources
- Project change management
- 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|
|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:
- Breaks the project down into the lowest components
- Helps with the development of duration estimates
- Aids development of resource assignments and responsibilities (identifies skills and skill acquisition needs)
- Facilitates risk identification and mitigation
- Identifies tasks supporting activities for the design
- 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|
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
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
- Required software reliability
- Size of application code
- Complexity of the product
- Hardware attributes
- Performance demands
- Memory demands
- Required turnabout time
- Personnel attributes
- Software team capability
- Application type experience
- Programming experience
- Level of teamwork
- Organization attributes
- Team distribution (collocated or distributed)
- Process maturity
- Project attributes
- Amount of code reuse
- Use of software tools
- Application of software engineering methods
- 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:
c. Coding and testing
ii. Degree of difficulty
iii. Interfaces to other subsystems
vi. Hardware constraints
d. Integration testing
iii. Testing efficiency
i. Test environment (availability)
e. Other Disciplines
a. Development process
3. Program constraints
b. Development system
iii. Process control
v. Product control
c. Management process
vi. System support
d. Management methods
ii. Project organization
iii. Management experience
iv. Program interfaces
e. Work environment
ii. Personnel management
iii. Quality assurance
iv. Configuration management
i. Quality attitude
ii. Human resource
i. Type of contract (fixed, etc.)
c. Program interfaces
ii. Contractors and subcontractors
iii. Corporate management
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.
- Identify potential risks
- Analyze risk effect
- Plan and develop mitigation methods
- Track or monitor for risk occurrence
- 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:
- Risk acceptance - accepting the risk as it matures.
- Risk transference - assigning the risk to another (the other may be more capable)
- Risk avoidance - using other strategies to remove the risk
- 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.
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.
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.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:
- Sufficient breakdown of budget allowing linking of the WBS to the budget
- Correct billing of hours to tasks
- Quick response from the hour billing system (latency between when time is put in and when it is visible)
- 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 > 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 > 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:
- The program manager needed a contingency plan to handle lost member situations.
- The subsequent counterproductive arguing added no value to the product or project and had a negative impact upon team morale.
- 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.
1Dr. 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).
2Defense Acquisition University Press, Systems Engineering Fundamentals, (Fort Belvoir, Virginia, Dau 2001) p. 118.
About the Author
From Project Management of Complex and Embedded Systems: Ensuring Product Integrity and Program Quality by Kim Pries and Jon Quigley.