Project and Implementation Management

Introduction and Context

Industrial engineering projects convert an approved need into a measurable operational result. Examples include installing a production line, redesigning a warehouse, implementing enterprise software, reducing setup time, automating inspection, or introducing a maintenance-management system. Such projects differ from routine operations because they are temporary, contain uncertainty, require coordinated resources, and produce a defined deliverable or capability.

Project management provides the methods needed to define scope, sequence work, allocate resources, control performance, manage change, and realize benefits. In industrial engineering, project management is closely connected with systems thinking: a local improvement is valuable only when it improves the performance of the wider system without creating unacceptable effects on safety, quality, cost, delivery, people, or the environment.

A useful distinction is between the project output and the business benefit. A project may deliver a new scheduling system, but the benefit is shorter lead time or improved schedule adherence. It may install a robot, but the benefit is safer and more consistent production. Benefits therefore require operational adoption, process ownership, measurement, and follow-through after implementation.

Learning Objectives

By the end of this chapter, the student should be able to:

1. Define project scope, deliverables, assumptions, constraints, and success criteria.
2. Construct a work breakdown structure and a logical project network.
3. Calculate critical-path schedules using the critical path method (CPM).
4. Estimate uncertain activity durations using PERT.
5. Analyze resource loading, resource conflicts, and project crashing decisions.
6. Apply earned-value analysis to assess cost and schedule performance.
7. Build and maintain a practical risk register.
8. Manage stakeholders, teams, communication, change, configuration, and documentation.
9. Evaluate implementation readiness and benefits realization.
10. Recognize ethical, safety, cybersecurity, and governance responsibilities in industrial projects.

1. The Project Life Cycle and Governance

A conventional project life cycle contains four interacting phases:

• Initiation: establish the problem, expected value, sponsor, feasibility, and authorization.
• Planning: define scope, schedule, budget, resources, risks, quality criteria, communications, and procurement.
• Execution and implementation: produce deliverables, coordinate people and suppliers, test outputs, and manage issues.
• Control and closure: compare actual performance with the baseline, control changes, obtain acceptance, transfer the result to operations, and capture lessons learned.

These phases are not strictly linear. A technology project may return from execution to planning when testing reveals an integration problem. A stage-gate approach formally requires evidence before proceeding, such as an approved business case, design review, pilot acceptance, or operational-readiness review.

Governance establishes who may make which decisions. A project charter normally identifies the sponsor, project manager, business owner, objectives, high-level scope, constraints, authority, and initial budget. A responsibility assignment matrix, often expressed as RACI, identifies who is Responsible, Accountable, Consulted, and Informed for major activities. There should normally be one clearly accountable role for each decision or deliverable, even though several people may be responsible for performing work.

A project should be judged against a balanced set of objectives. The traditional cost–time–scope triangle is incomplete if safety, quality, regulatory compliance, workforce acceptance, sustainability, and benefits are ignored. A faster project that creates unsafe work or unusable software is not successful.

2. Scope Definition and the Work Breakdown Structure

Scope states what the project will and will not deliver. Ambiguous scope is a major source of cost growth, conflict, and schedule delay. A scope statement should include:

• the business problem and desired outcome;
• in-scope and out-of-scope work;
• deliverables and acceptance criteria;
• assumptions and constraints;
• interfaces with existing processes and systems;
• exclusions and dependencies; and
• approval authority.

A work breakdown structure (WBS) is a hierarchical decomposition of the total project scope into increasingly smaller components. The lowest useful components are work packages. A work package should have a definable output, responsible owner, estimated effort or duration, cost basis, acceptance criteria, and relationship to other work.

The WBS is deliverable-oriented rather than merely a list of departments. For example, an automation project might be decomposed into project management, process requirements, mechanical design, controls design, procurement, installation, testing, training, and handover. Each branch can then be decomposed further. The 100% rule states that the WBS should include all work required to deliver the approved scope, while avoiding unrelated work and double counting.

The WBS is not itself a schedule. It identifies work; the schedule adds logical relationships, durations, calendars, and milestones. A work package may contain several activities, and a milestone is a zero-duration event used to mark an important point, such as design approval or production release.

Scope baseline and requirements traceability

The scope baseline consists of the approved scope statement, WBS, and WBS dictionary. The WBS dictionary records detailed descriptions, exclusions, assumptions, acceptance conditions, and responsible parties. Requirements traceability links each requirement to its source, design response, test evidence, and acceptance decision. This is particularly important in regulated, safety-related, and software-enabled projects.

