Process — Managing Technical Aspects practice questions

Schedule forecasts

Why wrong: Schedule forecasts are a key output of the Control Schedule process, not an input. These forecasts are estimates or predictions of future project conditions and events, such as the Estimated Completion Date (EAC) or Estimated Time to Complete (ETC), based on the current work performance and schedule performance. The Control Schedule process analyzes current schedule status and trends to generate these forward-looking projections, which are then communicated to stakeholders to inform future decision-making.

Probability and impact matrix

Why wrong: The probability and impact matrix is a key tool and technique utilized within the Perform Qualitative Risk Analysis process. Its primary function is to prioritize individual project risks for further analysis or action by assessing their likelihood of occurrence and potential effect on project objectives. It is not employed during the Plan Risk Management process, which focuses on defining *how* risk management will be conducted.

Risk categorization

Why wrong: Risk categorization is a tool and technique primarily applied during the Perform Qualitative Risk Analysis process, not Plan Risk Management. It involves grouping individual project risks by common root causes, areas of the project affected, or other useful categories to determine areas of potential risk concentration. This structured grouping aids in understanding the overall project risk exposure and developing effective risk responses.

SWOT analysis

Why wrong: SWOT analysis (Strengths, Weaknesses, Opportunities, Threats) is a strategic planning tool primarily used for identifying and analyzing internal and external factors that can impact an organization or project. While it helps in identifying potential risks (threats) and opportunities, it is a qualitative technique that does not involve numerical analysis or statistical modeling to quantify the probability or impact of risks, thus it is not a quantitative risk analysis technique.

Checklist analysis

Why wrong: Checklist analysis is a risk identification technique where a pre-compiled list of potential risks, often derived from historical data or industry best practices, is used to prompt the project team to identify relevant risks for the current project. While crucial for ensuring comprehensive risk identification, it is a qualitative process focused on listing risks rather than performing numerical calculations or statistical assessments of their probability or monetary impact.

9 days

Why wrong: Calculating the total duration for all distinct sequences of activities from the project's start to its completion, as depicted in the network diagram, reveals no path that sums to exactly 9 days. This value does not correspond to any valid path duration within the project schedule. Therefore, 9 days cannot represent the critical path duration, which by definition is the longest sequence of activities.

10 days

Why wrong: While 10 days accurately represents the total duration of a specific path through the project network, namely path A-B-D, it is not the critical path. The critical path is fundamentally defined as the longest sequence of activities that dictates the minimum project completion time. Since another path exists with a longer duration (11 days), 10 days does not reflect the overall project's earliest possible completion.

12 days

Why wrong: A duration of 12 days is an overestimation and does not accurately reflect the critical path of the project. A thorough analysis of all possible activity sequences within the provided network diagram demonstrates that no single path accumulates a total duration of 12 days. Consequently, this value is not supported by the project schedule calculations and cannot be the critical path duration.

Risk budget

Why wrong: The risk budget is a critical component established during the Plan Risk Management process, detailing the funds allocated for managing project risks. This includes provisions for contingency reserves, management reserves, and the costs associated with implementing risk response strategies. It ensures that adequate financial resources are set aside to address potential threats and opportunities throughout the project lifecycle, making it an essential output documented within the risk management plan.

Work breakdown structure

Why wrong: The Work Breakdown Structure (WBS) is a hierarchical decomposition of the total scope of work required to produce the project deliverables. It is a primary output of the Create WBS process within Project Scope Management, not Project Risk Management. While the WBS serves as a fundamental input for identifying risks by providing a structured view of project components, it is not generated during the planning of how risk management will be conducted.

Probability and impact matrix

Why wrong: The Probability and Impact Matrix is a tool and technique used primarily in the Perform Qualitative Risk Analysis process to assess and prioritize individual project risks. It defines combinations of probability and impact levels to assign a risk rating (e.g., low, medium, high) to each identified risk. While the *format* and *definitions* for such a matrix are established and documented within the Risk Management Plan (an output of Plan Risk Management), the matrix itself, populated with actual risk assessments, is not an output of this initial planning process.

Risk register

