PMI Practice Questions, Discussions & Exam Topics by our Authors
A team member does not understand what the project risks are or the impact that they could have. How should an agile leader co...
When communicating project risks to a team, it’s essential to provide information in a way that is clear, actionable, and directly relevant to the team’s work. The goal is to make sure that everyone understands the risks, their potential impact, and how to address them. Let’s evaluate each option:
A) Create a RACI chart (responsible, accountable, consulted, informed) that identifies who is accountable for each risk.
- Rejected: While the RACI chart is useful for clarifying roles and responsibilities in a project, it doesn't directly address the understanding of risks themselves. It focuses on who is responsible for communication or resolution but does not effectively communicate the nature of the risks, their potential impact, or how they will affect the project. This option is more of a governance tool than a method for educating the team about risks.
B) Create a Gantt chart that includes slack to accommodate for unknowns.
- Rejected: A Gantt chart is a scheduling tool that provides a timeline for project tasks, and while it can be helpful in planning, it doesn't directly communicate risks or their impacts. Including slack for unknowns might give the team some buffer for unforeseen issues, but it doesn’t explain the actual risks, their likelihood, or their potential impact. The team needs a more direct understanding of what specific risks exist and how they could affect their work, rather than just time allowances.
C) Create a communications management plan that details who is responsible for communicating risks.
- Rejected: While the communications management plan is important for outlining the flow of information in a project, it doesn’t directly address the team’s understanding of the risks themselves. This plan outlines who will communicate what, but it doesn’t provide a mechanism for the team to actively engage with, understand, or mitigate risks in real time. ...
Author: Ravi Patel · Last updated Jul 9, 2026
A large, corporate organization is forced to hire new team members in a geographically remote location from the current team. The manager of the department is concerned about the team not bein...
In a situation where a large, corporate organization has hired new team members in a geographically remote location, it is important to assess how well the team is collaborating and whether the new arrangement is causing any disruptions in the team’s cohesion and efficiency. Let’s analyze the options provided to understand the best indicator of a team not working well together.
A) Team members are sending more emails to the team.
- Rejected: While an increase in email communication might suggest a shift in how the team is communicating, it doesn't necessarily indicate poor collaboration. In fact, depending on the context, sending more emails could be a sign that team members are adapting to the new communication tools and trying to bridge the gap created by the physical distance. More emails alone don't directly reflect ineffective collaboration. There may still be productive discussions happening asynchronously or through other communication channels.
B) The duration of feedback cycles has increased.
- Selected: This is a strong indicator that the team may not be working well together. Increased feedback cycles often suggest that communication is not flowing efficiently, and it is taking longer for team members to provide input or make decisions. This delay could be caused by several factors, such as a lack of synchronous communication, misunderstandings due to time zone differences, or inefficient collaboration tools. Agile teams thrive on fast, iterative feedback loops, and an increase in feedback cycles typically signals a breakdown in this process. This is especially important in remote teams, where the lack of face-to-face interaction can create delays in decision-making and problem-solving.
C) The velocity has increased by having the new team work on items.
- Rejected: An increase in velocity is generally a positive sign, as it indicates the team is completing more work over a given time period. This could even suggest that the new remote team members are adapting quickly and becoming productive. Ho...
Author: Emma Brown · Last updated Jul 9, 2026
A software company is developing an accounting software system to market to customers. The team has been working on the project for six weeks and has great velocity. One of the major stakeholders approached the scrum master and asked for a bi-weekly status repo...
In this scenario, the scrum master should prioritize open communication, transparency, and maintaining alignment with stakeholders. The key factors in deciding how to respond involve adhering to Scrum principles, fostering collaboration, and ensuring that stakeholders are informed without unnecessary overhead. Let's analyze each option:
Option A: Inform the stakeholder that all updates are provided in the sprint review sessions and encourage them to attend.
- Reasoning: Scrum emphasizes regular, structured communication through events like sprint reviews, where progress is shared and feedback is gathered. The stakeholder's request for a bi-weekly report can be seen as a sign that they want more frequent updates, but in Scrum, the sprint review is the formal forum for such updates. Encouraging the stakeholder to attend these sessions aligns with Scrum values of collaboration and transparency. It avoids creating extra work by generating separate reports while still keeping the stakeholder involved.
- When to use: This is the most appropriate response if the stakeholder is willing to attend the sprint review sessions and engage directly with the team, as it fosters transparency and regular feedback.
Option B: Create and update bi-weekly project status reports for the stakeholder who requested the report.
- Reasoning: While this might seem like an immediate solution, it goes against Scrum's principle of minimizing unnecessary documentation and overhead. By creating a separate bi-weekly report, the scrum master could inadvertently increase the burden on the team without significantly improving the stakeholder's understanding. Moreover, if this report merely restates what is already c...
Author: BlazingPhoenix22 · Last updated Jul 9, 2026
The project lead of a newly created agile project delivery team realizes that there are gaps in the knowledge of some team members. The lack of specific skills will add risk to the project delivery if the project becomes too dependent on specific resources fo...
In this scenario, the project lead is focused on addressing skill gaps within the team to avoid dependency on specific individuals. The goal is to create a high-performing team capable of delivering the project successfully while reducing risks tied to knowledge silos. Let’s break down each option:
Option A: Ask each team member to document their solutions extensively in a knowledge repository for knowledge exchange between the team.
- Reasoning: While documentation can be helpful for knowledge sharing, it doesn't address the immediate need for developing the team’s skills. Documentation might help long-term knowledge transfer, but it won't solve the current skill gaps or improve the team’s capability to deliver in the short term. Additionally, if team members don’t have the necessary skills in the first place, documentation alone won’t resolve the issue of underperformance.
- When to use: This option could be valuable as a complementary action after skill development, but it is not the primary solution to addressing knowledge gaps or reducing project risk.
Option B: Pair team members and ensure review of technical deliverables by partners in each sprint before integration of the solution.
- Reasoning: Pairing team members to review deliverables can be a useful practice for fostering collaboration and sharing knowledge, but it doesn’t focus on addressing skill gaps directly. The review process could help ensure quality and highlight areas where improvement is needed, but it still depends on the existing knowledge base of the team. If the gaps are significant, simply reviewing deliverables might not be sufficient to overcome them. This approach would be more effective once the team has had opportunities to develop the necessary skills.
- When to use: This is a good practice for improving collaboration and quality after addressing the initial knowledge gaps, but it doesn’t solve the problem of skill development.
...
Author: Isabella · Last updated Jul 9, 2026
Stakeholders are unhappy because they have not been consulted on a user interface (UI) for a project that will have a significant impact on end u...
In this situation, the key issue is that stakeholders feel disconnected from the user interface (UI) design process, and there is a risk that their needs have not been fully considered. It's essential to address the stakeholders' concerns, ensure proper engagement, and maintain alignment throughout the project. Let's examine each option in detail:
Option A: The agile team should engage stakeholders regarding the proposed designs and ensure that sufficient engagement occurs throughout the project in an adaptive way.
- Reasoning: This is the best approach because it aligns with the agile principles of collaboration, flexibility, and continuous feedback. Stakeholders should be involved in the design and development process, especially when the UI will have a significant impact on end users. Engaging stakeholders throughout the project in an adaptive manner allows for iterative refinement of the UI based on feedback. Agile emphasizes delivering value and adjusting based on stakeholder needs and input.
- When to use: This option should be used because it ensures ongoing collaboration with stakeholders, integrates feedback early and often, and maintains adaptability, which is critical to agile projects. It allows the team to adjust the design to meet the stakeholders’ expectations and mitigate the risk of disconnect later in the process.
Option B: The agile practitioner should inform the stakeholders that the UI has already been approved by the project team and the project sponsor, so the team is committed to staying the course.
- Reasoning: While it may be true that the UI has been approved by the project team and sponsor, this response ignores the need for ongoing stakeholder engagement, which is crucial in agile projects. In agile, the solution evolves based on stakeholder feedback, and the fact that the UI was approved by the internal team doesn’t mean it necessarily aligns with stakeholders’ expectations. This approach risks alienating the stakeholders and creating frustration, which could lead to more signifi...
Author: Noah · Last updated Jul 9, 2026
A client has provided their requirements and deadline to the project team. The requirements are confusing, and the team is fr...
In this scenario, the project team is facing frustration due to confusing requirements, which can significantly impact the project's progress and quality. The servant leader's role is to support the team by removing obstacles, clarifying uncertainties, and fostering effective communication with the client. Let’s analyze each option:
Option A: Try to motivate the team by recounting examples of their past successes.
- Reasoning: While motivating the team is important for maintaining morale, this option doesn't address the root cause of the frustration, which is the confusing requirements. Recounting past successes is a form of encouragement but doesn’t help in clarifying the current situation or provide practical steps to resolve the issue. In agile, the focus is on removing impediments and ensuring the team has what they need to succeed, which requires addressing the confusion with the client.
- When to use: This option could be used to boost team morale but is not an effective strategy to resolve the current issue, as it doesn't actively address the problem.
Option B: Ask the team to find user stories from similar projects for this customer.
- Reasoning: Looking at past user stories from similar projects might provide some context, but it doesn’t directly resolve the issue of unclear requirements. The team may still face gaps or misunderstandings between the old stories and the current project's needs. Additionally, relying solely on past projects could lead to assumptions and risks of not properly aligning with the client’s actual needs. This option doesn’t foster collaboration with the client to clarify the requirements.
- When to use: This could be helpful if the requirements are partially clear and the team is looking for reference material. However, it doesn’t address the immediate n...
Author: Scarlett · Last updated Jul 9, 2026
During an agile team retrospective, some junior team members discussed an approach that could improve the overall team performance. Ho...
In this scenario, the agile practitioner is faced with a suggestion from junior team members during a retrospective that could potentially improve team performance. The agile practitioner’s role is to foster a culture of collaboration, transparency, and continuous improvement. Let’s break down each option:
Option A: Record the suggestion to be considered for future projects.
- Reasoning: While recording the suggestion is a valid first step, it doesn’t address the immediate opportunity to evaluate and potentially implement the idea in the current context. Agile emphasizes continuous improvement in the present, not just in the future. Simply recording the suggestion and deferring it may cause the team to miss the chance to experiment and iterate on it right now, potentially benefiting from it immediately. This approach also doesn't actively engage the team in a process of evaluation and ownership.
- When to use: This option could be used if the suggestion is out of scope for the current project but worth considering in the future. However, it's a less proactive approach in the context of an ongoing agile process.
Option B: Invite the team to evaluate the suggestion and measure the effectiveness of the implementation.
- Reasoning: This is the most effective response, as it actively engages the team in evaluating and experimenting with the suggestion. Agile teams are empowered to make decisions and continuously improve their ways of working. By involving the team in evaluating the suggestion and measuring its effectiveness, the team can determine whether it truly improves performance. This option fosters a culture of shared ownership, collaboration, and learning, which is a core principle of agile. It allows for an iterative approach, where the team can experiment, gather feedback, and adapt.
- When to use: This is the ideal op...
Author: RadiantPhoenixX · Last updated Jul 9, 2026
A new Scrum team is struggling with the various ceremonies of Scrum. Among other things, the product owner and stakeholders find the technical architecture and design presentati...
In this scenario, the primary concern is that the product owner and stakeholders find the technical architecture and design presentations during the sprint reviews to be less informative. Given that the sprint review is primarily a meeting for inspecting the increment and adapting the product based on feedback, it's important to align the focus of the ceremony with the needs and interests of the stakeholders and product owner, rather than overly focusing on technical details that may not add value for them.
Let's evaluate each option:
A) Refocus the sprint review meetings to demonstrate working software and seek feedback on the product.
- Rationale: This option directly addresses the primary purpose of the sprint review: showcasing working software and getting feedback on the product. Stakeholders typically want to see tangible progress in terms of user-facing features and how the product is evolving. Technical architecture and design presentations, while important, might not be relevant to this group unless they directly impact the user experience or product functionality.
- Key Factors: Stakeholder value, product feedback, clear communication of progress.
- Why Rejected: While this option is optimal for focusing on the product itself, it does not address the technical team's need for better communication or refining technical presentations for relevant audiences. However, it is a critical option because it aligns with Scrum principles.
B) Reach out to other, more experienced teams to seek input as to how to present the technical details in a more informative manner.
- Rationale: Seeking input from more experienced teams can help the Scrum team refine their communication and presentation style, ensuring that technical information is delivered in a way that is easier for stakeholders to digest. This could lead to better understanding and more productive sprint reviews.
- Key Factors: Continuous improvement, sharing knowledge, collaboration.
- Why Rejected: While valuable for improvement, this option doesn’t directly address the issue of the sprint review not being valuable to stakeholders. It is a good supplementary strategy, but it is not the most ...
Author: Lucas · Last updated Jul 9, 2026
Two team members are working together to deliver an asset management tool. The code delivered by team member A during this sprint is not aligning with the specifications written by team member B. Both team members do not seem to agr...
In this scenario, two team members are having disagreements about the alignment between the code delivered and the specifications, as well as the look and feel of the functionality. This issue points to a misalignment in expectations and communication, which could result in delays or inefficiencies if not resolved effectively. Let’s analyze each option:
A) Understand the root cause of this issue and recommend discussing their differences to find common ground.
- Rationale: This option is focused on identifying the root cause of the disagreement and facilitating a discussion between the two team members to resolve the conflict. A Scrum Master should encourage open communication and collaboration, helping the team members understand each other’s perspectives. The goal is to find common ground and ensure that both parties understand the requirements and design intentions.
- Key Factors: Root cause analysis, conflict resolution, fostering collaboration, open communication.
- Why Selected: This approach is ideal because it encourages proactive problem-solving and collaboration, which are core values of Scrum. The Scrum Master’s role is to coach the team and create an environment where conflicts are resolved constructively. It also avoids forcing a solution or escalating the issue unnecessarily.
B) Hold a team meeting to discuss these issues and help direct the whole team on how to proceed further.
- Rationale: While bringing the whole team together could help, it may also lead to unnecessary distraction if the issue is primarily between two team members. A group discussion may be overkill and could shift focus away from more pressing team-wide issues. It might also put undue pressure on the two individuals, making it harder to reach a resolution. It could also be seen as micromanagement if the Scrum Master doesn't first try to resolve the issue with the individuals involved.
- Key Factors: Group dynamics, efficiency, appropriate escalation.
- Why Rejected: A team-wide meeting may not be necessary unless the issue impacts the entire team. It’s better to try resolving the issue between the two team members befor...
Author: Lucas · Last updated Jul 9, 2026
An agile team is continuously interrupted by stakeholders wanting to ask product backlog questions. Distractions can have a negative impact on value delivery an...
In this scenario, the team is being frequently interrupted by stakeholders with questions about the product backlog, which is impacting their ability to focus on delivering value and quality. The key concern is ensuring that the team can remain focused on their work without being distracted by external inquiries, while still maintaining alignment with stakeholder needs.
A) Product owner
- Rationale: The Product Owner (PO) is responsible for the product backlog, including ensuring it is well-defined, prioritized, and understood by all stakeholders. They are the key interface between the team and the stakeholders, and part of their role is to manage stakeholder expectations and communications about the backlog. The PO should help prevent unnecessary interruptions by managing when and how stakeholders can engage with the team regarding the product backlog.
- Key Factors: Stakeholder management, backlog clarity, minimizing distractions for the team.
- Why Selected: The Product Owner is directly responsible for managing the flow of information between the team and stakeholders. By handling the stakeholder inquiries and ensuring that they have a clear understanding of the backlog, the PO can shield the development team from unnecessary distractions. This allows the team to maintain focus on delivering the agreed-upon sprint goals.
B) Project manager
- Rationale: In traditional project management, a project manager may handle stakeholder communication and oversee the team’s progress. However, in agile, the project manager role is often less prominent or nonexistent, as Scrum, Kanban, and other Agile frameworks emphasize team self-management. The Scrum Master or Product Owner typically takes on roles traditionally associated with the project manager.
- Key Factors: Agile roles, responsibility for distraction prevention, team self-management.
- Why Rejected: The role of a project manager in a Scrum team is not as defined as in traditional project management. Scrum doesn't typically include a Project Manager role, as it places the responsibility for minimizing distractions on the Product Owner and Scrum Master. Therefore, the...
Author: Aarav2020 · Last updated Jul 9, 2026
An organization is shifting to an agile delivery methodology. An agile project manager has been assigned to the transformation project.
What should...
In this scenario, the organization is transitioning to an agile delivery methodology, and an agile project manager has been assigned to oversee the transformation. The key challenge is ensuring a high level of adoption of agile practices throughout the organization. Let’s evaluate each option:
A) Focus on not just the "what," but also the "how" of delivering projects.
- Rationale: Focusing on both the "what" and "how" is critical to ensuring that teams understand not only the project deliverables (the "what") but also the processes, behaviors, and practices (the "how") that lead to successful agile outcomes. However, in the context of driving agile adoption, this is more of a secondary consideration. The core of adoption lies in understanding and internalizing the agile mindset, and this option doesn't specifically address the broader organizational change required.
- Key Factors: Process improvement, holistic project delivery.
- Why Rejected: While important, this option is more of an ongoing operational focus rather than the foundational action required to initiate and sustain agile adoption. Adoption is about mindset and cultural change, and this option does not directly target those areas.
B) Ensure that there is buy-in from senior management to adopt agile.
- Rationale: Ensuring senior management's buy-in is crucial for the success of any organizational transformation, especially one as significant as a shift to agile. Senior leaders can drive change, allocate resources, and support teams through the transition. Without their buy-in, the transition can face significant roadblocks, such as lack of support, insufficient resources, or resistance to change at various levels of the organization.
- Key Factors: Leadership support, organizational alignment, resource allocation.
- Why Selected: Buy-in from senior management is foundational to agile adoption. Without the proper support from leadership, an agile transformation is likely to face resistance or be deprioritized. Senior management is critical in setting the vision, securing funding, and removing organizational barriers. This is a strategic move to ensure a smooth transition and high adoption across the organization.
C) Identify stron...
Author: Harper · Last updated Jul 9, 2026
An agile team is struggling to achieve their goal during the first release due to an unstable environment beyond the authority of the product owner. Close to the end of the current sprint, the rel...
In this scenario, the team is struggling to achieve its goal due to an unstable environment that is beyond the control of the product owner, and the release manager who was responsible for managing the release process has resigned. A new release manager is taking over close to the end of the current sprint. The Scrum Master needs to ensure that the team can still meet its goals, while also managing the transition effectively.
Let's evaluate each option:
A) Report the issue to the product owner and request help.
- Rationale: The Product Owner is responsible for maximizing the value of the product and managing the product backlog. However, the issue in this case lies with the release process, which is beyond the Product Owner's authority. Reporting the issue to the PO might create unnecessary distractions for them, as this is not their domain of responsibility. Instead, the Scrum Master should directly engage with the release manager or other relevant parties to address the instability.
- Key Factors: Product Owner responsibility, scope of authority, effective communication.
- Why Rejected: This option is not optimal, as it doesn't align with the Scrum framework, where the Scrum Master is responsible for facilitating the process, including addressing obstacles and communicating with the right stakeholders (in this case, the new release manager). It also places unnecessary focus on the PO when they cannot directly resolve the issue.
B) Let the new release manager participate in the daily standup.
- Rationale: Involving the new release manager in the daily standup could provide the team with visibility into the release process and allow the new manager to understand the current issues. However, the daily standup is typically meant for team members to discuss progress, impediments, and next steps, not for managing external roles. Including the release manager might distract from the purpose of the standup.
- Key Factors: Daily standup purpose, focus on team communication, avoiding unnecessary distractions.
- Why Rejected: While it could be beneficial for the release manager to understand the team’s challenges, the daily standup may not be the right forum for such a discussion. Instead, it would be more effective for the Scrum Master to communicate the specific issues directly with the new release manager outside of the standup.
C) Invite the new release manager to the sprint demo and ask f...
Author: Sam · Last updated Jul 9, 2026
A customer has given a project team several requests for new features on a product. The customer is upset that the requests have been placed in the backlog and are not...
To address the customer’s concerns effectively, the team needs to take a balanced and strategic approach. Let’s evaluate the available options.
A) Review the feature requests and reject the most complex ones.
- Why it’s rejected: This approach is reactive and doesn’t foster collaboration with the customer. Rejecting complex features could alienate the customer and create a negative perception of the team's willingness to address their needs. Moreover, what is considered complex might vary depending on the team's capabilities or the context of the product roadmap. It also doesn’t help with organizing and prioritizing the work in a constructive way.
- Scenario when it might be used: This could work in a situation where there are clear resource constraints, and the team is overwhelmed with feature requests. However, even in that case, rejecting features without proper discussion could hurt customer relationships.
B) Organize the feature requests from simple to complex.
- Why it’s rejected: While it’s a good idea to categorize requests, simply organizing them from simple to complex doesn’t address prioritization. The team could end up working on low-value features that are easy but not impactful. Prioritization should be based on customer value, feasibility, and alignment with business goals, not just complexity.
- Scenario when it might be used: This might be useful when the team needs an initial understanding of the scope or effort required, but it’s not a complete strategy on its own.
C) Prioritize the requests for the next sprint.
- Why it’s reject...
Author: Lina Zhang · Last updated Jul 9, 2026
An agile practitioner is in the process of refining requirements. The requirements keep changing based upon with whom the agile practitioner spea...
A) Ask the scrum master to help reduce the rate of change.
- Why it’s rejected: The Scrum Master’s primary role is to help the team adhere to Scrum principles, facilitate ceremonies, and remove impediments. While they can help manage the overall process, the rate of change in requirements is not something they directly control. The issue seems to be more related to the ongoing communication and understanding of requirements rather than something the Scrum Master can influence by themselves. Additionally, attempting to reduce the rate of change might limit adaptability and responsiveness to the customer, which is a key advantage of Agile.
- Scenario when it might be used: This might be useful in scenarios where scope creep is an issue, but it doesn't directly address the cause of the changing requirements.
B) Work with the agile coach to document the requirements in a collaborative way.
- Why it’s rejected: While working with an agile coach to improve documentation practices could be beneficial, the core issue is not documentation itself, but the continuous change in requirements. The practitioner needs to focus more on stabilizing the requirements and improving the communication process with stakeholders rather than just documenting what keeps changing. Documentation alone won’t solve the problem if the requirements continue to shift.
- Scenario when it might be used: This option is useful if the issue is about improving the quality of requirement documentation or aligning the team on how to document user stories. However, it doesn't address the primary challenge of changing requirements due to differing opinions from stakeholders.
C) Work with the stakeholder directly rather than go through different layers of people.
- Why it’s rejected: Working directly with stakeholde...
Author: Krishna · Last updated Jul 9, 2026
An agile team is having a meeting with a customer to formulate the product requirements for the next iteration. The outcome of the meeting is a set of ...
Let’s evaluate each option in the context of the team’s next steps after meeting with the customer to define product requirements for the next iteration:
A) Run automated tests on the legacy functionality.
- Why it’s rejected: While testing legacy functionality is important for ensuring that new changes don’t break existing features, the current focus should be on implementing the new features as per the agreed-upon product requirements. Running tests on legacy functionality is not the most immediate action after defining the requirements for the new iteration. It might also be unnecessary if the team already has automated tests for legacy functionality in place and needs to focus on the new stories.
- Scenario when it might be used: This would be appropriate if there were concerns about the impact of new features on existing functionality, or if legacy functionality was unstable. However, this is not the immediate next step when moving forward with new user stories.
B) Ask the customer to write tests that will be used to know when a story has been correctly developed.
- Why it’s rejected: While customer input is crucial, having the customer write tests directly may not be the most effective or efficient use of their time. In Agile, the development team typically takes responsibility for writing tests based on the requirements, user stories, and acceptance criteria. The customer can certainly provide feedback on the tests and acceptance criteria, but writing the tests themselves may lead to inefficiency and could create confusion regarding responsibilities.
- Scenario when it might be used: This might work in a scenario where the customer has a very detailed and technical understanding of the product and is comfortable writing tests, but it's not the common practice in Agile.
C) Start ...
Author: David · Last updated Jul 9, 2026
A Kanban team is struggling to prioritize and determine which tasks to handle first according to value. Wha...
A) Involve their product owner.
- Why it’s rejected: While involving the product owner can certainly help the team understand customer needs and the value of certain tasks, it doesn’t directly solve the issue of prioritization within the Kanban framework. The team may already have input from the product owner, but without a clear system to evaluate and prioritize tasks based on value, the problem persists. This option focuses more on communication but doesn’t address the underlying mechanism for determining value-driven prioritization.
- Scenario when it might be used: This could be helpful if the product owner is not currently involved or if there's a lack of clear understanding between the team and the product owner. However, it still doesn’t provide a structured method to prioritize tasks effectively.
B) Review their work in progress (WIP) limits.
- Why it’s rejected: Reviewing WIP limits is important for improving flow and ensuring the team is not overwhelmed, but it does not directly address the challenge of prioritizing tasks according to value. WIP limits help manage the flow of tasks, but they are more about limiting bottlenecks rather than clarifying which tasks should be worked on first.
- Scenario when it might be used: If the team is facing bottlenecks or overloading, reviewing WIP limits could help improve flow and reduce inefficiencies. However, it won’t help in setting clear priorities based on value.
C) Use class of service.
- Why it’s selected: The "class of service" approach in Kanban helps teams categori...
Author: Daniel · Last updated Jul 9, 2026
The product owner is very concerned about work not being completed and tested before a hard release date. Wh...
Let’s evaluate each option in the context of the team’s need to mitigate the risk of not completing and testing work before a hard release date:
A) High-risk features can be prioritized to fit into releases with less work in progress.
- Why it’s selected: Prioritizing high-risk features ensures that the most uncertain or complex aspects of the product are addressed first. This is critical because high-risk features typically have the potential for delays or additional work. By tackling these features early, the team gives itself ample time to complete testing, debugging, and other necessary work. If high-risk features are left until later, there’s a risk of running out of time before the release date. This strategy aligns with the principle of "failing fast"—if problems arise, there’s still time to address them.
- Scenario when it might be used: This is ideal when the team is dealing with features that have a high level of uncertainty or complexity, and it’s important to identify potential issues early. Prioritizing high-risk work early in the iteration or sprint ensures the team has enough time to complete necessary testing and adjustments.
B) Low-risk, low-value features can be prioritized and completed first.
- Why it’s rejected: While completing low-risk, low-value features first may seem like a way to reduce the number of tasks remaining at the end of the cycle, it doesn’t effectively mitigate the risk of missing deadlines for important, high-risk features. These low-risk features may not be the ones that are critical to the release’s success, and addressing them early could cause delays in delivering the more valuable or complex features. The focus should be on delivering high-value and high-risk work first to reduce the likelihood of issues closer to the release date.
- Scenario when it might be used: This could work in cases where low-risk features are easy wins or when the team needs to gain momentum by completing smaller tasks. H...
Author: Deepak · Last updated Jul 9, 2026
A project team tasked with delivering a solution with extremely aggressive timelines is facing an issue with meeting their sprint velocity targets. To address this issu...
In this situation, where a project team faces aggressive timelines and struggles with meeting sprint velocity targets, the goal is to take the most effective and feasible action to get back on track. Let’s analyze each option.
A) Perform value stream analysis to eliminate the processes with wastage
- Pros: Value stream analysis focuses on identifying inefficiencies in processes and removing non-value-added activities. By streamlining workflows, the team can improve their overall productivity, which could help in the long term.
- Cons: However, this option requires significant time to identify inefficiencies, implement changes, and evaluate results. The team is already under pressure with aggressive timelines, and performing value stream analysis may further delay progress.
- When to use: This could be valuable for long-term improvement but is not immediately helpful for the urgent issue at hand.
B) Reevaluate the minimum viable product (MVP) deliverables to remove high-risk stories and meet timelines
- Pros: This is a sensible strategy in cases where the team needs to prioritize delivering the MVP on time. By reevaluating the MVP and removing high-risk or non-essential stories, the team can focus on completing critical tasks. This helps in reducing scope creep and ensures that essential features are prioritized.
- Cons: Removing high-risk stories could lead to cutting out important features that might affect the product's quality or value. However, given the need for speed, the team may have to make this trade-off to meet the deadlines.
- When to use: This is useful when timelines are non-negotiable and the team needs to focus on delivering the most important functionality first.
C) Adjust the story points included in each sprint to represent the actual velocity
- Pros: Adjusting story points could help the team manage expectations a...
Author: Madison · Last updated Jul 9, 2026
An organization wants to increase value delivery in its agile projects. What should the agile teams ...
To increase value delivery in agile projects, the key focus should be on ensuring that the team delivers the highest value in the shortest amount of time, while maintaining flexibility and quality. Let's evaluate each option based on how it contributes to this goal.
A) Perform analysis and development work, but no testing because that should be managed by another specialized team
- Pros: This approach might seem efficient at first by separating concerns. The development team focuses on analysis and development, while the testing team handles quality assurance.
- Cons: This goes against one of the core principles of Agile, which is cross-functional teamwork and continuous integration of all roles. Separating testing from development can lead to delays, miscommunication, and missed issues until later in the process. This also undermines the concept of delivering a potentially shippable product increment at the end of each sprint.
- When to use: This option is not recommended in Agile environments because it reduces team collaboration and impedes the rapid feedback loop that Agile aims for.
B) Master available technology and tools to provide informative dashboards to the stakeholders
- Pros: Dashboards can provide valuable real-time data on project progress, helping stakeholders stay informed. Proper use of technology tools can indeed streamline project tracking and decision-making.
- Cons: While valuable, this does not directly improve the core process of value delivery. Focusing too much on dashboards can become a distraction from delivering actual product value. Dashboards provide visibility but don't necessarily contribute to the actual work of delivering features or improving customer satisfaction.
- When to use: This could be beneficial as a complementary tool to enhance communication and transparency, but it is not the main factor that drives value delivery in Agile.
C) Work with product owners and turn product backlog items into potentially shipp...
Author: Ravi Patel · Last updated Jul 9, 2026
Your program has 121 stakeholders that you'll need to communicate with. Your communications management plan defines how the communication should happen, what should be communicated, and the expected modality of the communications. You'll al...
To determine which input is required for the information distribution process, let's break down each option in the context of a communications management plan and why certain options may or may not be suitable:
A) Change Requests:
- Reasoning: Change requests are typically generated when there is a modification in the project scope, schedule, or other elements that need to be communicated to stakeholders. However, change requests are generally outputs of a change control process, rather than direct inputs to the information distribution process.
- Use Case: Change requests could be communicated to stakeholders but they aren't specifically an input for the process of distributing regular program communications. They are more of a response to specific triggers or needs.
B) Earned Value Management (EVM) Results:
- Reasoning: Earned value management results (such as cost performance index, schedule performance index, etc.) are used to monitor the health of the project by analyzing the actual versus planned performance. These results are typically used for performance analysis and are essential for decision-making but do not directly guide the information distribution process.
- Use Case: EVM results would be shared with stakeholders during periodic performance reviews or management meetings, but they don't directly drive the communication distribution plan itself.
C) Stakeholder Analysis Plan:
- Reasoning: The stakeholder analysis plan is critical to the communication process because it identifies stakeholders, their interests, expectations, communication needs, and preferred methods of com...
Author: Zara · Last updated Jul 22, 2026
What is the formula to determine earned value (EV) for a program?
To determine Earned Value (EV) for a program, you need to calculate the value of work actually performed based on the project’s planned budget. The formula for Earned Value (EV) is:
[
EV = ext{Percent Complete} imes ext{Budget at Completion (BAC)}
]
Where:
- Percent Complete refers to the amount of work that has been completed as of the current reporting period.
- Budget at Completion (BAC) is the total budget allocated for the entire project.
Now, let's analyze each option provided:
Option A: Percent complete times percent remaining in the program
- Reasoning: This option combines two percentages (percent complete and percent remaining), which doesn't directly relate to how earned value is calculated. The "percent remaining" doesn't contribute to the EV directly because earned value is based on the work already completed, not the work that is still pending.
- Rejection: This is not a valid formula for EV because it doesn't account for the actual value of completed work against the original budget.
Option B: Percent complete times the program cost estimate
- Reasoning: The cost estimate can vary, and it may not reflect the original budget at completion (BAC). EV uses the budgeted cost at completion (BAC), which is fixed for the project, rather than an estimate that could change over time.
- Rejection: T...
Author: Leo · Last updated Jul 22, 2026
Olive is the program manager for her organization. She has created a request for proposal for a large portion of her program. In this work to be procured she has set several requirements for the vendors to participate. The chief among these requirements is a vendor must have at least four licens...
Let's analyze the options provided in the context of the situation where Olive has set a requirement for vendors to have at least four licensed electricians on their team. This requirement is aimed at ensuring that potential vendors meet a specific qualification necessary to perform the work.
A) Screening System:
- Reasoning: A screening system refers to a process used to filter out vendors or potential contractors who don't meet certain minimum criteria before they are even considered for further evaluation. It's a mechanism to eliminate vendors who do not meet essential requirements.
- Use Case: If the requirement of having four licensed electricians was part of an initial filter to decide which vendors will even be considered for bidding, this would indeed fall under a screening system. However, in this case, the requirement is more about evaluating specific vendor capabilities rather than just a pass/fail condition.
- Rejected Reasoning: This requirement is not simply a filter for eligibility; it’s part of a more detailed evaluation process, not just an elimination mechanism.
B) Scoring Model:
- Reasoning: A scoring model is used in vendor selection to assign numerical values to different criteria (such as cost, quality, technical expertise, etc.). Vendors are scored based on their responses to different factors, and the one with the highest total score typically wins.
- Use Case: The requirement of four licensed electricians would typically be a qualifying factor in the evaluation process but doesn’t by itself score or rate vendors against other factors.
- Rejected Reasoning: The licensed electricians' requirement is not something that would be scored or weighted numerically in a model. It's a basic requirement for eligibility, not part of a scoring mechanism.
C) Vendor Analysis Requirements:
- R...
Author: Zara · Last updated Jul 22, 2026
You are the program manager for your organization. Management has asked you to create a document that will capture the stakeholders concerns, perceived threats, and specific objectives about the progr...
Let's evaluate the options one by one based on the scenario where management is asking the program manager to capture stakeholders' concerns, perceived threats, and specific objectives related to the program and its projects.
A) Requirements Document:
- Reasoning: A requirements document outlines the specific needs, features, and expectations for the project. It defines what needs to be delivered, detailing the functional and non-functional requirements of the project or program. This document focuses on what the project needs to achieve, not on capturing stakeholder concerns or threats.
- Use Case: This document is typically created during the planning phase of a project to guide project development and implementation, but it does not specifically address stakeholder concerns or perceived threats.
- Rejected Reasoning: The focus here is on capturing stakeholder feedback and concerns, which goes beyond just listing requirements for project deliverables.
B) Project Charter:
- Reasoning: The project charter is a document that officially authorizes the project, outlining the high-level objectives, scope, stakeholders, and key roles. It provides the initial framework and approval for a project, but it does not go into the details of stakeholder concerns, threats, or specific objectives beyond a high-level outline.
- Use Case: The project charter typically provides an overview of the project’s goals and key stakeholders but does not go deep into capturing the specific concerns or threats related to stakeholders.
- Rejected Reasoning: While it includes stakeholder information, the project charter is not intended to capture detailed concerns, threats, or objectives related to the program. It's a foundational document, not one that dives into specific issues.
C) Business Case:
- Reasoning: The business case is a document that justifies ...
Author: Daniel · Last updated Jul 22, 2026
You are the program manager of the NHQ Program. You are working with your program team to ensure that the work in the program is done accurately and according to scope. You are also reviewing the team inspection process that will need to be done to ensure that the work is being done according to the scope. If the work is found to be defective it will need...
Let's analyze the given scenario and options based on the description of the work being reviewed for scope compliance, defects being corrected before inspection by customers, and ensuring that the work is being done according to scope.
A) Quality Control:
- Reasoning: Quality control (QC) is the process of monitoring and inspecting the deliverables during or after work is completed to ensure they meet the required quality standards. QC focuses on identifying defects in the work and correcting them before the customer inspects the work. The scenario mentioned, where defects are identified and need to be corrected before the program customers can inspect, directly describes quality control.
- Use Case: In this case, as defects need to be identified and corrected before inspection, QC fits well with the described actions of inspecting work and ensuring it meets the required standards.
- Selected Reasoning: Since you’re ensuring that the work is done accurately and checking it for defects before customer inspection, this aligns directly with quality control.
B) Scope Verification:
- Reasoning: Scope verification is the process of formalizing acceptance of the completed project deliverables by the customer or sponsor. This is more about confirming that the project or program’s deliverables meet the agreed-upon scope and that stakeholders approve them.
- Use Case: Scope verification would be used after the work is completed and when you want to confirm that the deliverables meet the defined scope. It is not about inspecting work for defects before customer inspection.
- Rejected Reasoning: Since the scenario focuses on inspecting and correcting defects before customer inspection, this is not about formal acceptance or verification, but about identifying issues before the final approval.
C) Quality Assurance:
- Reasoning: Q...
Author: Victoria · Last updated Jul 22, 2026
Your company and a competing company have created a teaming agreement for an opportunity. Through this team agreement you and your competitor can complete a major program for a client. This is, technically, a risk resp...
In this scenario, the type of risk response being used is A) Teaming. Here’s why:
Reasoning:
- Teaming is a risk response strategy where two or more organizations come together to leverage each other's strengths in order to mitigate risks and enhance their ability to win or execute a project. In this case, your company and a competitor are forming a partnership to complete a major program for a client, which allows both parties to share resources, expertise, and responsibilities. This joint effort helps both organizations manage the uncertainties and risks of the project by pooling their capabilities.
- Exploiting would involve identifying and taking advantage of a positive risk opportunity, such as accelerating a timeline or leveraging a new technology. However, this situation is about mitigating risks through collaboration, not capitalizing on a potential positive outcome. Therefore, exploiting is not applicable here.
- Accepting involves acknowledging a risk but choosing not to take any action to mitigate it—often because the risk is deemed insignificant or the cost of mitiga...
Author: Aarav · Last updated Jul 22, 2026
A project manager in your program has estimated the cost of a program to be $145,000. As the project manager's project comes close to completion, the project manager realizes that he has still $27,876 left in his project budget. He decides to add some additional features to the project's deliverables in an effort to use the remaining budg...
In this scenario, the term being described is A) Gold plating. Here's why:
Reasoning:
- Gold plating refers to the practice of adding extra features or enhancements to a project beyond what was originally agreed upon or required, often to use up remaining budget or resources. In this case, the project manager realizes there’s a leftover budget of $27,876 and decides to add additional features to the project that the customer is likely to enjoy. This is a classic example of gold plating because the features are being added without a formal change request or a contractual obligation, and it's driven by the desire to use up the remaining funds, not necessarily to fulfill the project’s original scope.
Why other options are rejected:
- Errors and omissions refer to mistakes or omissions in the project’s deliverables or documentation. These are typically unintentional and can lead to corrective actions or claims. This situation doesn’t involve an error or omission but rather a decision to add extra features, so errors and omissions is not the correct term.
- Expert judgment by the project manager involves using knowledge, experience, or specialized expertise to make decisions about project risks, scope, or other critical elements. While the project manager might be using their expertise, th...
Author: Suresh · Last updated Jul 22, 2026
Andy is the program manager of the HQN Program. This program is nearing its completion and there is still $25,000 left in the program budget. Andy has asked the program team to identify some extra deliverables that can be included in the program scope to improve the program deliverable but...
In this scenario, the term that applies to Andy's actions is D) Gold plating. Here’s why:
Reasoning:
- Gold plating refers to adding extra features or deliverables to a project or program beyond what was originally planned or required. Andy is instructing his team to identify additional deliverables that can be added to the program's scope in order to use up the remaining budget of $25,000, without a clear demand for these additions from the customer or a formal need within the program. This is a textbook example of gold plating — adding extra elements just to exhaust the remaining funds, often without a defined requirement.
Why other options are rejected:
- Value-added change requests typically refer to changes that are requested to improve the project or program, often based on customer needs or to meet objectives that were not originally considered. However, in this case, the goal is not to improve the program based on customer input or real needs but rather to spend the remaining budget, which makes value-added change requests an unsuitable term for this scenario.
- Zero-based budgeting is a budgeting method where every expense must be justified from scratch, regardless of prior budgets. This doesn't apply here because the issue at hand isn't about justifying each dollar in a budget, but rather trying ...
Author: Maya2022 · Last updated Jul 22, 2026
What analysis type could you use in a program to compare the positive stakeholders and their position, power, and influence over your program to the same...
In this scenario, the correct analysis type to use is B) Stakeholder analysis. Here’s why:
Reasoning:
- Stakeholder analysis involves identifying and analyzing stakeholders in a project or program based on their interests, power, influence, and potential impact on the project’s success. In this case, you’re comparing the positive and negative stakeholders by assessing their position, power, and influence over the program. This type of analysis helps understand the dynamics between stakeholders, their needs, and how they could affect the program’s outcomes. Stakeholder analysis directly addresses the need to assess and compare the influence of different stakeholders, whether they are supportive or unsupportive of the program.
Why other options are rejected:
- Sensitivity analysis is used to determine how different values of an input variable affect the outcome of a model. It is commonly applied in scenarios involving uncertainties, such as predicting future financial outcomes or the impact of risk factors. Sensitivity analysis focuses on the variables and their effects, not on stakeholder influence, so it’s not the appropriate method here.
- Monte Carlo simulation involves using random sampling and statistical modeling to estimate the possible outcomes of a decision or a system under uncertainty. It’s useful in risk management and decision-making when there's a need to model a range of potential...
Author: Ishaan · Last updated Jul 22, 2026
You are the program manager of the BHG Program. One of the projects in your program will be using new materials that are somewhat untested. You are worried that there may be delays and waste because the project team is unaware of how to accurately use these materials. You elect to send the people that will be using the new materials through training on how to complete their project work. You also allow them to purchase some of the materials ...
In this scenario, the action you’ve provided is A) This is an example of a preventive action. Here’s why:
Reasoning:
- Preventive action refers to steps taken to eliminate the causes of potential problems or risks before they occur. In this case, you are proactively addressing the risk of delays and waste due to the untested new materials by providing training to the project team and allowing them to experiment with the materials beforehand. By doing so, you are reducing the likelihood of mistakes during the actual project work, which is the essence of preventive action. You're essentially preventing potential issues from arising by preparing the team in advance.
Why other options are rejected:
- Team development focuses on improving the skills, relationships, and collaboration among the project team members. While the training you’re providing may have a side benefit of developing the team, the primary goal is to ensure that the team is prepared to handle the new materials effectively to prevent future issues, not just to improve team dynamics. Therefore, team development is not the primary objective in this scenario.
- Quality assurance involves evaluating and ensuring that the processes used during the project will lead to the desired quality outcomes. It typically focuses on the systematic review of processes to en...
Author: Abigail · Last updated Jul 22, 2026
You are the program manager for your organization. You and your program team have been creating and transferring the program benefits to operations as feasible in your program execution. The proce...
In the context of program management, the process of delivering the program's benefits to operations refers to the Benefits Management process.
Reasoning for the selected option:
- Benefits Management (B): This process involves the planning, tracking, and realization of the benefits that the program aims to deliver. As a program manager, you are specifically concerned with ensuring that the intended benefits are transferred effectively to operations as part of the program execution. This process continues through the program lifecycle, ensuring that once the program outputs are delivered, the benefits are captured, realized, and integrated into operations. It’s about maintaining a focus on how the program's outputs translate into long-term value for the organization, which aligns with your description of transferring benefits to operations.
Why the other options are rejected:
- A) Quality Control: This process focuses on monitoring and recording results of quality activities to assess performance and recommend necessary changes. It ensures that the deliverables meet quality standards but does not specifically address the realization and transfer of program benefits into operations. Quality control happens as part of execution and monitoring but isn't directly concerned with benefit delivery to operations.
- C) Direct and Manage Program Execution: This process involves leading and performing the work defined in the program's plan. While it includes ensuring the program is...
Author: StarryEagle42 · Last updated Jul 22, 2026
What is the present value of a program that will be worth $3,567,000 if it lasts for six years and t...
To calculate the present value (PV) of a program or investment, you can use the Present Value formula:
[
PV = frac{FV}{(1 + r)^n}
]
Where:
- PV = Present Value
- FV = Future Value (the value of the program after 6 years, which is $3,567,000)
- r = Rate of return (5%, or 0.05)
- n = Number of periods (6 years)
Calculation:
[
PV = frac{3,567,000}{(1 + 0.05)^6}
]
[
PV = frac{3,567,000}{(1.05)^6}
]
[
PV = frac{3,567,000}{1.340095}
]
[
PV approx 2,661,750
]
Reasoning for the selected option:
- D) $2,661,750 is the correct present value based on the formula and calculation above. This is the value of the program today, accounting for the rate of return of 5% over the 6-year period.
Why the other options are rejected:
- A) $1,550,850: This value is significantly lower than the expected present value. It may be the result of applying an incorrect rate or formula, but it doesn't reflect the correct calc...
Author: Abigail · Last updated Jul 22, 2026
You are the program manager for the SRQ Program. You have rejected several change requests for the program scope. W...
When a change request is rejected in a program, it is essential to follow a structured process to ensure transparency, maintain communication, and document the decision. Let’s examine the options and reason through the best choice:
Key Considerations:
- Transparency: Stakeholders need to understand the reasoning behind the rejection.
- Documentation: Properly recording the rejected change request ensures that the rationale is available for future reference, and lessons can be learned.
- Change Register: It's important to maintain an up-to-date record of all changes, whether accepted or rejected, to ensure effective change control.
Option Analysis:
- A) Communicate why the change request was rejected and record the results in the lessons learned documentation for your program:
- Pros: This option is thorough because it suggests both communication and documentation of the reason behind the rejection. Recording the rejection in the "lessons learned" documentation helps in the future by analyzing why the request was rejected and learning from the situation.
- Cons: While useful for future reference, the "lessons learned" documentation is typically part of post-project/program analysis rather than an immediate action. This option focuses more on long-term learning than on immediate change management.
- B) Inform the stakeholders that their change requests have been rejected:
- Pros: This communicates the rejection to stakeholders, which is a necessary action.
- Cons: It lacks the reasoning behind the rejection and does not ensure the documentation of the decision, which are both critical for transparency and accountabili...
Author: Sam · Last updated Jul 22, 2026
Where are negative risks recorded?
In program and project management, negative risks (or threats) are recorded to ensure they are proactively managed and mitigated. Let’s evaluate the options based on where negative risks should be documented:
Key Considerations:
- Risk Register: The primary tool for recording all identified risks (both positive and negative), along with their potential impact, mitigation strategies, and status. It's a central repository for risk management and is typically updated throughout the lifecycle of the program.
- Risk Management Plan: This document outlines the overall strategy and processes for identifying, analyzing, and managing risks. While it includes procedures for handling risks, it is not the place to track individual risks.
- Issues Log: This log is used to document issues that have already occurred, which require resolution. Negative risks are potential threats that haven’t necessarily materialized into issues yet, so they don't belong in the issues log until they become actual problems.
- Negative Risk Register: This is not a standard term in formal risk management practices. While it might be used informally in some organizations, it is not the best practice or formal terminology for where negative risks should be recorded.
Option Analysis:
- A) Negative risk register:
- Pros: This option may sound intuitive because it focuses on negative risks, but it is not a formal or standardized part of the risk management process. Generally, all risks, whether positive or negative, are recorded in a single risk register.
- Cons: There is no such thing as a "negative risk register" in formal risk management terminology. Risk management typically combines both positive (opportunities) and negative (threats) risks in one Risk Register.
- B) Risk management plan:
- Pros: The Risk Management Plan outlines how r...
Author: Amira99 · Last updated Jul 22, 2026
You are the program manager for your organization. Management would like to consider the present value for your program. If your program is predicted to be worth $450,000 in two year...
To calculate the present value (PV) of the program, we need to use the Present Value formula:
[
PV = frac{FV}{(1 + r)^n}
]
Where:
- FV = Future Value (the value of the program after 2 years, which is $450,000)
- r = Interest rate (6%, or 0.06)
- n = Number of periods (2 years)
Calculation:
[
PV = frac{450,000}{(1 + 0.06)^2}
]
[
PV = frac{450,000}{(1.06)^2}
]
[
PV = frac{450,000}{1.1236}
]
[
PV approx 400,498
]
Reasoning for the selected option:
- A) $400,498 is the correct present value based on the formula and calculation above. This is the value of the program today, accounting for the interest rate of 6% over the 2-year period.
Why the other options are rejected:
- B) $521,345: This value is higher than the future value of $450,000, which doesn't make sense given that we are calculating the present...
Author: Isabella · Last updated Jul 22, 2026
Harriet is the program manager of a large program that has a high profile and visibility in her organization. Some of the stakeholders are negative and Harriet needs to work with these stakeholders to address their fears, perceived threats, and conc...
In this scenario, the best communication method would be A) Face-to-face. Here’s why:
Key Factors to Consider:
1. Stakeholder Concerns: The stakeholders in this situation are negative, and Harriet needs to address their fears and perceived threats. Face-to-face communication provides the opportunity for immediate feedback, empathy, and active listening, which are crucial when addressing concerns. The ability to gauge body language, tone, and emotional reactions can also help Harriet navigate sensitive conversations and build trust.
2. High Profile and Visibility: Given the program’s high visibility, it’s important to handle communication with these stakeholders personally and with care. A face-to-face conversation shows a high level of commitment to resolving concerns and reinforces that Harriet is actively engaged and invested in addressing issues.
3. Building Relationships: Direct, personal communication fosters stronger relationships and creates an environment where stakeholders feel heard and valued. It can also provide a platform to clarify misunderstandings and engage in dialogue that may not be possible in other forms of communication.
Why Other Options Are Rejected:
- B) Many-to-many: This approach, typically used in group settings (e.g., team meetings, conferences), is not ideal for a...
Author: Aria · Last updated Jul 22, 2026
Eric is the project manager of the NQQ Project and has hired the ZAS Corporation to complete part of the project work for Eric's organization. Due to a change request the ZAS Corporation is no longer needed on the project even though they have completed nearly all of the projec...
In this scenario, the correct answer is C) It depends on what the termination clause of the contract stipulates. Here’s why:
Key Factors to Consider:
1. Contract Terms and Conditions: The primary guiding factor here is the contract between Eric's organization and the ZAS Corporation. If the contract includes a termination clause, it will outline the specific conditions under which either party can terminate the contract and the associated financial implications. The termination clause often details the payment structure in the event of early termination, including whether ZAS Corporation is entitled to compensation for the work completed before the change request.
2. Scope of Work and Work Completed: ZAS Corporation has completed nearly all of the work. Therefore, Eric's organization might still be liable for paying for work already completed, even if the work was terminated early due to a change request. The key here is whether the change request qualifies as a valid reason for termination, and whether ZAS Corporation is entitled to payment for the work they performed.
3. Legal and Contractual Obligations: The termination clause typically defines the conditions for payment in the event of cancellation or modification of the scope. It may stipulate that the organization must pay for services rendered up to the point of termination, or may allow for a partial payment or refund based on the circumstances. Understanding these specifics is crucial.
Why Other Options Are Rejected:
- A) It depends on what the outcome of a lawsuit will determine:...
Author: Noah · Last updated Jul 22, 2026
Mike is the program manager of the NHQ Program. Mike and a vendor are in disagreement over the deliverable the vendor has created for Mike's program. Mike does not believe the vendor has correctly created the deliverable, while the vendor is adamant that his company has...
The correct answer in this scenario is D) Claim. Here’s why:
Key Factors to Consider:
1. Disagreement Between the Parties: In this case, Mike (the program manager) and the vendor disagree on whether the deliverable has been completed as per the contract. The vendor believes they have fulfilled the contract, while Mike does not. This kind of disagreement, where both parties have documented their stances, typically falls under a claim. A claim involves one party asserting that another party has not met the contractual terms and demanding some form of resolution (usually financial compensation or rectification of the deliverable).
2. Contractual Dispute: A claim arises when there is a dispute over the terms of the contract or its execution. Here, the vendor believes they have completed the work as agreed, while Mike thinks the deliverable is incorrect. This situation usually leads to formal or informal negotiations, arbitration, or legal proceedings to settle the disagreement. Since both parties have documented their positions, it fits the definition of a claim, where one party (Mike) is claiming that the deliverable does not meet the agreed-upon specifications.
3. Resolution: The goal of the claim is to resolve the dispute, either by fixing the deliverable, compensating for non-completion, or some other means of dispute resolution. The fact that both sides have documented their position suggests that they are both preparing for this resolution process, which is characteristic of a claim.
Why Other Options Are Rejected:
- A) Breach of contract: A breach of contract occurs when one party fails to fulfill their obligations as spec...
Author: Akash · Last updated Jul 22, 2026
You are the program manager of the GHY Program in your organization. It has come to your attention that some of the project managers in your program are adding time to each project activity in an effort to pad their durations in case some event happens in their project that will cause delays. What ...
The correct answer in this scenario is A) Parkinson's Law. Here’s why:
Key Factors to Consider:
1. Padding Activities: The project managers are adding extra time to their activity durations as a safety margin, essentially padding the schedule. This approach is based on the belief that unexpected delays might happen, and they want to account for that possibility. However, this behavior is counterproductive and can lead to inefficiencies.
2. Parkinson's Law: Parkinson's Law states, "Work expands to fill the time available for its completion." When project managers pad their activity durations, they are essentially allocating extra time that may lead to inefficiency. With extra time, activities may take longer than they should, simply because more time is available. This results in unnecessary delays and potentially delays other tasks in the program, which can affect the overall timeline.
3. Addressing the Issue: Sharing Parkinson's Law with the project managers emphasizes that by padding activity durations, they are likely wasting time, not ensuring a smoother project execution. Encouraging accurate time estimates and proactive risk management (rather than artificially inflating activity durations) will lead to more realistic schedules and a more efficient program.
Why Other Options Are Rejected:
- B) Law of Diminishing Returns: This law states that after a certain point, adding more resources ...
Author: StarryEagle42 · Last updated Jul 22, 2026
You are the program manager for your organization. Your program team has 43 people that all need to be monitored and controlled. You would like to create a standardized report that you can use to monitor, control, and record the performance of each staff membe...
The correct answer in this scenario is A) Performance reports. Here’s why:
Key Factors to Consider:
1. Purpose of the Report: You want a standardized report that allows you to monitor, control, and record the performance of your program team members. A performance report is specifically designed to track individual and team performance over time. It typically includes metrics such as task completion, productivity, quality of work, and adherence to deadlines, which are essential for monitoring and controlling the performance of each staff member.
2. Tracking Staff Performance: Performance reports are the most appropriate tool for evaluating individual performance and identifying areas of improvement. These reports are regularly updated to provide an accurate, real-time picture of how each team member is contributing to the program’s overall objectives. As a program manager, using performance reports will allow you to compare performance across team members, recognize achievements, and address any performance issues quickly.
3. Consistency and Standardization: A performance report provides standardized metrics that can be applied to all 43 team members, ensuring that you can track performance in a consistent way across the entire team. This is especially important for a large team, where individualized attention to each team member's progress is essential for overall success.
Why Other Options Are Rejected:
- B) Staff variance reports: A variance report typically compares actual performance to planned performance (e.g., budget or schedule variance). While it can be useful for tracking project deviations, it is ...
Author: Olivia · Last updated Jul 22, 2026
You have created a control chart for a repeatable process in your program. You have discovered that the seven most recent measurements are all on the positive si...
The phenomenon you are describing, where the seven most recent measurements on a control chart are all on the positive side of the mean, is known as Rule of Seven.
Here's the breakdown of the options:
- A) Rule of Improvement: This is not a standard term in statistical quality control. While "improvement" might be the goal of a process, the Rule of Seven is a specific rule related to patterns of data on control charts. So, this is not the correct answer.
- B) Mean Improvement: This term also doesn't directly apply in this context. The Rule of Seven doesn't indicate any improvement in the mean of a process. It simply highlights a pattern in the data points. "Mean improvement" could theoretically refer to a shift in the average over time, but it’s not the same as what is being described in the problem.
- C) Rule of Seven: This is the correct answer. According to this rule, if you see seven consecutive points on one side of th...
Author: David · Last updated Jul 22, 2026
What component of the change management system is responsible for evaluating, testing, and documenti...
The correct component of the change management system responsible for evaluating, testing, and documenting changes to the project scope is D) Configuration Management System.
Here's the reasoning for each option:
- A) Project Management Information System (PMIS): A PMIS is a tool or system used for storing and managing project information, including schedules, budgets, and status updates. While it can support change management activities by providing a centralized repository for data, it does not specifically evaluate, test, or document changes. This option is more about data management rather than the direct handling of scope changes.
- B) Integrated Change Control: Integrated Change Control is the process that ensures that all changes to the project scope, schedule, and costs are identified, documented, evaluated, and approved. While this process evaluates changes, it doesn't necessarily test or document them in the same structured manner as configuration management. Integrated Change Control deals with the overall process of controlling changes but doesn't focus on the specific activities of testing and documentation of scope changes, which are key functions of configuration management.
- C) Scope Verification: Scope Verification is the process of formalizing acceptance of the completed project deliverables. It ensures that the work was completed according to the defined scope and meets the stakehold...
Author: Rahul · Last updated Jul 22, 2026
Donna is the project manager for her organization. She is preparing a plan to manage changes to the project should changes be requested. Her change management plan defines the process for documenting, tracking, and determining if the changes should be appr...
The correct system considered the parent of the change control system documented in Donna's plan is D) Integrated Change Control System.
Here's the reasoning for each option:
- A) Quality Management System: The Quality Management System (QMS) focuses on ensuring that the project meets predefined quality standards and continuous improvement processes. While quality management may involve monitoring changes to maintain quality, it does not directly control or manage the overall process for evaluating, approving, or tracking changes to the project. Thus, it isn't the "parent" of the change control system.
- B) Change Control System: The Change Control System is a subset of the overall Integrated Change Control process. It focuses on controlling and managing the changes that occur within the project. However, it is not the overarching system but rather part of the larger Integrated Change Control System. Therefore, it’s not the "parent" system but rather a component within the larger framework.
- C) Project Management Information System (PMIS): The PMIS is a system that supports decision-making and project management activities by providing tools for storing and sharing project information, such as schedules, costs, and progress. While the PMIS can ...
Author: MysticJaguar44 · Last updated Jul 22, 2026
You are a program manager for your organization. You have proposed a program to the management that will last four years and will cost $35 million to create.
Management has asked to see the program charter and the proposed costs and benefits of the program.
Management agrees to your program charter and proposed...
The type of funding management has proposed for this program is B) Step funding.
Here's the reasoning for each option:
- A) Tentative: "Tentative" funding refers to an uncertain or conditional commitment of funds. Typically, this means that funds are set aside but are not guaranteed. The situation described here involves a clear agreement to fund the program incrementally at each milestone, which is more structured and definitive than tentative funding. Therefore, this option doesn't fit the situation.
- B) Step funding: Step funding is a method where funds are released incrementally, typically at the completion of each major milestone or phase of a project. In the case presented, management agrees to fund the program in increments at the completion of each milestone. This matches the definition of Step funding, where the program is funded in discrete steps as progress is made and milestones are achieved. This funding approach is often used for large, multi-phase projects like the one described, ensuring that funding is tied to performance and progress.
- C) Milestone approval: While milestone approval is related to the concept of approving funding at specific points, it typically refers to the formal approval of a milestone or deliverable,...
Author: Max · Last updated Jul 22, 2026
You are program manager for the HYH Program. Your program governance is requiring you to use earned value management to predict how closely your program is tracking to the cost and schedule baselines and to predict overall program performance. Which earned value management for...
The correct formula to use for predicting how much more will need to be invested in the program based on current program performance is D) EAC - AC.
Here's the reasoning for each option:
- A) EV/AC (Earned Value / Actual Cost): This ratio calculates the cost efficiency of the program, but it does not directly predict how much more will need to be invested. It gives the Cost Performance Index (CPI), which helps assess how efficiently the program is using its budget, but it is not used for predicting future costs directly. Therefore, it is not the right choice for predicting the remaining investment needed.
- B) EV/PV (Earned Value / Planned Value): This ratio calculates the Schedule Performance Index (SPI), which measures how well the project is adhering to the schedule. While this is useful for assessing schedule performance, it does not help in predicting future costs or the remaining investment needed. It is more focused on schedule rather than cost.
- C) BAC/CPI (Budget at Completion / Cost Performance Index): This formula predicts the Estimate at Completion (EAC) using the current cost performance. However, it gives an estimate of the total cost at comp...
Author: Mia · Last updated Jul 22, 2026
You are the program manager for your organization. When a project in your program is completed, who wil...
In the context of completing a project within a program, the certificate of completion typically signifies that the project has been finished and meets the required criteria. Let's evaluate the options:
A) The Project Manager
- Reasoning: The project manager is responsible for overseeing the execution of the project, ensuring that it meets the defined scope, timeline, and quality standards. While they play a key role in delivering the project, they are not typically the person to officially sign off the completion because it is the responsibility of the stakeholder or the customer to confirm that the project deliverables have been successfully completed.
- Rejection Reason: The project manager is primarily responsible for execution and management, not necessarily the formal completion acknowledgment from the customer or stakeholder.
B) The Program Customer
- Reasoning: The program customer (or the client who requested the project) is the best choice to sign the certificate of completion. The customer’s approval typically signifies that the project has met their expectations, deliverables, and requirements. Their sign-off is a critical form of validation that the project has achieved what it was meant to.
- Selected Option: In most cases, the program customer is the signatory since their satisfaction is the final criterion of success.
C)...
Author: MoonlitPantherX · Last updated Jul 22, 2026
You are the program manager for your organization. Part of your role as the program manager is to train John, a new program manager, on the program processes within a program. John is confused as to when the program team can be ...
When training John, the new program manager, it’s essential to clarify when the program team should be acquired during the program management lifecycle. Let’s analyze the options in detail:
A) Planning
- Reasoning: The planning phase focuses on developing the program's overall strategy, defining objectives, scope, and creating detailed plans. While planning is critical to ensuring resources and team roles are defined, the actual acquisition of team members typically occurs before or during the planning phase to ensure the program is properly staffed for execution. So, although the planning phase involves identifying roles and responsibilities, it is not when the program team is fully acquired.
- Rejection Reason: The program team acquisition is part of earlier processes (usually during Initiation or before the start of detailed planning) rather than strictly during the planning phase.
B) Execution
- Reasoning: During the execution phase, the program manager leads the team in implementing the program plan, and work is carried out. By this stage, the program team should already be in place. If team members were not acquired before execution, it could significantly delay or complicate program execution. So, while execution focuses on delivering outputs, team acquisition has to happen earlier, particularly during initiation or prior to execution.
- Rejection Reason: The team must be in place before execution can begin. Execution is about managing the team, not acquiring them.
C) Mo...
Author: CrimsonViperX · Last updated Jul 22, 2026
You are the program manager for your organization. You're currently working with the program director, Nancy Holmes, to define a new program and the benefits the program should create....
When defining a benefit for a program, it's important to distinguish between outputs (deliverables) and actual benefits—which focus on value creation and utility for stakeholders. Let's examine each option to find the best fit:
A) A benefit is an outcome of the constituent projects within a program.
- Reasoning: While it’s true that benefits are often realized from the outcomes of the projects within a program, this option is somewhat too narrow. It only mentions the outcome of the projects and does not capture the value or utility generated by these outcomes. A benefit is more than just an outcome; it’s the impact or value derived from that outcome.
- Rejection Reason: This definition doesn’t fully encompass the broader perspective of benefits, especially regarding the value that stakeholders experience.
B) A benefit is a project and program deliverables that the organization may use immediately.
- Reasoning: This option suggests that the benefit is tied to deliverables that can be immediately used, but the focus is too narrow. Deliverables are outputs, not benefits. Benefits are the value these deliverables bring to the organization or stakeholders, which may not always be realized immediately.
- Rejection Reason: A benefit is not merely something that can be used immediately—it can be an ongoing or long-term value, not just something to be used right away.
C) A benefit is a deliverable of a program or project that is worth more than the cost to create the deliverable.
- Reasoning: This option frames the benefit as something related to the cost-to-value ratio. While the valu...
Author: Mia · Last updated Jul 22, 2026
You are the program manager for your organization and you need to define all of the program resources you'll need for your program. All of the foll...
When defining program resources, it's essential to distinguish between tangible, intangible, and conceptual resources. Let's analyze each option:
A) A forklift
- Reasoning: A forklift is a physical asset that could be necessary for certain programs, especially those involving logistics, construction, or physical infrastructure. It can be used to transport heavy materials or equipment. As a tangible resource, it qualifies as a program resource if the program requires it for physical tasks or operations.
- Rejection Reason: The forklift is indeed a program resource in scenarios where physical operations or logistics are involved.
B) Materials for the installation of a new server
- Reasoning: Materials (e.g., cables, hardware, etc.) for a server installation are also physical resources that are directly tied to the program’s deliverables. These resources are necessary for the completion of tasks related to IT infrastructure, and they represent tangible items required for execution.
- Rejection Reason: These materials are directly involved in carrying out the program and thus qualify as program resources.
C) A positive risk response
- Reasoning: A positive risk response refers to an action or strategy designed to exploit ...
Author: Henry · Last updated Jul 22, 2026
Your program has been selected and its program charter is now being created. The program charter defines all of th...
The program charter is a foundational document that authorizes the program and sets its framework. It typically includes essential elements that define the program's overall purpose, scope, and high-level goals. Let’s evaluate each option:
A) Program constraints
- Reasoning: Program constraints (e.g., budget, timeline, resources) are a fundamental part of the program charter. They define the limitations within which the program must operate. These constraints help establish boundaries for program execution and are an essential component of the program charter.
- Rejection Reason: Program constraints are certainly part of the program charter, as they define the limitations within which the program must function.
B) Program scope
- Reasoning: The program scope defines the overall work that will be accomplished as part of the program, including deliverables, objectives, and outcomes. The program charter outlines this at a high level to provide clarity about what is included and what is excluded from the program’s work.
- Rejection Reason: The program scope is a key component of the program charter because it provides clear direction for the program's boundaries.
C) High-level objectives for the program
- Reasoning: The high-level objectives outline the program’s goals and what it aims to achieve. These objectives are an essential part of the program charter, as they e...
Author: BlazingPhoenix22 · Last updated Jul 22, 2026
Terri is the program manager for her organization and she's working with Alice, a project manager in her program. Alice calls Terri and insists that she add a change to program scope. Terri agrees that the ...
In this scenario, Alice is asking Terri to add a change to the program scope, and Terri agrees that the change should be entertained. To move forward with the change, Alice must follow the proper process of submitting and justifying the change within the context of program management. Here's a breakdown of the available options and why some are more appropriate than others:
Option A: Add the change to the program scope herself, as she is a project manager
- Rejected: While Alice is the project manager, she does not have the authority to unilaterally add a change to the program scope. Scope changes must be evaluated and approved through a formal process that involves key stakeholders, including the program manager (Terri). Adding a change directly without this process would violate proper change management procedures.
Option B: Add the change request to the scope and complete integrated change control
- Rejected: This option is close, but not fully correct. Integrated change control is a formal process used in project management to evaluate and approve changes. However, this is typically part of the change control process within the project, not something Alice would "do" on her own. Alice would need to formally submit the change request, which could then go through integrated change control. Adding it directly to the scope without pr...
