Project Management Qualification (PMQ) Quiz 32

Correct: Engaging in a one-on-one dialogue allows the project manager to build rapport and understand the root cause of the resistance. By validating the stakeholder’s concerns and seeking collaborative solutions, the project manager can turn a resistant stakeholder into a supportive one. Incorrect: Formally documenting the lack of cooperation and escalating to the Steering Committee is a reactive measure that can damage the relationship and should only be used after direct engagement has failed. Incorrect: Publicly highlighting delays to create peer pressure is a confrontational tactic that likely increases hostility and undermines trust. Incorrect: Bypassing the stakeholder and limiting their involvement may solve short-term data needs but creates significant long-term risks, as the stakeholder may sabotage the final transition or refuse to adopt the new system. Key Takeaway: Effective stakeholder management relies on empathy and proactive communication to address the underlying motivations of resistance rather than relying on authority or avoidance.

Correct: The project manager uses social proof by highlighting that other influential peers (Marketing and Sales Directors) have already agreed to the plan, which reduces the Operations Director’s perceived risk by showing that others find the plan acceptable. By inviting the Director to co-design the implementation sequence, the project manager uses consultation, which increases buy-in by giving the stakeholder a sense of ownership and ensuring their specific concerns are addressed directly in the plan. Incorrect: Coalition building and pressure is incorrect because while there is a hint of a coalition, the project manager is not using threats, constant reminders, or formal power to force a decision, which characterizes the pressure tactic. Incorrect: Rational persuasion and exchange is incorrect because while data is mentioned, the core of the strategy relies on peer influence rather than just logical arguments. Exchange is not used because the project manager is not offering a specific favor or trade-off in return for the approval. Incorrect: Personal appeal and legitimating is incorrect because the project manager is not asking for a favor based on a personal friendship, nor are they relying on formal rules, policies, or official authority to mandate the downtime. Key Takeaway: Effective stakeholder management often requires a blend of techniques; social proof leverages the power of peer behavior, while consultation transforms a potential opponent into a collaborator by involving them in the decision-making process.

Correct: Monitoring stakeholder engagement is a continuous process. The stakeholder engagement assessment matrix is a powerful tool for identifying gaps between current and desired levels of engagement, allowing the project manager to see where intervention is needed. Supplementing this with informal pulse surveys or one-on-one conversations provides qualitative data on sentiment that formal reports might miss. Incorrect: Reviewing the project schedule and milestones focuses on project performance metrics rather than stakeholder sentiment; while a delay might be a symptom of poor engagement, it does not help in monitoring the sentiment itself. Incorrect: Mandating attendance at formal meetings is a reactive and potentially counterproductive measure that does not measure sentiment; it may actually increase resentment if the stakeholder feels their time is being wasted. Incorrect: Updating the stakeholder register only at the end of a phase is insufficient for active monitoring, as stakeholder attitudes can shift rapidly and require more frequent observation and adjustment of engagement strategies. Key Takeaway: Effective stakeholder monitoring requires a combination of analytical tools like the engagement assessment matrix and interpersonal techniques to detect shifts in sentiment before they impact project delivery.

Correct: Establishing iterative review sessions and demonstrations is the most effective way to create a continuous feedback loop. This approach allows stakeholders to see tangible progress and provide input in real-time, which ensures that the project remains aligned with their needs and reduces the risk of significant rework later in the lifecycle. Incorrect: Increasing the frequency of steering committee meetings focuses on governance and oversight rather than a collaborative feedback loop; it may also lead to meeting fatigue without improving the quality of the feedback. Distributing monthly progress reports and requesting written feedback is a form of one-way communication that lacks the interactive element necessary for deep engagement and immediate clarification. Updating the stakeholder engagement plan to include more formal sign-off stages is a control mechanism that can actually slow down the project and create an adversarial environment rather than fostering the collaborative, continuous engagement required for success. Key Takeaway: Effective stakeholder engagement relies on two-way communication and iterative feedback loops that allow for timely adjustments throughout the project lifecycle.

