1.5 Stakeholder Identification, Needs, and Plan Review

AACE Planning and Scheduling Professional PSP

Track your progress as you read

Finished sections get a check mark.

1 Chapter 0: Introduction & AACE PSP Exam Structure

0.1 Current AACE PSP Exam, Eligibility, and Certification Facts 0.2 Planning and Scheduling Professional Roles and Competencies 0.3 Cost Engineering and Scheduling Terminology per RP 10S-90

2 Chapter 1: Scope Definition & Planning Fundamentals

1.1 Work Breakdown Structure (WBS) Architecture & RP 33R-15 1.2 Organization & Resource Breakdown Structures (OBS, RBS, RAM) 1.3 Project Planning and Activity-Logic Development 1.4 Contract Requirements and Delivery Constraints 1.5 Stakeholder Identification, Needs, and Plan Review 1.6 Constructability Methods and Value Engineering 1.7 Resource Identification and Project Variables 1.8 Scope, Goals, Project Plan, and Phase Definition 1.9 Cost Breakdown Structure and Cost Estimate Development 1.10 Phase Relationships, Baseline Plan, Forecasts, and Risk/Recovery Planning

3 Chapter 2: Critical Path Method Mechanics & Network Logic

2.1 Activity Definition and Logic Relationships 2.2 Activity Durations, Productivity, and Work Calendars 2.3 Forward and Backward Pass Mathematical Mechanics 2.4 Float Calculations and Critical-Path Identification

4 Chapter 3: Advanced Network Techniques & Schedule Constraints

3.1 Schedule Constraints and Their Impact on Dates and Float 3.2 Advanced Logic Modeling: Ladders and Fragnets 3.3 Schedule Levels of Detail and Schedule Basis Documentation 3.4 Schedule Scope and Schedule Specification 3.5 Breakdown-Structure Relationships and the Cost Estimate Model 3.6 Stakeholder Feedback and Types of Schedules 3.7 Activities, Milestones, Schedule Quality, and Basis Documentation

5 Chapter 4: Resource Management & Leveling

4.1 Resource Planning, Allocation, and Histograms 4.2 Resource Leveling vs. Resource Smoothing 4.3 Cumulative Resource S-Curves & Productivity Tracking

6 Chapter 5: Baseline Management & Schedule Updating

5.1 Baseline Establishment, Forecasts, and Controlled Revision 5.2 Progress Measurement and Data Date Mechanics 5.3 Out-of-Sequence Logic: Progress Override vs. Retained Logic 5.4 Schedule Update Review and Quality Verification per RP 53R-06 5.5 Cost/Resource Management, Schedule Change, and Feedback 5.6 Acceleration and Recovery Scheduling per RP 54R-07 5.7 Control Schedules, Variance Analysis, Forecasts, and Management Summaries

7 Chapter 6: Schedule Risk Analysis & Monte Carlo Simulation

6.1 Schedule Risk Principles, Risk Drivers, and Three-Point Estimates 6.2 Monte Carlo Simulation, Criticality, Correlation, and Merge Effects 6.3 Risk Outputs, Confidence Dates, Sensitivity, and Contingency

8 Chapter 7: Earned Value & Earned Schedule Management

7.1 Earned Value Foundations: PV, EV, AC, and Variances 7.2 Traditional EV Performance Indices & Late-Project Quirks 7.3 Earned Schedule (ES) Theory, SV(t), and SPI(t) 7.4 Independent Schedule Forecasting & IEAC(t)

9 Chapter 8: Forensic Schedule Analysis & Delay Claims

8.1 Delay Classification, Criticality, and Contract Questions 8.2 RP 29R-03 Taxonomy, Data Validation, and Method Selection 8.3 TIA, Windowed Analysis, and Subtractive Models 8.4 Concurrency, Pacing, and Float: Technical Analysis Before Entitlement

10 Chapter 9: Executive Communication & Practical Scenario Applications

9.1 Official PSP Memo Writing Framework 9.2 Structured Technical Problem-Solving for PSP Scenarios 9.3 Current Exam Strategy and Core Calculation Review

1.5 Stakeholder Identification, Needs, and Plan Review

Key Takeaways Explain This Topic AI

Stakeholder identification asks who can supply requirements, constrain execution, perform work, accept deliverables, or be affected by the project.

A stakeholder register should record influence, information needs, decisions, interfaces, timing, and engagement ownership.