A requirement should be testable. “The system should be user-friendly” is weak; “a trained operator shall complete the standard transaction in no more than three minutes with no more than one help prompt” is more measurable, although the threshold must be validated with users and stakeholders.

3. Network Planning and the Critical Path Method

Once activities have been identified, their precedence relationships are represented in a project network. Common relationships include:

• Finish-to-start (FS): successor starts after predecessor finishes.
• Start-to-start (SS): successor starts after predecessor starts.
• Finish-to-finish (FF): successor finishes after predecessor finishes.
• Start-to-finish (SF): successor finishes after predecessor starts; this is uncommon.

The critical path method (CPM) uses deterministic activity durations to calculate the earliest and latest feasible times. In the basic activity-on-node formulation, an activity has an early start (ES), early finish (EF), late start (LS), late finish (LF), and total float.

Here, d_i is the duration of activity i, in consistent time units. For a start activity, ES is normally zero. For a finish-to-start network:

The forward pass calculates earliest times. The backward pass begins with the required project completion time, T, and uses:

Total float is:

All durations and times must use the same calendar convention. A zero-float activity is critical under the specified network and assumptions. There may be more than one critical path, and the critical path can change when durations, logic, calendars, or constraints change. Float is not a license to delay work without considering resource availability, risk, or downstream effects.

Worked CPM example

Consider the following activities:

The paths are A–B–D–F and A–C–E–F. Their durations are 3 + 4 + 6 + 3 = 16 days and 3 + 5 + 4 + 3 = 15 days. Therefore, the planned project duration is 16 days and A–B–D–F is the critical path. The second path has one day of path float, provided that no other constraint exists.

A schedule should be treated as a model, not a guarantee. Procurement lead times, shift calendars, approvals, commissioning windows, and resource limitations may invalidate a purely logical network. The schedule must therefore be reviewed with the people who perform the work.

4. PERT and Uncertainty in Activity Durations

CPM is useful when activity durations are sufficiently predictable. The program evaluation and review technique (PERT) represents uncertainty with three estimates:

• optimistic time, a;
• most likely time, m; and
• pessimistic time, b.

The conventional beta-distribution approximation gives the expected activity time:

and the variance:

The standard deviation is σ = (b − a) ÷ 6. These equations assume that the three-point estimates reasonably describe the activity and that the beta approximation is appropriate. They do not eliminate bias, correlation, resource constraints, or common-cause risks.

For a path containing activities that are treated as independent, expected path duration is the sum of expected activity durations:

and path variance is the sum of activity variances:

The independence assumption is important. If activities share a common risk, simply adding variances can understate uncertainty. For an approximate probability that a path will finish by a target time D, a normal approximation uses:

The approximation is more credible when the path contains several activities and no dominant unusual risk. It should not be presented as a precise guarantee.

For example, if three independent activities have expected durations of 4, 6, and 5 days, the expected path duration is 15 days. If their variances are 1, 4, and 1 day², the path standard deviation is √6 ≈ 2.45 days. A 17-day target has Z = (17 − 15) ÷ 2.45 ≈ 0.82. The corresponding probability must be obtained from a standard normal table or software and is approximately 0.79 under the stated approximation.

5. Resource Planning, Leveling, and Crashing

A logical schedule may require more engineers, electricians, cranes, or test facilities than are available. Resource planning identifies skill requirements over time and compares demand with supply. A resource histogram displays resource demand by period; a loading profile can reveal peaks, idle periods, and bottlenecks.

Resource allocation assigns available resources to activities. Resource leveling changes activity timing to remove over-allocation, often increasing the project duration. Resource smoothing adjusts work within available float while attempting to preserve the completion date. These are different decisions and should not be confused.

Priorities for resolving conflicts should be explicit. Possible criteria include criticality, safety, contractual commitments, benefit contribution, readiness, and the cost of delay. A schedule that silently assumes unlimited specialist labor is not a credible baseline.

Project crashing

Crashing reduces activity duration by adding cost or resources, such as overtime, an additional crew, expedited procurement, or an alternative method. Only activities that can technically be shortened should be considered. The cost slope for an activity is:

The units are monetary units per unit of time saved. Crashing should begin with the least-cost feasible activity on the current critical path, but the analysis must be repeated after each change because the critical path may change. Crashing a noncritical activity usually does not reduce total project duration unless its float is fully consumed.

Worked crashing example

Suppose a critical activity normally takes 8 days at a cost of $12,000 and can be reduced to 5 days at a crash cost of $15,600. Its cost slope is:

If the value of completing the project one day earlier exceeds $1,200 and the activity remains critical, one day of crashing may be justified. However, the decision must also consider overtime fatigue, safety, quality, rework, supplier reliability, and whether the earlier completion creates downstream capacity or benefits.

6. Cost and Earned-Value Management

A cost baseline distributes approved budget over time. Earned-value management (EVM) integrates scope, schedule, and cost using three measures for a reporting period:

• Planned value (PV): budgeted value of work scheduled to be completed.
• Earned value (EV): budgeted value of work actually completed.
• Actual cost (AC): actual cost incurred for the completed work.

All three are measured for the same date and scope. Variances are:

Schedule variance, SV, is expressed in monetary-value units; it is not literally a number of days. Cost variance, CV, is also in monetary-value units. Performance indices are:

An index above 1.00 indicates favorable performance relative to the chosen baseline; an index below 1.00 indicates unfavorable performance. Interpretation requires context, because EV depends on an approved method of measuring physical progress.

If the budget at completion is BAC, a simple estimate at completion is:

This assumes that current cost efficiency will continue and that remaining work behaves similarly. Other forecasting methods are appropriate when the variance is exceptional, when remaining work has a new cost structure, or when schedule performance affects cost. Estimate to complete is ETC = EAC − AC, and variance at completion is VAC = BAC − EAC.

Worked EVM example

A project has BAC = $100,000. At the status date, the planned value is $50,000, earned value is $45,000, and actual cost is $60,000. Therefore:

• SV = $45,000 − $50,000 = −$5,000;
• CV = $45,000 − $60,000 = −$15,000;
• SPI = 45,000 ÷ 50,000 = 0.90; and
• CPI = 45,000 ÷ 60,000 = 0.75.

The project has achieved 90% of the planned progress and obtained $0.75 of budgeted value for each dollar spent. Under the simple continuing-trend forecast, EAC = 100,000 ÷ 0.75 ≈ $133,333. This is a forecast, not a guaranteed final cost.

EVM can be distorted by front-loaded budgets, subjective percentage-complete estimates, unapproved scope, or late recognition of actual costs. It should be combined with physical evidence, milestone acceptance, quality data, and risk information.

7. Risk Management and the Risk Register

A risk is an uncertain event or condition that, if it occurs, affects one or more objectives. Threats may have negative effects; opportunities may have positive effects. An issue is a risk that has already occurred. A risk register should distinguish these terms.

A practical risk process includes:

1. establish context and risk criteria;
2. identify risks using workshops, historical data, process maps, supplier reviews, and expert judgment;
3. analyze probability, impact, proximity, and detectability where appropriate;
4. select responses;
5. assign an owner and due date;
6. monitor triggers and residual exposure; and
7. close, transfer, escalate, or re-plan as conditions change.

A risk register may contain the following fields:

Risk scores based on ordinal scales are useful for prioritization but are not precise probabilities. If probability and monetary impact are credible, expected monetary value may be calculated as:

where p is probability between 0 and 1 and I is impact in monetary units. Expected monetary value should not be used mechanically when impacts are nonfinancial, highly uncertain, dependent, or ethically unacceptable. A low-probability catastrophic safety event cannot be dismissed because its average monetary value is small.

Responses should address causes where possible. For example, “monitor supplier” is not a complete mitigation. A stronger response may include an approved alternative supplier, an early inspection, a technical hold point, and a contingency schedule.

8. Stakeholders, Teams, and Communication

Stakeholders include anyone who can affect the project or be affected by it. In an industrial setting this may include operators, maintenance technicians, production planners, quality personnel, suppliers, regulators, customers, information-technology staff, senior management, and neighboring communities.

Stakeholder analysis considers power, interest, influence, impact, legitimacy, and changing expectations. A high-power sponsor may require concise decision information, while operators may require demonstrations, training, and opportunities to identify hazards. Engagement is not merely sending reports; it is creating appropriate participation and feedback.

Effective project teams require clear objectives, role clarity, psychological safety, technical competence, and mechanisms for resolving conflict. Conflict about technical assumptions can improve decisions when handled respectfully. Suppressed concerns are dangerous in safety-critical work.

A communication plan should specify the information, audience, purpose, format, frequency, owner, and escalation route. Status reports should distinguish facts, forecasts, decisions required, assumptions, risks, issues, and changes. A dashboard that displays green status despite unresolved commissioning defects is a governance failure, not good communication.

9. Change, Configuration, and Documentation Control