Correct: Collaboration, also known as problem-solving, involves incorporating multiple viewpoints and insights from differing perspectives. It requires a cooperative search for a solution that satisfies the underlying concerns of all parties, leading to long-term commitment and consensus. Incorrect: Compromise involves each party giving up something to reach a middle ground. While it can be quick, it often results in a lose-lose outcome where neither party is fully satisfied with the result. Incorrect: Smoothing, or accommodating, focuses on areas of agreement rather than differences. This approach is often temporary because it fails to address the root cause of the conflict, allowing the issue to resurface later. Incorrect: Forcing, or directing, involves one party imposing their will on the other. This typically creates resentment and damages stakeholder relationships, which is counterproductive for long-term project success. Key Takeaway: Collaboration is the preferred method for resolving complex stakeholder disputes as it fosters trust and ensures the final decision is robust and mutually beneficial.

Correct: Effective global stakeholder management requires recognizing that different cultures have varying communication styles, such as high-context versus low-context communication. By developing a communication management plan that uses diverse feedback mechanisms like one-on-one sessions, the project manager respects the cultural preference for saving face or indirect communication often found in Japanese business culture. Simultaneously, a team charter helps set ground rules that manage more expressive styles, ensuring a balanced and inclusive environment. Incorrect: Forcing stakeholders to speak for a set time can cause significant discomfort and may not result in honest feedback if the cultural norm is to avoid public confrontation. Incorrect: Assuming that silence equals consent is a common pitfall in cross-cultural management; in many cultures, silence may indicate disagreement, reflection, or a desire to avoid conflict. Incorrect: While clear language is important, attempting to strip away all cultural nuance through purely technical language often fails because the interpretation of ‘directness’ itself is culturally dependent and can lead to perceived rudeness or further confusion. Key Takeaway: Successful global project management involves adapting communication strategies to bridge cultural gaps rather than forcing a single, rigid style on a diverse group of stakeholders.

Correct: Referring to the scope baseline and implementing formal change control is the most effective way to manage scope creep. The scope baseline, which consists of the project scope statement, WBS, and WBS dictionary, defines the agreed-upon work. By using a formal change control process, the project manager ensures that every change is evaluated for its impact on cost, time, and quality before approval, maintaining the integrity of the project boundaries. Incorrect: Increasing the frequency of status meetings might improve communication, but it does not provide a mechanism to stop or manage unauthorized changes to the project scope. Incorrect: Updating the risk register identifies the symptom of the problem (schedule slippage) but does not address the cause (uncontrolled scope expansion) or provide a solution to manage the client’s requests. Incorrect: Re-baselining the project schedule and requesting additional funding without a formal evaluation of the changes essentially rewards scope creep and bypasses the governance required to ensure the project remains viable and aligned with its business case. Key Takeaway: Effective scope management depends on a clearly defined scope baseline and a rigorous change control process to prevent undocumented work from impacting project performance.

Correct: Facilitated workshops are highly effective for resolving conflicts and building consensus because they bring key stakeholders together in a structured environment to discuss requirements in real-time. This collaborative approach allows for immediate clarification, negotiation, and collective decision-making. Incorrect: One-on-one interviews are excellent for gathering detailed individual perspectives but are time-consuming and do not provide a platform for stakeholders to resolve their differences or understand competing priorities directly. Incorrect: Online surveys and questionnaires are useful for collecting data from a large, geographically dispersed group but lack the interactive element required to navigate complex disagreements or explore nuanced requirements. Incorrect: Passive observation helps the project team understand how users currently perform tasks in their natural environment but does not facilitate the active negotiation or prioritization needed when stakeholders have conflicting goals. Key Takeaway: When stakeholder requirements conflict, interactive group techniques like workshops are superior to individual or passive methods for achieving alignment and reaching a consensus.