Why wrong: The Risk Register is a dynamic document that records all identified individual project risks, along with their characteristics, analysis results, and planned responses. It is initially created as a key output of the Identify Risks process, where specific risks are documented for the first time. Subsequent risk management processes, such as qualitative and quantitative analysis and response planning, update and elaborate on the information within the Risk Register, but its initial generation does not occur during the Plan Risk Management process.

The 'feature/login' branch is still active and contains unmerged commits.

Why wrong: This statement is incorrect because the exhibit clearly indicates that the 'feature/login' branch has been successfully merged into 'main'. Once a branch is merged, all its commits become part of the target branch's history, meaning there are no longer any "unmerged" commits from 'feature/login' relative to 'main'. While the branch pointer itself might persist, its content has been fully integrated.

The 'feature/login' branch has not been merged into main.

Why wrong: This option is incorrect. The visual representation of the Git history, specifically the presence of a merge commit on the 'main' branch, serves as direct evidence that the 'feature/login' branch's changes have been fully incorporated. A merge commit explicitly records the integration of one branch's history into another, making this statement false.

The 'feature/login' branch is behind main by one commit.

Why wrong: This statement is inaccurate. After 'feature/login' has been merged into 'main', all commits from 'feature/login' are now present in 'main'. While 'main' might subsequently gain new commits, making 'feature/login' appear "behind" in terms of the latest 'main' state, the statement implies 'feature/login' is missing a commit that 'main' has *from its own history*, which is not the case post-merge. The branch's contributions are fully integrated into 'main'.

Stakeholder register

Why wrong: The Stakeholder Register is a project document, not a component of the Project Management Plan. It serves as a repository of information about identified project stakeholders, including their identification details, assessment (e.g., their interest, influence, involvement), and classification. While essential for stakeholder engagement planning, this register is a dynamic record of data rather than a plan dictating *how* project work or management processes will be executed.

Issue log

Why wrong: The Issue Log is a project document used to record, track, and manage project issues from identification through resolution, making it distinct from the Project Management Plan. Issues are points of contention or problems that have already occurred, requiring immediate attention and resolution, whereas the Project Management Plan defines *how* the project will be executed and controlled. Therefore, the Issue Log is an operational tracking tool, not a foundational planning component.

Project charter

Why wrong: The Project Charter is an input to the planning processes, not a component of the Project Management Plan itself. It formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities. As a high-level document created before detailed planning begins, it sets the initial scope and objectives but does not contain the detailed subsidiary plans that collectively form the Project Management Plan.

Critical chain method

Why wrong: The Critical Chain Method (CCM) is a schedule network analysis technique that focuses on managing project duration by accounting for limited resources and protecting the critical chain with strategically placed buffers. While it aims to improve the likelihood of on-time completion by optimizing resource allocation and managing uncertainty, its primary objective is not schedule compression but rather to ensure a more reliable and stable project schedule by absorbing variations.

Resource leveling

Why wrong: Resource leveling is a technique used to adjust the project schedule to optimize the allocation of resources, particularly when resources are over-allocated or their availability is constrained. It aims to smooth out resource utilization over the project's duration by shifting activities within their available float. While it prevents resource conflicts and promotes a more stable work environment, resource leveling frequently extends the project's overall duration, making it counterproductive for schedule compression.

Monte Carlo simulation

Why wrong: Monte Carlo simulation is a quantitative risk analysis technique that models the probability of different outcomes in a process influenced by random variables. In project management, it's used to assess the potential impact of risks and uncertainties on project objectives, such as schedule and cost, by running numerous iterations. It provides a statistical distribution of possible project completion dates or costs, offering insights into schedule feasibility, but it does not itself compress the schedule; rather, it helps understand the likelihood of achieving a compressed schedule.

The project is under budget and ahead of schedule

Why wrong: This option suggests the project is performing exceptionally well, being both cost-efficient and ahead of its planned schedule. To be considered "under budget," the Cost Performance Index (CPI) must be greater than 1.0, indicating that the actual cost incurred is less than the earned value. Simultaneously, to be "ahead of schedule," the Schedule Performance Index (SPI) must also be greater than 1.0, meaning more work has been completed than planned by this point. This scenario contradicts the implied project status where performance indices are likely below 1.0.

