PMP Exam Day Three Notes

Scope Management Fundamentals

Scope precisely defines what the project will deliver, emphasizing tangible outputs (nouns/deliverables) rather than the activities performed to create them. For instance, 'a new training portal', 'a refined shopping-cart module', or 'a comprehensive regulatory report' are deliverables, whereas 'developing software' or 'conducting research' are activities and not part of the defined scope.

Planning approaches that postpone detailed scope definition until later phases, allowing for flexibility and adaptation:

• Rolling Wave Planning / Iterative Planning / Progressive Elaboration: These are synonymous terms describing an adaptive technique where work is planned in detail only for the near term, while future work is planned at a higher level. As the project progresses and more information becomes available, details are progressively elaborated. This approach is usable in both Agile (where iterations naturally support it) and Predictive lifecycles (e.g., in projects with evolving requirements), enabling an early start even when requirements are still emerging.

Scope artifacts in Predictive projects (all become part of the Scope Baseline and are subject to formal Change Control to ensure any modifications are managed):

• Scope Statement: A detailed description of the project and product scope, including major deliverables, project objectives, acceptance criteria, and explicit statements of what is in scope and out of scope. It also outlines project constraints (e.g., budget, schedule, resources) and assumptions (factors believed to be true).

• Requirements Document: Initially high-level, requirements are progressively refined as the project advances. These requirements are often managed and tracked in a Requirements Traceability Matrix (RTM), which links requirements to design, code, tests, and business objectives, ensuring all approved requirements are delivered and facilitating change management.

• Work Breakdown Structure (WBS): A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish project objectives and create the required deliverables. It organizes and defines the total scope of the project, often visually.

• WBS Dictionary: Provides detailed metadata for each component in the WBS, specifying the work package description, assigned organization, estimated cost, schedule information, quality requirements, and acceptance criteria.

Change & “Scope Creep” are critical challenges to manage. It's essential to collect high-level requirements and agree on the overall project scope before detailing specific features. Uncontrolled expansion of product or project scope without adjustments to time, cost, and resources is known as scope creep and can destabilize a project.

Ethical implication: Maintaining clarity and transparency regarding scope from the outset prevents misaligned expectations among stakeholders, reduces post-delivery disputes, and builds trust.

Iterative Planning vs. Traditional Planning

Iterative planning concepts existed long before Agile methodologies; Agile popularised and standardized much of the associated vocabulary and practices.

Analogies for activity sequencing, useful in both Predictive and Agile contexts:

• Swim relay: Represents a Finish-to-Start dependency, where one activity must complete before the next can begin (no lead/lag).

• Running relay: Represents a Lead, where the successor activity can start before the predecessor activity is fully finished, creating an overlap. This can speed up the schedule.

• Triathlon transition: Represents a Lag (or delay), where there is intentional waiting time after the predecessor finishes and before the successor can begin. This might be due to a required drying time, regulatory waiting period, or other non-work-effort related delays.

Leads & Lags can have explicit durations; they do NOT count toward activity work‐effort.

Minimum Viable Product (MVP) vs. Minimum Business Increment (MBI)

• Minimum Viable Product (MVP): This is an experiment or prototype designed to validate a business idea or product desirability with the least amount of effort and for discovery purposes. It often includes only core functionality, which may sometimes be manual or “band-aided” (e.g., the initial Amazon Go store utilized human monitoring to simulate automated checkout). The investment in an MVP emphasizes learning and validating hypotheses.

• Minimum Business Increment (MBI): This represents the smallest shippable, production-ready slice of functionality that delivers distinct, monetisable value to the customer or business. It is an investment geared towards generating revenue or achieving a specific business outcome. For example, a quick A/B test of a shopping cart design to see which converts better (MVP) might lead to the full implementation of various payment methods (MBI).

Pharmaceutical example: Lab bench results or early compound testing might be akin to an MVP for initial validation, while a final, regulatory-approved vaccine with demonstrated efficacy and safety would be an MBI.

Practical risk: Releasing buggy or incomplete MBIs can significantly harm a brand's reputation and customer trust. However, delaying an MBI for too long incurs opportunity costs by postponing value realization and market entry.

Product Roadmaps & Milestones

• Product Roadmap: A high-level, time-phased visual representation (often spanning quarters or years) that outlines the strategic goals, features, and customer value a product aims to deliver over time. It communicates the product vision and direction.

• Milestones: Significant points or events in the project schedule that mark the completion of major deliverables or decision points. Milestones typically have a duration of zero, indicating a specific point in time rather than work being performed. They are often mandatory (e.g., contractual obligations) or optional but important tracking points. Executive status updates are frequently reported using milestone charts rather than highly detailed, multi-page schedules.