Correct: A requirements traceability matrix (RTM) is a grid that links product requirements from their origin to the deliverables that satisfy them. It helps ensure that each requirement adds business value by linking it to the project and business objectives. It also provides a structure for tracking requirements throughout the project life cycle, ensuring that requirements approved in the requirements documentation are delivered at the end of the project and verified through testing. Incorrect: Updating the project schedule focuses on the timing of activities rather than the logical linkage between business needs and technical solutions. While more reviews might improve communication, they do not provide the formal tracking mechanism offered by a traceability matrix. Creating a detailed work breakdown structure (WBS) is essential for defining the total scope of work, but the WBS focuses on deliverables and work packages rather than the bidirectional tracking of individual requirements to business goals. Performing a cost-benefit analysis is a tool used during project selection or change control to evaluate the financial viability of a requirement, but it does not provide the traceability needed to ensure a requirement is actually met and tested. Key Takeaway: The requirements traceability matrix is the primary tool used to ensure alignment between the business case, requirements, and final deliverables, preventing scope creep and ensuring all objectives are met.

Correct: Defining exclusions is a critical part of scope management because it establishes the project boundaries. By explicitly stating what is not part of the project, the project manager reduces the risk of stakeholders making assumptions about deliverables, which is a primary cause of scope creep and conflict during the project lifecycle. Incorrect: Identifying specific internal staff members who are excluded from the team is part of resource management and human resource planning, not scope definition. Incorrect: Listing legal clauses and liability limitations is the function of the legal contract or terms and conditions, rather than the Statement of Work which focuses on the work to be performed. Incorrect: Providing a breakdown of removed budget items relates to cost management and financial reconciliation; while it may be discussed during planning, it is not the purpose of the exclusions section in a Statement of Work. Key Takeaway: A robust Statement of Work must define both what is in scope and what is out of scope to ensure a shared understanding of the project’s limits among all stakeholders.

Correct: The Work Breakdown Structure (WBS) is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team. Its primary purpose is to define the total scope of the project and ensure that all necessary work is captured. The lowest level of the WBS is the work package, which is the point at which cost and duration can be reliably estimated and managed. Incorrect: Establishing a chronological sequence of tasks describes the project schedule or network diagram, not the WBS. While activities are derived from work packages during the scheduling process, the WBS itself focuses on deliverables rather than the timing of tasks. Incorrect: Creating a functional organizational chart refers to an Organizational Breakdown Structure (OBS), which defines the project’s reporting relationships and resource structure rather than the work scope. Incorrect: Mapping financial expenditure relates to the budget or cost baseline. While a WBS can be integrated with cost accounts for financial tracking, its primary purpose is scope definition and decomposition. Key Takeaway: The WBS is the foundation of project planning because it defines the 100 percent rule, ensuring that all work and only the required work is included in the project.

Correct: The process of defining activities involves taking the work packages identified in the WBS and breaking them down into smaller, more manageable components called activities. These activities represent the actual work required to complete the deliverable associated with the work package, allowing for more accurate duration and cost estimation. Incorrect: Aggregating work packages into control accounts is a valid step for management and financial tracking, but it does not provide the level of detail needed for scheduling or resource allocation at the task level. Incorrect: Assigning work packages as milestones is inappropriate because work packages represent effort and deliverables, whereas milestones are points in time with zero duration; furthermore, this approach lacks the necessary detail for execution. Incorrect: Mapping work packages to the Organizational Breakdown Structure (OBS) helps define responsibility by creating a Responsibility Assignment Matrix, but it does not define the specific work steps or activities required to build the schedule. Key Takeaway: Work packages are the lowest level of the WBS, but they must be further decomposed into activities to create a functional project schedule and enable detailed resource management.

Correct: The Product Breakdown Structure (PBS) is a hierarchical structure that focuses exclusively on the physical deliverables or products of a project. In this scenario, it would break the locomotive down into its constituent parts, such as the chassis, engine, braking system, and control electronics. This helps ensure that the scope is clearly defined in terms of what is being built. Incorrect: Focusing on work packages and tasks describes a Work Breakdown Structure (WBS), which is activity-oriented rather than product-oriented. Representing project team members and reporting lines describes an Organizational Breakdown Structure (OBS), which focuses on the human resources assigned to the project. A matrix identifying risks associated with components describes a Risk Breakdown Structure (RBS) or a risk register, rather than a PBS. Key Takeaway: The PBS defines the ‘what’ of the project (the deliverables), while the WBS defines the ‘how’ (the work required to produce those deliverables).