The project is under budget but behind schedule

Why wrong: This option describes a project that is managing its costs effectively but failing to meet its schedule commitments. For a project to be "under budget," its Cost Performance Index (CPI) must be greater than 1.0, reflecting that the project is spending less than planned for the work accomplished. However, to be "behind schedule," the Schedule Performance Index (SPI) must be less than 1.0, indicating that the project has completed less work than originally planned by this stage. This specific combination of performance, while possible, does not align with the scenario where both cost and schedule are underperforming.

The project is over budget but ahead of schedule

Why wrong: This option suggests a project that is exceeding its budget but is ahead of its planned timeline. To be "over budget," the Cost Performance Index (CPI) must be less than 1.0, indicating that the actual costs are exceeding the earned value for the work completed. Conversely, for the project to be "ahead of schedule," the Schedule Performance Index (SPI) must be greater than 1.0, meaning the project has completed more work than planned by this point. This combination of poor cost performance but strong schedule performance is not consistent with a scenario where both aspects are struggling.

Set stricter deadlines to motivate the team

Why wrong: Setting stricter deadlines is a command-and-control approach that contradicts agile principles of sustainable pace and self-organization. This tactic often increases stress, reduces morale, and can lead to a decline in quality as team members rush or cut corners to meet arbitrary targets. Instead of motivating, it typically fosters burnout and does not address the underlying systemic issues causing the velocity drop.

Replace underperforming team members with more experienced ones

Why wrong: Replacing team members is a highly disruptive and punitive action that undermines team cohesion and psychological safety. Agile teams are built on trust, collaboration, and continuous learning, where 'underperformance' often stems from systemic issues or lack of support, not individual failure. This approach fails to address root causes, destroys institutional knowledge, and is a last resort after all coaching and support efforts have been exhausted.

Increase the sprint length to give the team more time

Why wrong: Increasing sprint length without addressing the root causes of a velocity drop merely delays feedback and postpones the identification of critical issues. Agile emphasizes short iterations to maximize learning, reduce risk, and allow for rapid adaptation to changing requirements. Extending the sprint timebox can mask underlying problems, reduce the frequency of inspection and adaptation, and ultimately diminish the project's overall agility and responsiveness.

The project is under budget but behind schedule

Why wrong: This option is incorrect because the Cost Performance Index (CPI) is 0.71, which is less than 1. A CPI value below 1 signifies that the project is over budget, meaning it is costing more than planned for the work accomplished. While the 'behind schedule' aspect aligns with an SPI of 0.83 (less than 1), the 'under budget' claim contradicts the actual cost performance indicated by the CPI.

The project is under budget and ahead of schedule

Why wrong: This option is incorrect as both performance indicators contradict its claims. A CPI of 0.71 indicates the project is over budget, not under budget, because the cost incurred is greater than the earned value. Similarly, an SPI of 0.83 signifies the project is behind schedule, not ahead of schedule, as less work has been completed than planned by this point. Therefore, both components of this statement are factually wrong based on the given indices.

The project is over budget but ahead of schedule

Why wrong: This option is incorrect because the project is not ahead of schedule. The Schedule Performance Index (SPI) is 0.83, which is less than 1, indicating that the project has completed less work than planned by the current date, thus running behind schedule. Although the 'over budget' part is consistent with a CPI of 0.71 (less than 1), the schedule performance claim is directly contradicted by the SPI value.

Escalate the conflict to the functional manager

Why wrong: Escalating the conflict prematurely to a functional manager bypasses the project manager's primary responsibility to facilitate resolution within the project team. This action can undermine team autonomy, create dependency on external authority, and potentially damage the project manager's credibility as a leader. Project managers are expected to exhaust their conflict resolution skills and internal team-level interventions before resorting to external escalation, which should be reserved for intractable issues.

Decide on the technical approach yourself and direct the team to implement it