Traditional vs. Agile Roles

• Predictive (Traditional) Projects: The Project Manager is key in facilitating requirement collection, planning, and execution. The Sponsor is typically a senior management role responsible for funding the project, providing high-level guidance, and having the ultimate authority to authorize or cancel the project.

• Agile Projects: The Product Owner (PO) is a single individual responsible for maximizing the value of the product resulting from the work of the Development Team. This includes owning and continuously sequencing the Product Backlog, making value-driven decisions, and possessing cancellation authority within the scope of the product. The Scrum Master acts as a servant-leader, facilitating the Agile team's processes and removing impediments.

PMI's perspective: The Project Management Institute (PMI) often treats the Product Owner as the de-facto Sponsor in an Agile context, given their direct responsibility for value realisation and product success.

Backlog Taxonomy

The overall Product Backlog (a prioritized, continually refined list of all known work for a product) is often decomposed into smaller, more manageable backlogs:

• Release Backlogs: Collections of Product Backlog items slated for a specific product release.

• Iteration/Sprint Backlogs: A subset of the Release Backlog containing items selected for completion within a single iteration or sprint.

It's important to think of a backlog as a flexible “list”, not burdened by “baggage” that implies rigidity: prioritised items can move, be dropped, or be superseded as understanding evolves.

Story Map visual: A visual representation that maps out the user journey. Horizontal flow typically represents steps in the user's interaction with the product, while vertical columns organize stories/features sorted by release priority, showing the scope of each release incrementally.

Agile Work Items Hierarchy

• Story: A small, concise description of a feature or piece of functionality from the perspective of an end-user. It must be small enough to fit within a single iteration (sprint). The common format is "As a (type of user) I want (some goal) so that (some reason/benefit)".

• Feature: A larger capability or significant piece of functionality that often requires multiple stories or several iterations to complete. It delivers a distinct value proposition.

• Epic: A very large theme or initiative that represents a significant body of work, often needing a lightweight business case and a strong hypothesis for its value. An Epic is too large to fit in a single release and breaks down into many features, which in turn break down into stories.

Requirements Gathering Techniques

Various techniques are employed to collect and analyze project requirements, drawing on different sources and methods:

• Expert Judgement & Interpersonal Skills: Relying on the knowledge and experience of experts in relevant domains and utilizing communication, facilitation, and negotiation skills to illicit and manage requirements effectively.

• Group Methods:

  • Nominal Group Technique: A structured variation of brainstorming that encourages participants to first generate ideas independently and silently, then share and discuss them, followed by a voting process (e.g., dot voting, star voting) to prioritize ideas.

  • Focus Groups: Bringing together pre-qualified stakeholders and subject matter experts to learn about their expectations and attitudes concerning a product, service, or result. They are guided by a facilitator.

  • Facilitated Workshops: Highly structured, cross-functional workshops designed to bring key stakeholders together to define and refine requirements rapidly, resolve discrepancies, and foster shared understanding.

• Individual Methods:

  • Interviews: Direct conversations with stakeholders to gather information, clarify requirements, and explore underlying needs.

  • Questionnaires: Written sets of questions distributed to a large group of stakeholders to gather input, especially useful for diverse or geographically dispersed teams.

• Observation (Gemba): Directly observing individuals performing their work or tasks to understand processes, challenges, and requirements that might not be articulated.

• Document & Benchmark Analysis: Reviewing existing documentation (e.g., business plans, policies, procedures) and comparing project practices or requirements against industry best practices or competitor offerings.

• Alternatives & Decision-matrix (weighted scoring): Evaluating different solution options against defined criteria, with each criterion assigned a weighting, to objectively select the most suitable alternative.

• Affinity Diagrams: A brain-storming tool used to cluster and organize large sets of ideas or requirements into natural groupings based on their relationships.

• Prioritization Techniques:

  • Kano Model: Categorizes customer preferences into 'Delighters', 'Satisfiers', and 'Must-haves' to understand which requirements will most impact customer satisfaction.

  • MoSCoW Prioritization: Classifies requirements as Must have, Should have, Could have, and Won't have (for this release).

  • 100-Point Voting: Stakeholders are given 100 points to distribute among potential requirements, indicating their relative importance.

• Validation Techniques:

  • Prototypes: Creating preliminary versions or mock-ups of a product or feature to gather early feedback and validate requirements before significant investment.

  • Storyboards: Visual sequences depicting how a user will interact with a system or product, aiding in understanding user experience and requirements.