Change is inevitable, but uncontrolled change undermines the baseline. A change-control process should:

1. record the request and its reason;
2. clarify the affected requirement, deliverable, or configuration;
3. estimate effects on scope, time, cost, quality, safety, cybersecurity, compliance, operations, and benefits;
4. obtain decision authority appropriate to the change;
5. update the baseline and related documents if approved;
6. communicate the decision; and
7. verify implementation and close the request.

A change-control board may include the sponsor, project manager, technical lead, operations owner, quality or safety representative, and other affected parties. Emergency changes still require documentation and retrospective review.

Configuration management ensures that the team knows which version of a drawing, software build, bill of materials, procedure, or specification is approved. Important records include the decision log, issue log, risk register, requirements traceability matrix, test records, inspection results, training records, supplier documents, acceptance certificates, and lessons learned. Document control is a technical control because an obsolete drawing can produce a physical defect.

10. Implementation Readiness and Benefits Realization

Implementation begins before installation. Readiness should address process design, people, equipment, materials, information, facilities, maintenance, safety, quality, data migration, cybersecurity, and support. A pilot or phased rollout can reduce exposure, reveal practical problems, and generate evidence for scaling.

A useful implementation sequence is:

1. confirm the future-state process and operating requirements;
2. validate design and interfaces;
3. prepare facilities, data, equipment, procedures, and support;
4. train users and supervisors;
5. test using realistic scenarios and acceptance criteria;
6. conduct a controlled pilot or commissioning;
7. stabilize performance and resolve defects;
8. transfer ownership to operations; and
9. measure benefits against the approved business case.

Benefits should have owners, measures, baselines, targets, realization dates, and assumptions. For example, a project to reduce changeover time may define baseline average changeover duration, target reduction, measurement method, product mix conditions, and process owner. Benefits may be financial, operational, customer-related, workforce-related, safety-related, or environmental.

A project can be closed administratively while benefits remain unrealized. Closure should therefore include a benefits review plan, not only a final invoice and archive. Post-implementation review asks whether the solution is being used, whether performance has improved, whether unintended effects occurred, and what should be learned for future projects.

11. Ethical, Safety, and Technology Considerations

Industrial project decisions affect workers and the public. Safety requirements must not be traded away to protect a deadline. Risk assessments should consider foreseeable misuse, maintenance conditions, human factors, emergency access, and the competence required to operate the system. Compliance with applicable occupational safety, machinery, electrical, environmental, data-protection, and sector-specific requirements must be built into the design and verification process.

Technology projects create additional risks. Connected equipment may expose production systems to cyberattack. Data models may encode biased or incomplete assumptions. Artificial intelligence can support forecasting, anomaly detection, document analysis, and resource planning, but generated recommendations require validation, traceability, access control, and human accountability. AI should not be used to fabricate progress evidence, conceal uncertainty, or make safety-critical decisions without appropriate engineering controls.

Professional integrity requires accurate reporting of cost, progress, defects, uncertainty, and conflicts of interest. A project manager should escalate information that could materially affect safety, compliance, or the business case, even when escalation is unpopular.

12. Integrated Applied Case: Illustrative Packaging-Line Implementation

Background

The following is a fictional illustrative case. A food-products plant experiences frequent manual inspection errors and inconsistent throughput. Management authorizes a project to install an automated vision-inspection station and connect its results to the production database. The intended benefits are a 30% reduction in inspection-related defects, improved traceability, and less repetitive manual inspection.

Problem and initial analysis

The sponsor initially describes the project as “install a camera.” The project team clarifies that the actual scope includes product presentation, lighting, camera and software, reject mechanism, database interface, operator procedures, training, validation, and maintenance support. It excludes replacement of the upstream filler and redesign of the enterprise resource-planning system.

The team develops a WBS and identifies stakeholders: operators, quality assurance, maintenance, information technology, the equipment supplier, production planning, and the plant safety representative. Requirements include minimum detection performance for specified defect classes, maximum false-reject rate, traceable records, safe access, and a defined recovery procedure when the system is unavailable.

Schedule and risk analysis

The network identifies requirements, mechanical design, controls design, procurement, software configuration, installation, integration testing, operator training, and production validation. Procurement and software configuration are initially the longest paths. A risk register records uncertain product presentation, supplier lead time, poor lighting, database-interface failure, operator resistance, and cyber-access weaknesses.

The team chooses mitigation actions: test representative products before final purchase, include an early supplier design review, specify lighting performance, conduct an interface test with anonymized data, involve operators in trials, and require controlled credentials and network segmentation. The risk owner for detection performance is the quality engineer, while the maintenance manager owns serviceability and spare-parts readiness.