Why wrong: Deciding on the technical approach yourself and directing the team to implement it represents a "Forcing" conflict resolution strategy, which is generally detrimental to team morale and long-term project success. This approach disregards the valuable expertise and perspectives of senior team members, potentially leading to resentment, reduced commitment, and a lack of ownership over the solution. Sustainable technical solutions often require team consensus and buy-in to ensure effective implementation and future support.

Bring the team members together in a meeting and mediate a discussion

Why wrong: While direct mediation is a valid conflict resolution technique, initiating it without prior individual discussions can be counterproductive, especially with senior team members. Without first understanding each individual's perspective, underlying concerns, and potential sensitivities, the project manager may lack the necessary context to guide the discussion effectively. A premature group meeting could escalate tensions if participants feel unheard or ambushed, making resolution more difficult and less likely to succeed.

Add the change to the product backlog without formal approval

Why wrong: This action bypasses the critical Integrated Change Control process, which is essential for managing project baselines. Adding changes directly to the product backlog without formal review and approval from the Change Control Board (CCB) can lead to uncontrolled scope creep, budget overruns, and schedule delays. Even in agile environments, significant changes impacting project objectives or baselines require formal governance.

Instruct the team to begin work on the change immediately

Why wrong: Directing the team to implement a change without following the established change control procedures is a severe violation of project governance. This approach circumvents necessary impact analysis, stakeholder communication, and formal approval, thereby exposing the project to unmanaged risks, potential rework, and a loss of control over project scope, schedule, and cost baselines.

Politely decline the request because the project is already underway

Why wrong: Declining a stakeholder's request outright without proper evaluation demonstrates poor stakeholder management and a lack of adherence to project management best practices. All proposed changes, regardless of project phase, should be formally assessed through the change control process to determine their potential value, impact, and feasibility, rather than being dismissed prematurely.

Add the issue to the lessons learned for future projects

Why wrong: Lessons learned are documented later; immediate corrective action is needed.

Escalate the issue to the sponsor

Why wrong: Escalation is not the first step; the PM should handle it within the project.

Update the quality management plan

Why wrong: The plan itself may not need updating; the issue is with the deliverable, not the process.

Allow the team to accept some ad-hoc requests to keep stakeholders happy

Why wrong: Allowing the development team to accept ad-hoc requests during an active sprint directly violates the sprint commitment and disrupts the planned work. This practice fragments the team's focus, introduces unplanned scope, and inevitably leads to declining velocity as the team struggles to complete committed items while accommodating new demands. While stakeholder satisfaction is important, it should be managed by channeling requests through the Product Owner, not by compromising sprint integrity.

Increase the sprint length to accommodate more work

Why wrong: Increasing sprint length to accommodate more work, including ad-hoc requests, is a counterproductive measure in agile. While it might temporarily mask the issue of declining velocity, it does not address the root cause of interruptions and scope creep. Longer sprints inherently reduce the frequency of feedback loops and opportunities for inspection and adaptation, potentially delaying the discovery of critical issues and making the project less responsive to change.

Reduce the team size to minimize communication overhead

Why wrong: Reducing team size to minimize communication overhead is an inappropriate response to declining velocity caused by ad-hoc requests. While communication overhead can be a factor in large teams, a smaller team inherently possesses less capacity to deliver work, potentially exacerbating the velocity decline rather than improving it. This action does not address the fundamental problem of uncontrolled scope changes and interruptions, which are the primary drivers of the velocity issue.

Praise the team for their initiative and innovation

Why wrong: Praising the team for adding unauthorized features, known as gold-plating, is detrimental to project success. This action undermines the principles of scope control and encourages further deviation from the approved scope baseline, potentially leading to wasted resources, increased costs, and schedule delays. It sends a message that unauthorized work is acceptable, which contradicts effective project governance.

Update the scope baseline to include the extra features

Why wrong: Updating the scope baseline to retroactively include unapproved extra features is an inappropriate response to gold-plating. The scope baseline represents the formally approved project scope, and any changes must undergo a formal change control process, including stakeholder review and approval. Legitimizing unauthorized work bypasses governance, encourages future gold-plating, and can lead to uncontrolled scope creep becoming an accepted practice.

$625,000