Work Breakdown Structure (WBS)

The Work Breakdown Structure (WBS) is a fundamental project management tool that provides a hierarchical decomposition of the total scope of work. It breaks down project deliverables into smaller, more manageable components, focusing exclusively on nouns or deliverables, not activities.

100% Rule: This critical rule states that the WBS must include 100% of the work defined by the project scope and capture all deliverables – internal, external, interim, and final. Conversely, it must not include any scope that is outside the project boundaries.

Levels of the WBS (from highest to lowest level of detail):

• Control Accounts: Management control points for integrating scope, cost, and schedule. They are aggregation points for tracking and reporting performance. A control account contains multiple planning packages or work packages.

• Planning Packages: Components of a control account, representing known work that is not yet detailed enough to be broken down into work packages. They are placeholders for future planning and elaboration.

• Work Packages: The lowest level of the WBS. Work packages are definable deliverables that are small enough to be reliably estimated in terms of time and cost, and can be assigned to a specific individual or team for completion. They represent concrete, manageable pieces of work.

WBS Dictionary: A companion document to the WBS that provides detailed metadata for each component, particularly for work packages. It typically includes the WBS identifier, a clear description of the work, the organization responsible, estimated cost and schedule information, quality requirements, acceptance criteria, and specific technical references.

Estimating Techniques (Predictive)

Predictive project management relies on various techniques to estimate the time and cost required for project activities. These estimates are crucial for planning and budgeting.

• Analogous Estimating (Top-Down): This technique uses historical data from a previous, similar project to estimate the duration or cost of a current project. It is quick but the least accurate, typically within ±50% of the actual value. It is often used early in the project when little detail is available.

• Parametric Estimating: This method uses a statistical relationship between historical data and other variables (e.g., square footage in construction, lines of code in software development) to calculate an estimate. It's generally more accurate than analogous estimating, for example, "rate × quantity" (e.g., 50 per square foot multiplied by 10,000 square feet).

• Bottom-Up Estimating: This is the most accurate but also the most time-consuming technique. It involves estimating the cost or duration of individual work packages (the lowest level of the WBS) and then rolling these estimates up to higher levels of the WBS to get a total project estimate.

• Three-Point Estimates: These techniques account for estimating uncertainty by considering three values:

  • Optimistic (O): The best-case scenario, usually the shortest duration or lowest cost.

  • Most Likely (M): The realistic duration or cost.

  • Pessimistic (P): The worst-case scenario, usually the longest duration or highest cost.
    Using these, two common calculations are:

  • Triangular Distribution: A simple average of the three points.

  • PERT/Beta Distribution: A weighted average that gives more weight to the most likely estimate, often used to reduce bias.

Effort vs. Duration distinction: It is crucial to distinguish between "effort" (the amount of labor needed to complete an activity, typically in person-hours or person-days) and "duration" (the total calendar time required to complete the activity). For example, an activity requiring 16 hours of effort might take 2 days of duration if one person works 8 hours a day, or 1 day if two people collaborate simultaneously.

Agile Estimation & Velocity

Agile methodologies employ distinct estimation techniques that emphasize relative sizing and adaptability.

• Relative Sizing with Fibonacci Sequence: Instead of estimating in absolute hours, Agile teams often use relative sizing, comparing the complexity, effort, and uncertainty of one story against others. The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21…) is commonly used for this, as it reflects the increasing uncertainty and complexity as items get larger.

• Story Points: Abstract units used to estimate the overall effort, complexity, risk, and uncertainty required to implement a user story. Story points are NOT hours; they are a direct measure of size and difficulty relative to other stories, allowing teams to focus on the work itself rather than getting bogged down in precise time estimates.

• Planning Poker: A consensus-based, gamified technique for estimating. Each team member simultaneously reveals a card representing their story point estimate. Outliers (significantly different estimates) are discussed to understand underlying assumptions and risks, leading to convergence on a collective estimate.

• Velocity: The average number of story points (or other units) that a development team completes per iteration (sprint). It is a measure of a team’s capacity and throughput, used for forecasting how much work can be completed in future sprints or how many sprints it will take to complete a set of features (e.g., if a team’s capacity is around 10 points per sprint, they can forecast accordingly).

• Definition of Done (DoD): A formal, agreed-upon checklist of criteria that a product increment must meet to be considered "complete" and shippable. The DoD ensures quality, consistency, and a shared understanding of what constitutes a finished piece of work at the end of each sprint.

Scheduling & Critical Path Method (CPM)

Scheduling in project management involves creating a realistic timetable for project activities. The Critical Path Method (CPM) is a key technique for determining the longest sequence of activities that must be completed on time for the entire project to be completed on schedule.