Implementation and control

During installation, an additional guarding requirement is identified. The project team does not simply absorb the work informally. It assesses the effect on cost, schedule, safety, and acceptance criteria. The change-control board approves a revised guard design and shifts training by two days. The baseline and drawings are updated, and the decision is recorded.

At the first pilot, the system detects the target defects but produces excessive false rejects on a product variant not included in the original test sample. The team treats this as a validation issue rather than declaring success. It expands the test protocol, adjusts lighting and classification rules, and repeats acceptance testing. Operators participate in the trial and identify a recovery step that would otherwise have caused excessive downtime.

Outcome and benefits

The project is accepted after the system meets the agreed detection and false-reject criteria across representative products, operators complete competency checks, maintenance receives spare parts and fault-isolation instructions, and the database records pass the traceability test. A 90-day benefits review compares defect rates, inspection labor, downtime, false rejects, and user adoption with the baseline.

Learning points

The case demonstrates that implementation management is broader than purchasing equipment. Clear scope prevented an unrealistic “camera-only” interpretation. The WBS exposed overlooked work. Risk ownership produced actions rather than passive lists. Change control protected safety and configuration integrity. User participation improved operational fit, and benefits measurement connected the technical deliverable to business performance.

Challenges and Limitations of Project-Control Methods

No method removes uncertainty. CPM can give false confidence when logic is incomplete or resource constraints are ignored. PERT depends on the quality of three-point estimates and can misrepresent correlated risks. Crashing may increase fatigue, defects, or safety exposure. EVM is less informative when scope is unstable or progress is difficult to measure objectively. Risk matrices can create artificial precision and may understate low-frequency catastrophic events.

Project control can also become bureaucratic. Excessive reports, unnecessary approval layers, and documentation without decision value consume resources. The appropriate level of control depends on complexity, risk, regulatory exposure, organizational maturity, and reversibility of decisions. Agile or iterative approaches may be useful for software and process discovery, while stage-gate and formal verification may be essential for safety-critical equipment. Hybrid approaches are often appropriate: iterative development within controlled design, testing, and release governance.

Best-Practice Checklist

A professionally managed industrial project should normally have:

• an approved charter and measurable business case;
• a clear scope baseline and deliverable-oriented WBS;
• a logically tested schedule with realistic calendars and resources;
• identified critical paths and schedule assumptions;
• a cost baseline and meaningful progress measurement;
• an active risk and issue process with named owners;
• stakeholder and communication plans;
• documented change and configuration control;
• requirements, test, training, and acceptance evidence;
• operational-readiness and safety reviews;
• a controlled handover to an accountable process owner; and
• a benefits-realization plan with post-implementation measurement.

Chapter Summary

Project and implementation management provides an integrated way to transform an industrial need into a controlled and beneficial operational result. Scope definition establishes boundaries and acceptance conditions; the WBS decomposes total work into manageable deliverables. Network planning exposes precedence and critical paths, while CPM calculates earliest and latest times under stated assumptions. PERT introduces three-point duration estimates and communicates uncertainty, although its statistical assumptions must be treated carefully.

Resource allocation, leveling, and crashing connect schedule logic with real capacity and cost. Earned-value analysis combines planned value, earned value, and actual cost to indicate schedule and cost performance, but results depend on credible progress measurement. Risk registers convert uncertainty into ownership, triggers, responses, and monitoring. Stakeholder engagement, team communication, change control, configuration management, and documentation protect technical and organizational integrity.

Successful implementation requires more than delivering equipment or software. It requires readiness, training, testing, safety, cybersecurity, operational ownership, and measurement of realized benefits. Ethical practice demands truthful reporting and protection of workers, users, customers, and the public. The most effective project systems are sufficiently rigorous to control risk while remaining practical enough to support learning and timely decisions.

Key Terms

Project: A temporary endeavor undertaken to create a defined product, service, or result.

Deliverable: A verifiable output produced by project work.

Scope baseline: Approved scope statement, WBS, and WBS dictionary.

Work breakdown structure (WBS): Hierarchical decomposition of total project scope.

Work package: The lowest practical WBS component assigned for planning and control.

Milestone: A significant event with zero planned duration.

Critical path: The longest-duration path determining the calculated project completion date.

Total float: Time an activity can be delayed without delaying the calculated project completion date.

PERT: A technique using optimistic, most likely, and pessimistic duration estimates.