Correct: The Cost Breakdown Structure (CBS) is a hierarchical representation of the project’s costs. By aligning the CBS with the Work Breakdown Structure (WBS), the project manager can ensure that every element of the project scope has an associated budget. This alignment is critical for effective cost control, as it allows for the aggregation of costs from the lowest work package level up to the total project level, facilitating the identification of where variances are occurring. Incorrect: The option suggesting the CBS replaces the WBS is incorrect because the two structures are complementary; the WBS defines the scope while the CBS defines the financial allocation for that scope. The option describing the CBS as a chronological list of expenditures is incorrect because that describes a cash flow statement or ledger; a CBS is organized by cost category or work element, not by time. The option stating the CBS is used exclusively during project closure is incorrect because the CBS is a vital planning and monitoring tool used throughout the project lifecycle to manage and control the budget. Key Takeaway: The CBS must be integrated with the WBS to provide a clear framework for financial accountability and performance measurement across all project deliverables.

Correct: Halting unauthorized work and requiring a formal change request is the standard procedure for managing scope. This ensures that the change is evaluated for its impact on time, cost, quality, and risk before it is officially integrated into the project. This process maintains the integrity of the project baseline and prevents the cumulative negative effects of unmanaged changes. Incorrect: Documenting the change in the issue log while allowing work to continue fails to address the root cause of scope creep. It sets a precedent that unauthorized changes are acceptable, which can lead to significant project drift and resource depletion. Incorrect: Updating the scope statement and work breakdown structure immediately bypasses the necessary evaluation and approval steps. Changes to the baseline should only occur after a formal change control board or project manager review has determined the change is beneficial and feasible. Incorrect: Requesting additional contingency funds without first evaluating the necessity or impact of the change is poor financial management. Contingency is intended for identified risks, not for accommodating unmanaged scope additions that have not been through a formal approval process. Key Takeaway: Effective scope management requires strict adherence to a change control process to ensure all modifications are vetted for their impact on project objectives before implementation.

Correct: Configuration audit is the formal process of verifying that a configuration item conforms to its specified requirements and that the configuration records accurately reflect the item’s physical state. This ensures that what was built matches what was designed and approved. Incorrect: Configuration status accounting is the activity of recording and reporting the status of configuration items, such as a history of changes and the current version, rather than the physical verification of the product itself. Incorrect: Configuration identification involves defining the scope of the configuration management system, selecting configuration items, and assigning unique identifiers, which typically occurs early in the lifecycle. Incorrect: Configuration control focuses on the process of managing changes to configuration items through a formal approval process, but it does not encompass the final verification of the physical product against its documentation. Key takeaway: Configuration management ensures product integrity by maintaining a consistent relationship between the product, its requirements, and its documentation throughout the project lifecycle.

Correct: Status accounting is the administrative procedure of recording and reporting the status of configuration items. It provides a continuous record of the status of proposed changes and the implementation status of approved changes, ensuring that there is a clear history of the item’s evolution. Incorrect: Configuration identification involves defining the scope, naming conventions, and unique identifiers for configuration items, but it does not track their ongoing status or change history. Incorrect: Configuration verification and audit is a formal check to ensure that the configuration item matches its functional and physical requirements and that the documentation is accurate; it is a point-in-time check rather than ongoing status tracking. Incorrect: Change control is the process of evaluating, approving, or rejecting changes to the project’s baselines, whereas status accounting is the reporting mechanism that tracks those changes once they are processed. Key Takeaway: Status accounting acts as the memory of the configuration management system, providing stakeholders with the current state and history of any configuration item.

Correct: A configuration audit is a formal review to ensure that a deliverable matches its configuration documentation and that all approved changes have been correctly incorporated and recorded. It confirms the integrity of the configuration management system by verifying that the physical product and its functional performance align with the technical specifications and version history. Incorrect: Quality control inspection focuses on identifying defects and ensuring the product meets specific quality standards, but it does not specifically validate the accuracy of version records or the configuration baseline. Incorrect: Scope validation is the process of obtaining formal acceptance of the completed project deliverables from the customer or sponsor, which is a broader acceptance process rather than a technical configuration check. Incorrect: Change control board review is the decision-making process where proposed changes are evaluated for approval or rejection; it occurs during the planning and execution phases rather than as a final verification of the implemented state. Key Takeaway: Configuration audits are essential for ensuring that the final deliverable is exactly what was documented and approved, providing a reliable baseline for future maintenance and operations.