• Early Start/Finish (Forward Pass): The earliest possible time an activity can start (ES) and finish (EF) without delaying the project. This is calculated by moving forward through the project network diagram.

• Late Start/Finish (Backward Pass): The latest possible time an activity can start (LS) and finish (LF) without delaying the project completion date. This is calculated by moving backward through the project network diagram from the project end date.

• Float (or Slack): The amount of time an activity can be delayed without delaying the project's early finish date or violating a schedule constraint. It is calculated as the difference between Late Start and Early Start (LS - ES) or Late Finish and Easy Finish (LF - EF). Activities on the Critical Path have a Float of zero, meaning any delay to these activities will directly delay the entire project.

• Crashing: A schedule compression technique in which resources are added to critical path activities to shorten the overall project duration. Crashing typically leads to increased costs but can significantly reduce project time (e.g., adding more workers, paying overtime).

• Fast Tracking: A schedule compression technique where activities that would normally be done in sequence are performed in parallel, or their phases are overlapped. This can reduce the overall project duration but often increases risk due to potential rework if early activities change after subsequent ones have started.

Resource Optimisation:

• Smoothing: Adjusting activities within their available float to level out resource demand peaks and valleys across the project. This avoids changing the critical path.

• Leveling: Adjusting the project schedule based on resource availability and constraints, even if it means extending the critical path and the overall project duration. This is necessary when resources are limited or to avoid over-allocation.

Communication Tools:

Various visual tools are used to communicate schedule information, including:

• Gantt Chart: A bar chart that illustrates a project schedule, showing the start and finish dates of the terminal elements and summary elements.

• Network Diagram: A graphical representation of the logical relationships (dependencies) among the project schedule activities.

• Milestone Chart: A high-level chart focusing only on major project milestones.

• Roadmap: A strategic visual overview of product or project direction over time.

Baselines & Iteration Zero/Harden Sprint

Baselines are fundamental for managing project performance and controlling changes, while special iterations are used to prepare for or finalize work.

PMI Performance Baselines:

The Project Management Institute (PMI) identifies three key baselines that, together, form part of the Project Management Plan and against which project performance is measured:

• Scope Baseline: The approved version of the scope statement, WBS, and WBS Dictionary.

• Schedule Baseline: The approved version of the project schedule.

• Cost Baseline: The approved version of the time-phased project budget.

Any changes to these baselines should go through a formal change control process.

• Iteration 0 (or Sprint 0): A preparatory iteration or phase, typically at the beginning of an Agile project, focused on setting up the foundational elements required for the subsequent development sprints. This can include setting up development environments, establishing Continuous Integration/Continuous Delivery (CI/CD) pipelines, configuring Wi-Fi and network access, onboarding team members, and initial architectural design or prototyping.

• Iteration H ("Hardening" / Release Sprint): A dedicated iteration, usually towards the end of a release cycle, prior to final deployment. Its purpose is to handle activities that might not fit cleanly into regular development sprints but are crucial for release readiness. This often includes comprehensive regression testing, data migration, performance tuning, final security checks, and detailed documentation before the product is released to production.

Risk Management Essentials

Risk management is the process of identifying, assessing, and controlling threats and opportunities to a project. A risk is an uncertain event or condition that, if it occurs, has a positive (opportunity) or negative (threat) effect on project objectives. It must have a probability greater than 0 and a non-zero impact.

Realized Risk becomes an Issue: If a risk event occurs, it is no longer a risk but an "issue" that requires immediate corrective action.

Organisational Posture Towards Risk:

• Risk Appetite: The degree of uncertainty an organization or individual is willing to accept in anticipation of a reward. This can range from risk-seeking to risk-neutral to risk-averse.

• Risk Threshold: The specific acceptable level of risk at which a project stakeholder is willing to tolerate (the point beyond which risk is unacceptable). This is a quantitative boundary for acceptance.

• Risk Exposure: The potential impact of a risk event, often expressed as a product of its probability and impact (e.g., in dollars, days, or a scoring value). The concept explains the potential magnitude if the risk occurs.

Tools & Techniques for Risk Management:

• Risk Breakdown Structure (RBS): A hierarchical representation of potential project risks, organized by category and subcategory. It helps ensure comprehensive identification of risks.

• Probability-Impact Matrix: A grid that maps the probability of a risk occurring against the severity of its impact. Risks are often categorized (e.g., Low, Medium, High, Very-High), and specific actions are typically escalated for risks falling into High or Very-High cells.