Why wrong: This value likely results from an incorrect calculation where the Budget At Completion (BAC) of $500,000 is divided by a Cost Performance Index (CPI) of 0.80 instead of the actual CPI of 0.85. While using a CPI in the denominator is the correct approach for EAC calculation when assuming future performance will continue at the same rate, applying an incorrect CPI value leads to an inaccurate estimate. This error demonstrates a misidentification or miscalculation of the project's cost efficiency.

$555,555

Why wrong: This value could arise from an incorrect application of Earned Value Management formulas, potentially by misusing the Schedule Performance Index (SPI) in a cost-related forecast or by employing an alternative EAC formula inappropriately. For instance, if one were to incorrectly calculate EAC = AC + (BAC - EV) / SPI, or some other variation, it would lead to an erroneous result. The standard EAC formula for projecting future costs based on current cost performance does not directly incorporate SPI in this manner, making this calculation method flawed for determining the final project cost.

$500,000

Why wrong: This value represents the Budget At Completion (BAC), which is the total planned budget for the project. However, the Cost Performance Index (CPI) being less than 1 (specifically 0.85, as implied by the correct answer) indicates that the project is currently over budget. Therefore, the Estimate At Completion (EAC) must be higher than the BAC to reflect the current cost performance trend, making $500,000 an incorrect EAC.

Immediately inform the project team to stop work on affected deliverables.

Why wrong: Immediately informing the project team to stop work on affected deliverables without prior analysis, formal approval, or a clear mitigation plan is a premature and highly disruptive action. Such an unapproved halt can lead to unnecessary project delays, increased costs due demobilization and remobilization efforts, and potential team demoralization, all without a justified or strategic basis.

Escalate the issue to the project sponsor for a decision on how to proceed.

Why wrong: Escalating the issue directly to the project sponsor for a decision on how to proceed, without first conducting a thorough impact analysis or preparing a proposed solution, bypasses the project manager's primary responsibility. The PM is expected to analyze problems, develop options, and present a well-reasoned change request to the CCB, only escalating to the sponsor for strategic guidance or approval on matters beyond the CCB's authority.

Increase automated test coverage.

Why wrong: Increasing automated test coverage primarily enhances product quality and reduces the likelihood of defects by verifying functionality against requirements. While crucial for quality assurance, this technical practice does not inherently facilitate direct interpersonal communication or information exchange between team members or different roles. It is a quality control mechanism, not a communication strategy designed to resolve breakdowns in team dialogue or understanding.

Adopt a kanban board to visualize workflow.

Why wrong: Adopting a Kanban board provides excellent visual transparency of work items and their status within the workflow, which can indirectly aid communication by making work visible to everyone. However, its primary purpose is to optimize flow and limit work in progress, rather than directly facilitating the interpersonal dialogue and explicit information exchange needed to resolve communication breakdowns between different roles. While helpful for tracking, it doesn't compel the same level of direct interaction as other methods.

Ask the team to compress the schedule by overlapping activities to recover the delay.

Why wrong: While schedule compression techniques such as fast-tracking (overlapping activities) can be considered to recover delays, simply asking the team to implement it without formal process is incorrect. Any significant change to the project schedule, particularly one that impacts the approved schedule baseline or introduces new risks, requires a formal change request and approval through the integrated change control process. This ensures all stakeholders are aware and agree to the revised plan and its potential implications.

Invoke the 'accept' response and do nothing further, as it was planned.

Why wrong: Invoking an 'accept' risk response means acknowledging the possibility of a risk occurring and its potential impact, but it does not imply inaction once the risk materializes. If the delay, even if accepted as a risk, impacts the project's approved schedule baseline, the project manager is still obligated to manage this impact. This requires initiating the change control process to formally adjust the schedule and baseline, rather than simply doing nothing.

Immediately escalate to the sponsor for additional budget to expedite delivery.

Why wrong: Immediately escalating to the sponsor for additional budget to expedite delivery is premature and bypasses established project management processes. The project manager's initial responsibility is to assess the situation, utilize planned risk responses, and follow the integrated change control process to manage the delay within the project team's authority. Escalation is reserved for issues that exceed the project manager's authority or require strategic guidance, not as a first response to a schedule delay.