Correct: The integration of change control and scope management requires that any modification to the agreed-upon scope must follow a formal process. This starts with documenting the request in a change log and performing an impact analysis to understand how the change affects the scope baseline, budget, and schedule. Only after formal approval from the Change Control Board or designated authority should the Work Breakdown Structure and other baseline documents be updated. Incorrect: Incorporating the change into the Work Breakdown Structure immediately bypasses formal governance and leads to unauthorized scope creep. Incorrect: Stating that the scope baseline is fixed and cannot be changed is incorrect, as project management frameworks allow for managed changes to ensure the project remains relevant to stakeholder needs. Incorrect: Revising the scope statement and project management plan before receiving formal approval is a violation of configuration management principles, as baselines should only be updated after a change is authorized. Key Takeaway: Change control ensures that the scope baseline is only modified through a deliberate, transparent, and approved process, protecting the project from uncontrolled changes.

Correct: Resource smoothing is a resource optimization technique that adjusts the activities of a schedule model such that the shared resources on the project do not exceed certain pre-defined resource limits. Unlike resource leveling, resource smoothing does not change the project’s critical path, and the completion date is not delayed. Activities are only delayed within their free and total float, making it the ideal choice when the end date is fixed. Incorrect: Resource leveling is a technique in which start and finish dates are adjusted based on resource constraints with the goal of balancing demand for resources with the available supply. This often causes the original critical path to change, usually resulting in a delay to the project completion date, which violates the scenario’s constraint. Incorrect: Fast tracking is a schedule compression technique where activities or phases normally done in sequence are performed in parallel for at least a portion of their duration. While it can shorten a schedule, it does not specifically address resource over-allocation and often increases risk. Incorrect: The critical chain method is a schedule network analysis technique that takes into account resource limitations and adds buffers to manage uncertainty. While it considers resources, it is a fundamental shift in scheduling methodology rather than a specific technique to resolve a temporary over-allocation within an existing CPM schedule without moving the end date. Key Takeaway: When the project end date is fixed and cannot be delayed, resource smoothing is the appropriate technique to manage resource peaks by utilizing available float.

Correct: Parametric estimating involves using a statistical relationship between historical data and other variables to calculate an estimate for activity parameters such as duration or cost. In this scenario, the project manager uses a specific unit rate (4 hours per database) and multiplies it by the quantity of work (250 databases) to derive the total, which is a classic application of a parametric model. Incorrect: Analogous estimating uses the actual duration of a previous, similar project as the basis for estimating the current project. It is typically a top-down approach used when there is limited detail, rather than a calculation based on unit rates. Incorrect: Three-point estimating (such as PERT) requires the identification of three different values—optimistic, most likely, and pessimistic—to account for uncertainty, which was not used in this calculation. Incorrect: Expert judgment relies on the knowledge and experience of individuals to provide an estimate. While an expert might provide the historical data, the specific method of using a mathematical scale or unit rate defines the technique as parametric. Key Takeaway: Parametric estimating is a highly accurate, quantitative technique that relies on the relationship between variables to calculate duration or cost, provided the underlying historical data is reliable.