• Monte Carlo Simulation: A quantitative risk analysis technique that uses computer modeling to simulate the outcomes of a project repeatedly, based on the probability distributions of various uncertain variables (e.g., task durations, costs). It provides a probabilistic range of possible project outcomes, useful for assessing schedule confidence or retirement fund viability.

• Delphi Technique: A structured communication technique, originally developed as a systematic, interactive forecasting method which relies on a panel of experts. The experts answer questionnaires in two or more rounds. After each round, a facilitator provides an anonymous summary of the experts’ forecasts and their reasons for them. Experts are then encouraged to revise their earlier answers in light of the replies of other members of the panel. This helps achieve consensus without direct confrontation.

Common Risk Categories:

Risks can generally be categorized to aid identification and management:

• Technical Risks: Related to technology, design, or performance.

• Management Risks: Associated with project governance, planning, or team dynamics.

• Commercial Risks: Involving contractual, legal, or market aspects.

• External Risks: Stemming from outside the project/organization (e.g., regulatory changes, natural disasters, economic shifts).

Risk Register: A document that tracks identified risks throughout the project lifecycle. For each risk, it typically includes: An ID number, category, a detailed description of the cause, probability (P), impact (I), calculated score, potential triggers (early warning signs), assigned owner, planned response strategy (e.g., mitigate, accept, avoid, transfer), and any residual risk remaining after the response.

Procurement & Contract Types (brief overview)

Procurement involves acquiring goods and services from outside the project organization. Contract types define how payments are structured and risk is allocated between buyer and seller.

• Fixed-Price (FP) Contracts: The buyer pays a fixed price for the agreed-upon work, shifting most of the financial risk to the seller. These are best when the scope is well-defined. Variations include:

  • Firm Fixed Price (FFP): Most common. Price is set at the outset and cannot be changed unless project scope changes.

  • Fixed Price with Incentive Fee (FPIF): Flexible fixed price with a fee adjustment based on meeting specified performance criteria (e.g., schedule, cost targets).

  • Fixed Price with Economic Price Adjustment (FPEPA): Used for long-term contracts where there might be future changes in economic conditions (e.g., inflation).

• Cost-Plus Contracts: The seller is reimbursed for all allowable costs incurred, plus a fee (profit). These are suitable when the scope is uncertain, and risk is primarily borne by the buyer. Variations include:

  • Cost-Plus Fixed Fee (CPFF): Seller is reimbursed for costs plus a predetermined fixed fee, regardless of project outcome.

  • Cost-Plus Incentive Fee (CPIF): Seller is reimbursed for costs plus a fee that is adjusted based on meeting performance objectives.

  • Cost-Plus Award Fee (CPAF): Seller is reimbursed for costs plus a fee determined by the buyer based on subjective performance evaluation.

• Time & Materials (T&M) Contracts: A hybrid type, featuring characteristics of both fixed-price and cost-plus. The buyer pays for time (e.g., hourly rates for labor) and direct materials. Often used when the scope isn't fully defined but some work estimation is possible. It can be open-ended or include not-to-exceed clauses.

• Agile Contracts: Agile principles emphasize flexibility and incremental delivery. Agile contracts often focus on value delivery rather than detailed upfront scope. They may price work per iteration, per backlog point, or use phased payments tied to demonstrable value increments, encouraging collaboration and adaptability.

Ethical / Practical Takeaways

Project success is not just about meeting technical specifications but also about managing stakeholder expectations, fostering transparency, and continuous learning.

• Releasing too early (e.g., a buggy Minimum Viable Product) can significantly harm a brand's reputation and customer trust, leading to negative market perception. Conversely, waiting too long to release a product or feature (e.g., striving for perfection) can cause an organization to forfeit market share to quicker competitors and miss valuable early customer feedback.

• Transparent information radiators (visual displays of project status, progress, and impediments, such as Kanban boards or burndown charts) are crucial. They foster trust among team members and stakeholders, promote self-organisation within the team by making work visible, and enable quick identification and resolution of issues.

• Properly defined Work Breakdown Structure (WBS) and a robust Requirements Traceability Matrix (RTM) are foundational tools. They give a project a "fighting chance" of success by ensuring everyone is aligned on precisely "what" needs to be delivered, preventing misunderstandings, and facilitating effective scope and change management.

• Project success fundamentally depends on continuous learning and adaptation. This is achieved through short feedback loops (e.g., frequent demonstrations, user acceptance testing), regular retrospectives (team discussions on what went well, what could be improved), and ongoing risk reviews to proactively identify and manage uncertainties. These practices enable teams to learn from experience, improve processes, and deliver better value over time.