Resource leveling: Adjusting activity timing to resolve resource over-allocation.

Crashing: Shortening project duration by adding cost or resources to suitable activities.

Planned value (PV): Budgeted value of work scheduled by a status date.

Earned value (EV): Budgeted value of work actually completed by a status date.

Actual cost (AC): Cost incurred for completed work by a status date.

Risk register: Controlled record of risks, analysis, owners, responses, and status.

Issue: A risk event or problem that has already occurred.

Change control: Formal evaluation and authorization of changes to the baseline.

Configuration management: Control of approved versions and relationships among project items.

Benefits realization: Process of ensuring that delivered outputs produce intended outcomes and value.

Stage gate: Formal decision point requiring evidence before proceeding to the next phase.

Review Questions

Short Answer Questions

1. What is the purpose of a work breakdown structure?
2. Distinguish between a risk and an issue.
3. What does a zero-float activity indicate in a CPM schedule?
4. Define planned value, earned value, and actual cost.
5. Why is operational ownership important for benefits realization?

Long Answer Questions

1. Explain how a project charter, scope baseline, WBS, and requirements traceability work together to control scope.
2. Describe the CPM forward-pass and backward-pass calculations and discuss the limitations of a purely logical schedule.
3. Explain PERT estimation, including its assumptions and the meaning of expected duration and variance.
4. Discuss how stakeholder engagement, communication, team design, and change control influence implementation success.
5. Explain how a project should move from technical completion to operational handover and benefits realization.

Analytical / Application Questions

1. Construct a precedence network for a small equipment-installation project, calculate its critical path and float, and explain how a two-day procurement delay would affect the schedule.
2. A project has BAC = $240,000, PV = $120,000, EV = $108,000, and AC = $135,000. Calculate SV, CV, SPI, CPI, and a simple EAC, then interpret the results.
3. Develop a risk register for implementing a connected automated inspection system. Include at least six risks, owners, triggers, preventive responses, and contingency actions, and justify which risks should receive the highest management attention.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a work breakdown structure?

A. A hierarchical decomposition of the total project scope

B. A list of employee salaries by department

C. A statistical forecast of project completion probability

D. A supplier contract containing delivery penalties

Correct Answer: A. A hierarchical decomposition of the total project scope

Question 2

For a finish-to-start network, which equation determines an activity’s early start?

A. ES = EF − duration

B. ES = maximum EF of immediate predecessors

C. ES = minimum LS of immediate successors

D. ES = duration ÷ EF

Correct Answer: B. ES = maximum EF of immediate predecessors

Question 3

An activity has a normal time of 10 days and cost of $20,000, and a crash time of 8 days and cost of $24,000. What is its cost slope?

A. $500 per day

B. $2,000 per day

C. $4,000 per day

D. $12,000 per day

Correct Answer: C. $4,000 per day

Question 4

If EV = $80,000 and PV = $100,000, what is the schedule performance index?

A. 0.80

B. 1.25

C. $20,000

D. $180,000

Correct Answer: A. 0.80

Question 5

Which item is an issue rather than a risk?

A. A supplier may miss the delivery date

B. A future software interface may fail testing

C. The supplier has already missed the delivery date

D. Operators may resist the new procedure

Correct Answer: C. The supplier has already missed the delivery date

Question 6

What is the primary purpose of resource leveling?

A. To increase every activity’s duration

B. To resolve resource over-allocation

C. To eliminate all project risks

D. To replace the project scope statement

Correct Answer: B. To resolve resource over-allocation

Question 7

Using the conventional PERT equation, what is the expected duration when a = 2 days, m = 5 days, and b = 8 days?

A. 4 days

B. 5 days

C. 6 days

D. 15 days

Correct Answer: B. 5 days

Question 8

Which document most directly records approved versions of drawings, software builds, and procedures?

A. Configuration-management record

B. Marketing plan

C. Attendance register

D. Risk appetite statement

Correct Answer: A. Configuration-management record

Question 9

A project has BAC = $100,000, EV = $40,000, and AC = $50,000. Using EAC = BAC ÷ CPI, what is the estimated cost at completion?

A. $80,000

B. $110,000

C. $125,000

D. $150,000

Correct Answer: D. $150,000

Question 10

Which practice most directly supports benefits realization?

A. Closing the project immediately after equipment delivery

B. Measuring outcomes against a baseline with an assigned benefit owner

C. Removing operators from acceptance testing

D. Avoiding post-implementation reviews

Correct Answer: B. Measuring outcomes against a baseline with an assigned benefit owner