Correct: The PERT (Program Evaluation and Review Technique) or Beta distribution formula is calculated as (Optimistic + 4 x Most Likely + Pessimistic) divided by 6. In this scenario, the calculation is (12 + (4 x 18) + 36) / 6, which equals 120 / 6 = 20 days. This method is preferred for uncertainty because it weights the most likely estimate more heavily than the extremes, providing a more realistic expected value than a simple average. Incorrect: 22 days is the result of the Triangular distribution formula (Optimistic + Most Likely + Pessimistic) divided by 3. This method is typically used when there is less historical data or when the distribution is not expected to follow a normal curve. Incorrect: While 20 days is the correct numerical result, the explanation that it identifies the absolute midpoint between optimistic and pessimistic values is false; the midpoint between 12 and 36 is 24. Incorrect: 24 days is not the result of the PERT formula, and the explanation regarding a standard deviation buffer describes a different risk management technique rather than the calculation of an expected duration. Key Takeaway: PERT (Beta distribution) provides a more statistically robust estimate by weighting the most likely scenario four times more than the optimistic or pessimistic scenarios.

Correct: Finish-to-Finish (FF) is the correct choice because it represents a relationship where the successor activity (packaging) cannot be completed until the predecessor activity (quality audit) has been completed. This allows for overlapping work but ensures the final output is dependent on the prior completion of the audit. Incorrect: Finish-to-Start (FS) is incorrect because it would mean the packaging cannot start until the audit is finished, which contradicts the scenario stating packaging can begin earlier. Incorrect: Start-to-Start (SS) is incorrect because it focuses on the initiation of activities rather than the completion requirements specified in the scenario. Incorrect: Start-to-Finish (SF) is incorrect because it describes a rare relationship where the completion of a successor depends on the start of a predecessor, which is the opposite of the logic required for a quality audit and finalization. Key Takeaway: Identifying the correct logical dependency ensures that the project schedule reflects the true constraints of the work, allowing for parallel processing while maintaining quality control.

Correct: The critical path is the longest sequence of dependent activities through a project network. In this scenario, there are two possible paths to completion. Path 1 consists of A-B-C-D-F, which totals 4 + 6 + 10 + 5 + 3 = 28 days. Path 2 consists of A-B-E-F, which totals 4 + 6 + 8 + 3 = 21 days. Since Path 1 is the longest, it is the critical path and determines the minimum project duration. Incorrect: A-B-E-F with a duration of 21 days is a valid path through the network, but because it is shorter than the other path, it contains float and is not the critical path. Incorrect: A-B-C-D-F with a duration of 25 days identifies the correct sequence of activities but provides an incorrect mathematical sum of the durations. Incorrect: A-B-C-E-F with a duration of 31 days is an invalid path because the scenario states that Activity E follows Activity B, not Activity C. Key Takeaway: The critical path is the sequence of activities that represents the longest path through a project, which determines the shortest possible project duration. Any delay in a critical path activity will delay the project finish date.

Correct: Total float is the amount of time an activity can be delayed without delaying the project completion date, calculated as Late Finish minus Early Finish (28 – 18 = 10 days). Free float is the amount of time an activity can be delayed without delaying the early start of its successor, calculated as the Early Start of the successor minus the Early Finish of the current activity (24 – 18 = 6 days). Therefore, Activity A can be delayed by 6 days before it impacts Activity B, and 10 days before it impacts the project end date. Incorrect: The option suggesting 10 days of free float and 6 days of total float incorrectly swaps the definitions and calculations of the two types of float. Incorrect: The option stating the activity is on the critical path is incorrect because activities on the critical path have zero total float; a total float of 10 days indicates the activity is on a non-critical path. Incorrect: The option suggesting 12 days of free float and 16 days of total float uses incorrect mathematical formulas that do not align with standard network analysis techniques. Key Takeaway: Total float relates to the project finish date, while free float relates to the next logical activity in the sequence.

Correct: Milestone charts are the most effective tool for executive-level reporting because they filter out the noise of daily operations and focus exclusively on major achievements, key dates, and significant transition points in the project lifecycle. This allows stakeholders to quickly assess project health against high-level goals. Incorrect: A detailed Gantt chart is often too cluttered for executive review, as it contains granular task data that can distract from the overall project status. Incorrect: A project network diagram is a technical tool used primarily by the project team to understand logic and dependencies; it lacks a clear calendar-based timeline which makes it difficult for executives to interpret schedule progress. Incorrect: A resource histogram is a tool for resource management and capacity planning, not for visualizing schedule progress or the achievement of project deliverables. Key Takeaway: The choice of schedule visualization should always be tailored to the audience; use milestone charts for high-level stakeholders and Gantt charts for the project team and functional managers.