Stakeholder preferences must be distinguished from physical, regulatory, and contractual requirements.

Structured reviews validate scope, sequence, resources, risks, milestones, and acceptance criteria before the plan becomes a baseline.

Last updated: October 2026

1.5 Stakeholder Identification, Needs, and Plan Review

Planning is collaborative because no scheduler owns all scope knowledge. Stakeholders include parties who provide requirements, perform work, control access or decisions, accept deliverables, fund the project, regulate it, operate the asset, or experience its impacts.

Identify stakeholders by interface

Begin with the project charter, organization chart, contract matrix, permits, WBS, procurement plan, and operations interfaces. Ask:

Who defines or approves requirements?

Who supplies design, land, equipment, permits, utilities, or access?

Who performs and supervises the work?

Who tests, accepts, operates, or maintains the deliverable?

Who can stop, delay, or resequence work?

Who needs schedule information to make a decision?

Typical groups include owner leadership, users, design disciplines, contractors, vendors, regulators, utility owners, operations, safety and quality teams, finance, procurement, commissioning, and affected community representatives.

Build a stakeholder register

• Stakeholder Required input or decision Needed by Schedule interface Engagement owner
• Operations Outage window approval 1 June Shutdown milestone and calendar Project manager
• Vendor Certified drawing 15 April Fabrication predecessor Procurement lead
• Regulator Permit decision 30 May Site-work release Permitting manager
• Commissioning Turnover sequence Baseline review System completion logic Commissioning lead

This turns a generic communication list into schedule information. It also reveals missing decision activities and unrealistic assumptions.

Consider stakeholder needs without corrupting logic

A stakeholder may prefer one sequence because it simplifies staffing or reporting. Another may require a sequence because of safety, law, or physical dependency. Record the basis. A preference can remain a planning assumption that is revisited during optimization; a mandatory interface needs formal treatment.

Avoid solving every concern with a hard constraint. Constraints can suppress float and mask the path. Model the underlying approval, access, or handoff activity whenever possible.

Facilitate plan reviews

A useful review is structured around evidence:

Scope review: Does the WBS cover all deliverables and closeout work?

Execution review: Is the method safe, buildable, operable, and coordinated?

Interface review: Are owner, designer, vendor, regulator, and contractor handoffs explicit?

Sequence review: Does logic reflect physical and management dependencies?

Duration/resource review: Are quantities, rates, crew sizes, calendars, and availability credible?

Risk review: Are material uncertainties and responses visible?

Milestone review: Do dates reconcile with commitments and acceptance needs?

Use comments, dispositions, owners, and due dates. “Reviewed” should mean issues were resolved or consciously accepted, not merely that a PDF was distributed.

Feedback across the lifecycle

Stakeholder involvement continues after baseline. Field teams report changed means and methods; procurement reports vendor movement; operations refines outage access; and leadership chooses mitigation. Route feedback through controlled update and change processes so the schedule remains current without erasing the approved baseline.

Common traps

Missing the stakeholder who controls a small but critical approval.

Treating executive target dates as physical logic.

Inviting only managers and omitting the people who understand execution.

Recording comments without disposition.

Allowing one stakeholder to optimize its area at the expense of the integrated project.

The planner’s role is to build a shared, traceable model of the agreed plan. Stakeholder review improves that model when it is connected to decisions, interfaces, and evidence.

Applied review: design the information path

Stakeholder analysis should answer who supplies information, who performs work, who approves decisions, who receives schedule outputs, and who can constrain access or acceptance. A responsibility matrix can connect each interface to an owner, required input, needed-by date, review duration, escalation route, and schedule activity. The planner then tests whether the network actually reflects those commitments instead of assuming that attendance at a meeting equals agreement.

Different stakeholders need different views of the same controlled model. A superintendent may need a short look-ahead organized by area and crew. Procurement may need required-on-site dates and submittal releases. An executive may need decision milestones, trend direction, and forecast exposure. Tailoring the view does not authorize changing the underlying status or logic. Reconcile every report to the same data date and explain any aggregation or filtering.

Review comments also require disposition. Record whether a comment was accepted, rejected, deferred, or converted into an action; identify the reason and responsible decision maker. Conflicting preferences should be resolved against scope, contract, execution feasibility, and governance—not by letting the loudest stakeholder impose hidden constraints. In an exam question, look for a response that validates the source, makes the decision path explicit, updates the model only after appropriate agreement, and preserves an audit trail.