Correct: Finish-to-Finish with a 5-day lag is the correct choice because the scenario describes a relationship where the completion of the successor (testing) is dependent on the completion of the predecessor (installation). In the Precedence Diagramming Method, a Finish-to-Finish (FF) relationship links the finish of one activity to the finish of another. The 5-day requirement represents a delay or waiting period, which is defined as a lag. Incorrect: Finish-to-Start with a 5-day lag is incorrect because this would imply that the testing phase cannot begin until 5 days after the installation ends. The scenario specifically links the completion of the two activities, not the start of the second to the finish of the first. Incorrect: Finish-to-Finish with a 5-day lead is incorrect because a lead (or negative lag) would imply that the testing phase could be finished 5 days before the installation is finished, which contradicts the requirement for a delay. Incorrect: Start-to-Finish with a 5-day lag is incorrect because this relationship type, where the start of a predecessor controls the finish of a successor, is rarely used and does not match the logic of one task’s completion being dependent on another task’s completion. Key Takeaway: When the completion of an activity is logically tied to the completion of its predecessor, a Finish-to-Finish relationship is required, and any necessary delay between those two points is represented as a lag.

Correct: Crashing is the schedule compression technique used to shorten the project duration for the least incremental cost by adding resources to critical path activities. Because the sponsor has provided additional funding and specifically prohibited increased risk or rework, crashing is the ideal solution as it focuses on resource injection rather than changing the logic of the schedule. Incorrect: Fast tracking involves overlapping activities that were originally planned to occur in sequence. This technique often leads to rework and increased risk because work is performed without the full information from preceding tasks, which contradicts the sponsor’s requirements in this scenario. Incorrect: Resource leveling is a resource optimization technique that often extends the project duration to ensure resource usage does not exceed limits; it is not a compression technique. Incorrect: Scope creep is the uncontrolled expansion of project scope without adjustments to time or cost; it is a negative project phenomenon rather than a managed technique to recover a schedule. Key Takeaway: Crashing increases cost to save time, while fast tracking increases risk to save time.

Correct: Resource leveling is a technique used to address resource over-allocation by adjusting the project schedule based on resource constraints. Because leveling prioritizes resource availability over time constraints, it often results in the original critical path being modified and the project completion date being pushed out to accommodate the limited resource capacity. Incorrect: The option suggesting the end date remains unchanged while redistributing workload using float describes resource smoothing. Smoothing is a time-constrained technique used when the project must be completed by a specific date, whereas leveling is used when resource limits are the primary constraint. Incorrect: Hiring an additional crane or authorizing overtime describes a schedule compression technique known as crashing. While this might solve the resource issue, it is a different management strategy than resource leveling. Incorrect: Changing logical relationships to overlap tasks describes fast tracking. Fast tracking is a schedule compression technique that often increases risk and does not resolve the issue of a single resource being over-allocated across concurrent tasks; in fact, it often worsens resource conflicts. Key Takeaway: Resource leveling is a resource-constrained scheduling method that typically extends the project duration, whereas resource smoothing is a time-constrained method that works within existing float.

Correct: Resource smoothing is a resource optimization technique used when the project’s end date is fixed and cannot be delayed. It focuses on evening out the peaks and troughs of resource usage by rescheduling activities that have float. Since only non-critical activities are moved within their float limits, the critical path and the project completion date remain unchanged. Incorrect: Delaying activities beyond their float and potentially extending the project completion date describes resource leveling, which is used when resource limits are the primary constraint rather than time. Incorrect: Assigning additional resources to critical path activities to reduce duration is known as crashing, which is a schedule compression technique, not a method for smoothing resource fluctuations. Incorrect: Resequencing tasks to perform them in parallel is known as fast tracking, which aims to shorten the schedule but does not specifically address the smoothing of resource demand profiles. Key Takeaway: The fundamental difference between resource smoothing and resource leveling is that smoothing does not delay the project completion date because it only utilizes available float, whereas leveling may extend the schedule to accommodate resource constraints.