Visit here for our full PMI PMP exam dumps and practice test questions.
Question 161
What is the purpose of a fishbone diagram (Ishikawa diagram) in quality management?
A) To create project schedules
B) To identify potential causes of problems or effects through structured cause-and-effect analysis
C) To track project costs
D) To eliminate stakeholder involvement
Answer: B) To identify potential causes of problems or effects through structured cause-and-effect analysis
Explanation:
A fishbone diagram, also called an Ishikawa or cause-and-effect diagram, systematically identifies and organizes potential causes contributing to a specific problem or effect. The diagram resembles a fish skeleton with the problem at the head and major cause categories as bones branching off the spine with detailed causes as smaller bones. This structured visual approach ensures comprehensive cause exploration rather than jumping to premature conclusions about problem sources.
Major cause categories organize brainstorming using standard frameworks like the 6Ms in manufacturing: Methods, Machines, Materials, Measurements, Mother Nature (Environment), and Manpower (People). Service industries might use the 4Ps: Policies, Procedures, People, and Plant (facility). These categories prompt systematic exploration of different problem dimensions ensuring all possible cause areas receive consideration. Category selection should match the problem domain to ensure relevance.
Detailed cause identification drills down within each major category identifying specific potential causes rather than staying at broad category levels. Team brainstorming generates specific causes that might contribute to the problem. For example, under “Methods,” specific causes might include inadequate procedures, inconsistent training, or outdated standards. This detail enables targeted investigation and ultimately effective corrective action addressing actual causes rather than general categories.
Root cause identification requires further investigation after fishbone creation because the diagram identifies potential causes not verified root causes. The fishbone organizes hypotheses about what might cause problems requiring additional analysis like data collection, testing, or process observation to determine which potential causes actually contribute significantly. The diagram guides investigation by ensuring all reasonable causes are considered rather than investigating random factors.
Fishbone applications extend beyond reactive problem-solving to proactive risk identification where the “effect” is a potential negative outcome and “causes” represent risk factors. The structured approach ensures comprehensive risk cause identification. Fishbone diagrams also support opportunity analysis where the effect is a desired positive outcome and causes represent factors enabling that outcome. The versatile framework suits various analytical purposes wherever understanding causation provides value.
Question 162
What is the purpose of a project charter?
A) To provide the detailed project schedule
B) To formally authorize the project and provide the project manager authority to apply resources
C) To document all project risks
D) To create the Work Breakdown Structure
Answer: B) To formally authorize the project and provide the project manager authority to apply resources
Explanation:
The project charter formally authorizes the project and grants the project manager authority to apply organizational resources to project activities. This foundational document establishes the project’s existence within the organization, defines its high-level objectives and scope, identifies the project manager, and provides the authority structure enabling project execution. Without a charter, projects lack formal standing and project managers lack authority to commit organizational resources.
Authorization from appropriate organizational authorities gives the charter its power. Sponsors, executives, or governance bodies issue charters signifying organizational commitment to the project and willingness to invest resources. This authorization represents the go-ahead decision following business case approval and project selection. The charter formalizes that decision providing documentation that the project is officially sanctioned organizational work rather than unauthorized activities.
High-level project information in the charter includes project purpose and justification, measurable objectives and success criteria, high-level requirements, summary budget and funding source, key stakeholders, and general timeline with major milestones. This information provides sufficient context for the project manager to begin detailed planning while remaining brief enough for senior stakeholder review and approval. The charter summarizes rather than comprehensively detailing all project aspects.
Project manager designation and authority grant establishes who will lead the project and what authority they have over budget, staffing, and decisions. Explicit authority definition prevents conflicts about project manager power and provides leverage when negotiating for resources or resolving disputes. Clear authority prevents situations where project managers have responsibility for results without authority to make decisions or commit resources necessary for success.
Charter creation occurs before detailed planning because the charter authorizes the planning work. The project manager uses charter content as the foundation for developing detailed project management plans. Charter approval triggers the transition from project selection to project planning and execution. This logical sequence ensures projects have organizational authorization before significant resources are invested in detailed planning or execution activities.
Question 163
What is the purpose of a scatter diagram in quality management?
A) To create organization charts
B) To show the relationship or correlation between two variables
C) To develop project schedules
D) To eliminate all defects
Answer: B) To show the relationship or correlation between two variables
Explanation:
A scatter diagram plots pairs of data points for two variables on X and Y axes showing whether and how the variables are related or correlated. This visual tool reveals relationships like positive correlation where both variables increase together, negative correlation where one variable increases as the other decreases, or no correlation where variables are independent. Scatter diagrams help identify potential cause-and-effect relationships enabling focused investigation of factors affecting quality or performance.
Positive correlation appears as data points trending upward from lower left to upper right indicating that as the X variable increases, the Y variable also tends to increase. For example, plotting training hours versus defect rates might show negative correlation where more training associates with fewer defects. This relationship suggests training improvements might reduce defects warranting further investigation of the causal mechanism and testing through additional training investment.
Negative correlation appears as data points trending downward from upper left to lower right indicating that as the X variable increases, the Y variable tends to decrease. For example, plotting process temperature versus product strength might show positive correlation suggesting temperature optimization could improve strength. Identifying these relationships guides experimentation to determine optimal settings for input variables affecting quality outcomes.
No correlation appears as randomly scattered data points with no clear pattern indicating variables are independent without meaningful relationship. This negative finding is also valuable because it prevents wasting effort trying to improve quality by adjusting factors that don’t actually affect outcomes. Scatter diagrams quickly reveal which variables warrant investigation and which are unrelated to the quality characteristics of interest.
Correlation does not prove causation is an important caution when interpreting scatter diagrams. Correlation might result from both variables being influenced by a third factor rather than one causing the other. Scatter diagrams identify potential relationships warranting investigation but don’t replace rigorous analysis to verify causal mechanisms. However, identifying potential relationships provides valuable starting points for deeper analysis and experimentation to improve quality and performance.
Question 164
In agile project management, what is a product backlog?
A) A list of completed deliverables
B) A prioritized list of desired product features and requirements
C) The project budget
D) A list of defects
Answer: B) A prioritized list of desired product features and requirements
Explanation:
The product backlog is a prioritized list of all desired product features, functionality, requirements, enhancements, and fixes that could be incorporated into the product. This dynamic artifact serves as the single source for all work that might be done on the product with items ordered by priority determining what the development team works on next. The product backlog is continuously refined throughout the project as new requirements emerge, priorities shift, and understanding deepens about what delivers maximum value.
Product owner responsibility for the backlog includes defining backlog items, ordering items by priority based on value and dependencies, ensuring items are clearly expressed with acceptance criteria, and refining items as implementation approaches. This concentrated accountability prevents conflicting priorities and ensures the backlog reflects a coherent product vision. While the product owner owns the backlog, they collaborate with stakeholders and the development team to inform content and priorities.
Prioritization based on business value, risk reduction, learning objectives, and dependencies determines work sequence. High-value features deliver first enabling earlier benefit realization and faster return on investment. High-risk items might be prioritized early to reduce uncertainty even if not highest value. Dependencies might require implementing foundational capabilities before dependent features. The product owner balances these factors determining optimal sequencing that maximizes delivered value and minimizes risk.
Backlog refinement occurs continuously throughout the product development lifecycle as items near the top are elaborated into implementation-ready user stories with acceptance criteria. This progressive refinement applies effort where it provides most value rather than detailing all items upfront regardless of implementation timing. Items near the backlog bottom remain at higher levels because they’re distant from implementation and understanding will improve before they’re needed. This just-in-time refinement reduces waste from specifying requirements that change before implementation.
Backlog items vary in size and detail with near-term items refined into small implementable user stories while future items remain as larger epics or themes. This natural granularity gradient reflects the reality that near-term work needs implementation detail while distant work requires only directional understanding. As items progress up the priority list toward implementation, they’re progressively decomposed from large themes to small specific stories enabling sprint planning and implementation.
Question 165
What is the purpose of a Monte Carlo simulation in project risk management?
A) To eliminate all project risks
B) To perform quantitative risk analysis by simulating different scenario outcomes based on probability distributions
C) To create project schedules
D) To reduce stakeholder involvement
Answer: B) To perform quantitative risk analysis by simulating different scenario outcomes based on probability distributions
Explanation:
Monte Carlo simulation performs quantitative risk analysis by running the project model thousands of times, each time selecting random values from probability distributions for uncertain variables like activity durations or costs. This repeated sampling produces a distribution of possible project outcomes revealing the probability of meeting various schedule or cost targets. Monte Carlo analysis quantifies overall project risk exposure accounting for interactions among multiple risk sources providing more reliable predictions than deterministic single-point estimates.
Probability distributions for input variables replace deterministic single-point estimates recognizing that activity durations and costs are uncertain. Rather than assuming an activity takes exactly 10 days, the distribution might specify 20 percent probability of 8 days, 60 percent probability of 10 days, and 20 percent probability of 12 days. These distributions capture reality that many outcomes are possible with different likelihoods. Distribution shape reflects the type of uncertainty with different patterns for different risk characteristics.
Iterative calculation runs the project model repeatedly, each iteration randomly selecting values from input distributions producing different project outcomes. After thousands of iterations, the accumulated results form an output distribution showing the range of possible project durations or costs and the probability of each outcome. This output distribution reveals not just a single expected outcome but the full range of possibilities with their relative likelihoods providing comprehensive risk perspective.
Probability analysis enables statements like “There is an 80 percent probability of completing within 12 months” or “There is a 70 percent probability of staying within a $5 million budget.” These probabilistic predictions prove more useful than single-point estimates because they explicitly acknowledge uncertainty and enable risk-informed decision-making. Stakeholders can select confidence levels that match their risk tolerance rather than being given a single estimate that might be overly optimistic or pessimistic.
Sensitivity analysis within Monte Carlo simulations identifies which uncertain inputs most significantly affect outcomes revealing where risk mitigation efforts should focus. If activity duration uncertainty in specific tasks drives most schedule variability, those activities warrant focused risk response. This analytical power enables efficient risk management investment directing resources where they reduce overall project risk most effectively. Monte Carlo transforms qualitative risk awareness into quantitative decision support.
Question 166
What is the purpose of a project management plan?
A) To provide only the project schedule
B) To document how the project will be executed, monitored, controlled, and closed
C) To eliminate all project meetings
D) To reduce project costs
Answer: B) To document how the project will be executed, monitored, controlled, and closed
Explanation:
The project management plan is the comprehensive document or collection of documents defining how the project will be executed, monitored and controlled, and closed. This integrated plan includes all subsidiary management plans for scope, schedule, cost, quality, resources, communications, risk, procurement, and stakeholder engagement plus key baselines for scope, schedule, and cost. The project management plan guides project execution and provides the basis for performance measurement and control.
Integration of subsidiary plans ensures consistency and alignment across all project management knowledge areas. Schedule plans align with resource availability plans. Cost plans reflect scope and quality requirements. Risk plans inform contingency reserves in cost and schedule baselines. Communication plans support stakeholder engagement strategies. This integration prevents inconsistencies where individual plans conflict or fail to consider impacts on other dimensions.
Baselines for scope, schedule, and cost provide approved references for measuring project performance. The scope baseline includes the scope statement, WBS, and WBS dictionary defining what will be delivered. The schedule baseline shows planned start and finish dates for all activities. The cost baseline represents the time-phased budget against which cost performance is measured. These baselines can only change through formal change control processes maintaining their integrity as performance references.
Management approach documentation specifies how processes will be performed including methodologies, tools, templates, governance structures, change control procedures, configuration management approaches, and performance measurement techniques. This process documentation ensures consistent execution aligned with organizational standards while enabling appropriate tailoring for project-specific needs. Clear process definition prevents confusion about how work should be managed and establishes expectations for all project participants.
Plan approval by appropriate authorities including sponsor and key stakeholders signifies organizational commitment to the project as defined in the plan. Approval establishes the plan’s authority as the guide for project execution and the reference for change control. Unapproved plans lack standing as official project direction. The approved plan represents organizational agreement about project direction, approach, and resource commitment enabling confident execution.
Question 167
What is the purpose of requirements management in projects?
A) To eliminate all project requirements
B) To ensure requirements are identified, documented, analyzed, prioritized, and tracked throughout the project
C) To increase project costs
D) To reduce stakeholder involvement
Answer: B) To ensure requirements are identified, documented, analyzed, prioritized, and tracked throughout the project
Explanation:
Requirements management ensures that project and product requirements are identified, documented, analyzed, prioritized, and tracked throughout the project lifecycle maintaining alignment between deliverables and stakeholder needs. This systematic approach prevents requirements from being lost, misunderstood, or incorrectly implemented while enabling controlled evolution as understanding deepens and conditions change. Effective requirements management is essential for delivering solutions that actually satisfy stakeholder needs rather than technically correct deliverables that miss the mark.
Requirements identification uses multiple techniques including stakeholder interviews, surveys, workshops, observation, prototyping, and document analysis to elicit comprehensive requirements from all relevant stakeholder groups. Different stakeholders contribute different requirement types with customers providing functional needs, users contributing usability requirements, technical staff identifying technical constraints, and quality groups specifying quality standards. Systematic elicitation across all stakeholder types prevents requirements gaps.
Requirements documentation captures requirements in sufficient detail for implementation and validation including requirement statements, acceptance criteria, priority, rationale, source, and relationships to other requirements. Documentation formats range from simple lists to formal requirements specifications to visual models depending on project complexity and domain. Adequate detail enables implementation teams to understand what to build while test teams can verify delivery. Insufficient documentation leads to misunderstandings and rework.
Requirements analysis examines requirements for completeness, consistency, feasibility, and testability identifying conflicts, gaps, and ambiguities that would cause problems during implementation. Analysis might reveal requirements that contradict each other, requirements that are technically infeasible, requirements that cannot be objectively verified, or areas where requirements don’t cover necessary functionality. Early analysis enables resolving these issues during planning rather than discovering them during expensive implementation or testing phases.
Requirements traceability links requirements through planning, implementation, and validation ensuring all requirements are addressed and enabling change impact analysis. Traceability prevents requirements from being lost while supporting verification that delivered capabilities satisfy stated needs. When requirements change, traceability reveals all affected artifacts enabling comprehensive impact assessment. Requirements management tools automate traceability maintenance making it practical for large complex projects where manual tracking becomes unmanageable.
Question 168
What is the purpose of a sprint planning meeting in agile/Scrum?
A) To demonstrate completed work
B) To plan the work that will be performed during the upcoming sprint
C) To conduct retrospectives
D) To close the project
Answer: B) To plan the work that will be performed during the upcoming sprint
Explanation:
Sprint planning meetings enable the Scrum team to collaborate in defining the sprint goal and selecting product backlog items that will be developed during the upcoming sprint based on team capacity and priorities. The team discusses how selected work will be accomplished breaking stories into tasks and estimating effort. Sprint planning creates shared commitment to the sprint goal and detailed plan enabling coordinated execution during the sprint. Effective sprint planning balances ambition with realism committing to achievable work that delivers significant value.
Sprint goal definition establishes the overarching objective for the sprint providing cohesive focus rather than treating the sprint as disconnected tasks. The goal might be implementing specific user journey, achieving particular capability, reducing technical debt in certain areas, or delivering minimum viable product. This goal guides daily work decisions and provides context for why selected stories matter. Sprint goals create narrative coherence transforming separate backlog items into purposeful progress toward product vision.
Product backlog item selection determines what work enters the sprint based on priority, value, team capacity, and dependencies. The product owner presents highest-priority items explaining their value and acceptance criteria. The team discusses each item clarifying understanding and identifying concerns. Based on team velocity and capacity considering availability and other commitments, the team selects items they commit to completing. This collaborative selection balances product owner priorities with team capacity realities.
Task breakdown decomposes selected user stories into implementation tasks like design, coding, testing, documentation, and review. This decomposition reveals work required to complete stories and exposes potential issues or dependencies. Team members volunteer for tasks based on skills and interests. Task identification and estimation produce detailed sprint plan showing who will do what and rough effort expectations. This detail enables coordinated execution and helps teams identify if they’ve over or under-committed.
Commitment to selected work represents team agreement that they will complete the selected backlog items to done standard by sprint end. This commitment isn’t a guarantee because new information might emerge requiring adjustment, but it represents the team’s best understanding and intention at sprint start. Commitment creates accountability and focus enabling intense effort toward sprint goals. However, commitment should be realistic avoiding chronic over-commitment that sets teams up for failure and demotivates through repeated inability to deliver promises.
Question 169
What is the purpose of a decision matrix (weighted scoring model) in project selection?
A) To randomly select projects
B) To evaluate and compare project alternatives using multiple weighted criteria
C) To eliminate all project risks
D) To increase all project budgets
Answer: B) To evaluate and compare project alternatives using multiple weighted criteria
Explanation:
A decision matrix evaluates and compares project alternatives or proposals using multiple weighted criteria enabling objective systematic comparison that considers various dimensions of project value and feasibility. This structured approach prevents selection based solely on single criteria or subjective preference by requiring explicit consideration of all important factors. Weighted scoring models support rational investment decisions balancing multiple objectives like strategic fit, financial returns, resource requirements, and risk levels.
Evaluation criteria represent the factors important for project success and organizational benefit including strategic alignment, expected financial returns, implementation feasibility, resource availability, risk levels, urgency, stakeholder support, and any other dimensions relevant to the decision context. Comprehensive criteria ensure all important aspects receive consideration rather than focusing narrowly on subset of concerns. However, too many criteria creates complexity without meaningful differentiation. Typically 5 to 10 criteria provide adequate breadth while remaining manageable.
Criterion weighting reflects relative importance of different factors preventing all criteria from receiving equal weight when some matter more than others. Strategic alignment might receive higher weight than cost for strategically critical initiatives. Financial returns might dominate for purely commercial projects. Risk tolerance might be heavily weighted for risk-averse organizations. Weight assignment forces explicit discussion about priorities rather than leaving them implicit where different evaluators apply different mental weightings producing inconsistent scoring.
Project scoring rates each alternative against each criterion using consistent scales like 1-5 or 1-10. Evaluators assess how well each project satisfies each criterion assigning scores based on defined rating scales. Clear rating definitions prevent subjective interpretation ensuring consistent scoring across evaluators and projects. For example, strategic alignment might be scored 5 for perfect alignment, 3 for moderate alignment, and 1 for poor alignment with specific definitions of what constitutes each level.
Weighted score calculation multiplies each criterion score by its weight then sums weighted scores producing total scores for each alternative. Projects with highest total weighted scores represent best overall options considering all criteria and their relative importance. This calculation makes trade-offs explicit showing how projects that excel in some dimensions but perform poorly in others compare to projects with more balanced performance. The mathematics ensures consistent systematic comparison.
Decision matrix applications extend beyond project selection to any decision requiring multi-criteria evaluation including vendor selection, alternative solution comparison, technology selection, site selection, and strategic option evaluation. The structured framework suits any complex decision where multiple factors warrant consideration and stakeholders need transparent rationale for choices. Decision matrices provide documentation of decision logic supporting stakeholder communication and organizational learning.
Question 170
What is the purpose of a project status report?
A) To eliminate all project communication
B) To provide regular updates on project performance, progress, and issues to stakeholders
C) To increase project costs
D) To avoid stakeholder engagement
Answer: B) To provide regular updates on project performance, progress, and issues to stakeholders
Explanation:
Project status reports provide regular systematic updates to stakeholders about project performance, progress toward objectives, accomplishments since last report, planned work for next period, current issues and risks, and any decisions required from stakeholders. These periodic reports maintain stakeholder visibility into project status preventing surprises while enabling timely intervention when problems emerge. Effective status reporting balances comprehensive information with concise presentation respecting stakeholder time while ensuring adequate transparency.
Performance metrics communicate objective progress using measures like schedule variance, cost variance, earned value metrics, milestone achievement, deliverable completion, and quality indicators. Quantitative metrics provide factual performance assessment complementing narrative descriptions. Trend charts showing performance over multiple periods reveal whether projects are improving, deteriorating, or holding steady. Visual presentation through dashboards or graphs enables quick comprehension of complex performance information.
Accomplishment descriptions highlight completed deliverables, achieved milestones, resolved issues, and other significant progress since the last report. This backward-looking content celebrates success, demonstrates forward movement, and maintains stakeholder confidence that work is progressing. Accomplishment communication motivates teams through recognition while assuring stakeholders that their investment is producing results. However, accomplishment sections should be factual avoiding exaggeration that damages credibility.
Upcoming work previews planned activities, expected deliverables, and key milestones for the next reporting period providing forward visibility into project progression. This forward-looking content helps stakeholders anticipate demands on their time for reviews or decisions and enables coordination with related initiatives. Clear communication about upcoming critical activities enables stakeholders to provide needed support or resources. Advance notice prevents stakeholder unavailability from delaying critical project activities.
Issue and risk sections alert stakeholders to current problems requiring resolution and potential future problems requiring attention or mitigation. This transparency enables timely stakeholder support and decision-making preventing small issues from growing into project-threatening crises. However, issue reporting should provide appropriate context avoiding alarm over routine manageable issues while ensuring serious problems receive adequate visibility and priority. Issues requiring stakeholder action or decision should be clearly identified with specific requests.
Question 171
In project management, what is a resource histogram?
A) A tool to eliminate resources
B) A bar chart showing resource allocation or usage over time
C) A method for creating organization charts
D) A technique for increasing costs
Answer: B) A bar chart showing resource allocation or usage over time
Explanation:
A resource histogram is a bar chart displaying resource allocation or usage over time with time periods on the horizontal axis and resource quantities on the vertical axis. Each bar represents the amount of a specific resource required or utilized during that time period. Resource histograms visualize resource loading patterns revealing peaks, valleys, and over-allocations enabling resource optimization and leveling. These visual tools make resource planning and management more intuitive than tabular data alone.
Over-allocation identification represents a key histogram application by showing periods where required resources exceed available supply. Bars extending above availability limits or marked threshold lines indicate resource conflicts requiring resolution. Visual representation makes over-allocations immediately apparent enabling prompt attention. Without histograms, over-allocations might be overlooked in complex schedules with many activities and resources until execution attempts reveal that simultaneous activities compete for limited resources.
Resource leveling uses histograms to guide schedule adjustments that reduce peaks and fill valleys creating more level resource demand matching available supply. Activities are rescheduled within available float to periods with resource availability. The histogram before and after leveling visually demonstrates improvement showing more uniform resource usage. This visualization helps stakeholders understand leveling benefits and trade-offs like schedule extension to achieve resource feasibility.
Resource smoothing optimizes resource usage within schedule constraints by adjusting activity timing within float to reduce variability and fill underutilized periods without extending project duration. The histogram shows how smoothing reduces extreme peaks and valleys even when some over-allocations cannot be eliminated without schedule extension. Visual feedback guides iterative smoothing adjustments helping planners find optimal resource patterns balancing efficiency against schedule preservation.
Multiple histograms for different resource types provide comprehensive resource planning showing patterns for different resource categories like labor, equipment, materials, or specific skill types. Separate histograms reveal whether resource conflicts affect all resource types or concentrate in specific categories guiding targeted resolution. Portfolio-level histograms aggregating across multiple projects show enterprise resource demand enabling strategic resource planning and investment decisions about resource capacity expansion or contraction.
Question 172
What is the purpose of a lessons learned repository?
A) To forget past project experiences
B) To store and organize lessons learned from projects for future reference and organizational learning
C) To increase project costs
D) To eliminate knowledge sharing
Answer: B) To store and organize lessons learned from projects for future reference and organizational learning
Explanation:
A lessons learned repository stores and organizes documented lessons from past projects creating an organizational knowledge base that enables future projects to benefit from accumulated experience. This centralized searchable collection prevents repeated mistakes while enabling replication of successful approaches. Effective repositories categorize lessons by project type, knowledge area, or issue type enabling efficient retrieval of relevant insights. Organizational project management maturity improves significantly when lessons learned are systematically captured, stored, and applied.
Repository structure and organization determines usability because poorly organized lessons become inaccessible. Categorization by knowledge area like risk management, estimation, stakeholder engagement, or technical domains enables targeted searches. Tagging by project characteristics like size, industry, methodology, or complexity helps identify relevant analogous situations. Full-text search capabilities enable keyword-based retrieval. Standardized lesson format with problem description, impact, root cause, and recommendations facilitates understanding and application.
Quality control for repository entries ensures lessons provide actionable value rather than vague platitudes or complaints. Effective lessons include specific situations, root causes of problems or success factors, concrete impacts that occurred, and recommendations for future projects with sufficient detail to guide application. Poor lessons like “better communication needed” provide limited value while specific lessons like “technical design reviews with customer representatives before implementation prevented costly rework from misunderstood requirements” enable actionable improvement.
Repository promotion and usage requires active effort because repositories don’t provide value unless consulted. Project managers should search repositories during planning for lessons relevant to their projects. Templates and checklists can prompt repository consultation at appropriate project phases. Success stories demonstrating lessons learned value encourage adoption. Repository metrics tracking usage and contribution motivate participation. Without active promotion, repositories become write-only databases where lessons are deposited but never retrieved.
Continuous improvement of the repository itself includes retiring outdated lessons as practices evolve, consolidating duplicate lessons, improving categorization based on usage patterns, and enhancing search capabilities based on user feedback. Repository stewardship ensures the collection remains current and usable rather than accumulating obsolete information that obscures valuable insights. Regular curation maintains repository quality and relevance supporting sustained organizational learning.
Question 173
What is the purpose of a project risk breakdown structure (RBS)?
A) To eliminate all risks
B) To hierarchically organize potential risk sources and categories
C) To increase project costs
D) To create project schedules
Answer: B) To hierarchically organize potential risk sources and categories
Explanation:
The Risk Breakdown Structure hierarchically organizes potential sources of project risk into categories and subcategories providing a structured framework for comprehensive risk identification. This taxonomy ensures systematic consideration of all risk categories preventing focus on obvious risks while overlooking less apparent threats. The RBS guides brainstorming and checklist-based risk identification ensuring coverage across all potential risk domains. Organizations develop standard RBS frameworks based on experience that project teams customize for specific project contexts.
Risk categories at the highest RBS levels might include technical risks, external risks, organizational risks, and project management risks. Technical risks include technology maturity, design complexity, performance requirements, and technical dependencies. External risks include market conditions, regulatory changes, environmental factors, and supplier reliability. Organizational risks include resource availability, funding stability, priority conflicts, and stakeholder support. Project management risks include estimation accuracy, planning completeness, control effectiveness, and communication adequacy.
Subcategory decomposition breaks high-level categories into specific risk sources. Technical risks might decompose into requirements risks, design risks, implementation risks, and integration risks. Requirements risks might further decompose into completeness issues, stability concerns, and clarity problems. This progressive decomposition continues to levels providing actionable detail for risk identification. The hierarchical structure provides both detailed identification guidance and high-level reporting aggregation.
Risk identification workshops use the RBS to systematically explore each category ensuring comprehensive coverage. Facilitators guide participants through RBS branches prompting consideration of risks in each area. This structured approach prevents jumping randomly across risk domains and reduces the likelihood of overlooking entire risk categories. The RBS provides shared language ensuring all participants understand risk categories consistently preventing confusion from terminology differences.
Risk reporting and analysis aggregates risks by RBS category revealing patterns and concentrations. If most high-priority risks cluster in specific categories, focused attention on those areas might be warranted. Category-level risk exposure calculations show which risk domains threaten the project most severely guiding risk response strategy. RBS-based reporting provides executives with understandable risk summaries without overwhelming detail about individual risks.
Question 174
What is the purpose of sensitivity analysis in project risk management?
A) To eliminate all project risks
B) To determine which individual risks or variables have the most impact on project outcomes
C) To increase project complexity
D) To avoid risk planning
Answer: B) To determine which individual risks or variables have the most impact on project outcomes
Explanation:
Sensitivity analysis determines which individual project risks or uncertain variables have the greatest potential impact on project outcomes like completion date or total cost. This technique examines how changes in individual variables affect overall project results revealing which uncertainties matter most for project success. Sensitivity analysis enables focused risk management effort on variables that significantly affect outcomes rather than dispersing effort across all identified risks regardless of their relative importance.
Tornado diagrams represent a common sensitivity analysis visualization showing variables ranked by their impact on project outcomes. Each variable appears as a horizontal bar with length proportional to impact magnitude. The diagram resembles a tornado shape with highest-impact variables at top having longest bars and lowest-impact variables at bottom with shorter bars. This visual ranking immediately reveals which variables warrant intensive risk response and which have minimal impact making them lower priority for risk management investment.
One-variable-at-a-time analysis varies each uncertain input individually while holding others at expected values measuring the resulting change in project outcomes. This approach isolates the effect of each variable enabling direct comparison of impact magnitude. Variables causing large outcome swings when varied require attention while variables causing minimal outcome changes might be accepted or addressed with minimal resources. This analytical focus ensures risk management resources concentrate where they provide most value.
Critical path sensitivity analysis examines schedule risks to determine which activity duration uncertainties most affect project completion date. Activities on or near the critical path typically show high sensitivity because delays directly extend project duration. However, activities with high duration uncertainty might show high sensitivity even if not currently on critical path because duration variations could make them critical. This analysis identifies where schedule risk mitigation provides most schedule protection.
Cost estimate sensitivity analysis examines which cost elements contribute most uncertainty to total project cost. Components with large cost ranges or high uncertainty dominate overall cost risk. Sensitivity analysis reveals whether cost uncertainty concentrates in few elements or distributes broadly across many components. Concentrated uncertainty suggests focused estimation improvement on critical elements could significantly reduce overall cost uncertainty. This insight guides estimation refinement priorities maximizing estimate accuracy improvement for invested effort.
Question 175
What is the purpose of a project dashboard?
A) To eliminate all project reporting
B) To provide visual at-a-glance summary of key project metrics and status
C) To increase project costs
D) To reduce stakeholder involvement
Answer: B) To provide visual at-a-glance summary of key project metrics and status
Explanation:
Project dashboards provide visual at-a-glance summaries of key project metrics, status indicators, and performance trends enabling quick comprehension of project health without detailed report review. These graphical displays use charts, graphs, indicators, and color coding to communicate complex project status simply and intuitively. Effective dashboards highlight exceptions and trends requiring attention while confirming that other aspects are on track. Dashboards serve busy stakeholders who need rapid status understanding without time for detailed analysis.
Key performance indicators selected for dashboard display should represent the most important project success factors including schedule adherence, budget performance, quality metrics, risk exposure, scope completion, and stakeholder satisfaction. Indicator selection balances comprehensiveness with simplicity because overloaded dashboards overwhelm rather than inform. Typically 5-10 well-chosen metrics provide adequate project health visibility without information overload. Metric selection should match stakeholder priorities and concerns.
Visual design principles enhance dashboard effectiveness through color coding using red-yellow-green traffic lights indicating status, trend arrows showing direction of change, gauges displaying current values against targets, and charts revealing patterns over time. Effective dashboards minimize text relying on visual elements for communication. Layout groups related metrics and emphasizes most critical information. Poor dashboard design buries important information in clutter or uses visual elements that obscure rather than clarify meaning.
Drill-down capabilities enable stakeholders to investigate details behind dashboard indicators when deeper understanding is needed. Clicking dashboard elements accesses underlying detailed reports, raw data, or explanation of issues. This layered information architecture serves executives needing high-level overviews and managers requiring operational detail without forcing everyone to wade through comprehensive reports. Drill-down functionality makes dashboards useful across organizational levels.
Real-time or near-real-time updates maintain dashboard currency reflecting latest project status. Automated data feeds from project management systems, time tracking tools, or financial systems enable frequent updates without manual effort. Current information enables timely decision-making and intervention versus outdated dashboards that might show yesterday’s status when situations have changed. However, update frequency should match actual information change rates because excessive updates with minimal changes waste stakeholder attention.
Question 176
What is the purpose of a make-or-buy analysis in procurement management?
A) To always buy everything externally
B) To determine whether project work should be performed internally or procured from external sources
C) To eliminate all vendors
D) To increase project costs
Answer: B) To determine whether project work should be performed internally or procured from external sources
Explanation:
Make-or-buy analysis evaluates whether specific project work, deliverables, or capabilities should be performed internally using organizational resources or procured from external vendors or contractors. This decision considers multiple factors including cost, capability, capacity, risk, strategic importance, and timing determining the optimal sourcing approach for each project component. Effective make-or-buy decisions optimize resource utilization and project outcomes by leveraging internal strengths while accessing external expertise or capacity where beneficial.
Cost comparison represents the most obvious analysis dimension comparing internal performance costs including labor, materials, overhead, and opportunity costs against external procurement costs including purchase price, management overhead, and transaction costs. However, cost comparison proves more complex than simple price comparison because internal costs include allocated overhead and indirect costs while external costs include vendor profit margins and contract management expenses. Lifecycle costs including maintenance and support should be considered not just initial acquisition costs.
Capability assessment examines whether the organization possesses necessary expertise, experience, and skills to perform the work effectively. Work requiring specialized expertise that the organization lacks or performs rarely might favor buying even at premium cost because developing internal capability would be inefficient. Conversely, work within core organizational competencies might favor internal performance leveraging existing strengths. Capability gaps might be temporary, addressed through training, or persistent, necessitating external sourcing.
Capacity considerations evaluate whether sufficient internal resources are available or whether internal resources are better allocated to higher-priority or higher-value work. Even when internal capability exists, resource constraints might necessitate external sourcing. Organizations might retain strategic control over core activities while outsourcing peripheral work to external vendors. Temporary capacity shortfalls might favor contract labor while sustained capacity needs might justify permanent staff additions.
Strategic importance influences make-or-buy decisions because work involving proprietary intellectual property, competitive advantages, or sensitive information might favor internal performance despite higher costs. External sourcing of strategic capabilities creates dependencies and potentially compromises confidentiality. Conversely, commodity products or services without strategic implications favor buying from specialized efficient vendors. The strategic lens considers factors beyond immediate project economics evaluating long-term organizational implications.
Question 177
What is the purpose of a sprint review in Scrum?
A) To plan the next sprint
B) To demonstrate completed work to stakeholders and gather feedback
C) To conduct team retrospectives
D) To eliminate defects
Answer: B) To demonstrate completed work to stakeholders and gather feedback
Explanation:
Sprint reviews provide opportunities for the Scrum team to demonstrate completed work to stakeholders, product owner, and other interested parties gathering feedback about delivered functionality and emerging requirements. This collaborative inspection and adaptation session validates that developed features meet stakeholder needs, surfaces issues requiring correction, and identifies new requirements or priority changes for the product backlog. Sprint reviews create regular touchpoints between development teams and stakeholders maintaining alignment and enabling course corrections before significant work proceeds in wrong directions.
Demonstration of completed work shows actual working software or deliverables rather than progress reports or slide presentations. Stakeholders interact with implemented features assessing functionality, usability, and value. Hands-on demonstration enables authentic feedback about whether solutions meet needs better than abstract descriptions. Only work meeting the definition of done should be demonstrated ensuring stakeholders see quality-complete features not work-in-progress requiring imagination to envision final state.
Stakeholder feedback gathered during demonstrations informs product backlog updates including new requirements, changed priorities, or modifications to existing backlog items. Seeing implemented features often generates ideas for enhancements or reveals misunderstandings requiring correction. This regular feedback loop enables incremental refinement steering development toward greatest value. Feedback immediacy while work is fresh enables efficient correction before teams move to distant topics.
Product backlog adaptation occurs during or after sprint reviews as product owners update the backlog based on demonstration results and stakeholder feedback. New items are added, existing items are modified or removed, and priorities are adjusted reflecting latest understanding and stakeholder input. This backlog evolution maintains relevance ensuring development work addresses current highest-value needs rather than outdated plans. The sprint review directly informs sprint planning for subsequent iterations.
Collaboration and transparency characterize effective sprint reviews with open discussion about what’s working, what’s not working, and what should happen next. Reviews aren’t status reports where the team defends performance but collaborative sessions where all participants contribute to product success. This collaborative atmosphere requires psychological safety where team members can honestly discuss challenges and stakeholders can provide candid feedback without blame. Constructive reviews accelerate learning and improvement while adversarial reviews undermine team morale and stakeholder relationships.
Question 178
What is the purpose of the critical chain method’s feeding buffer?
A) To eliminate all project buffers
B) To protect the critical chain from delays in non-critical task sequences
C) To increase project costs
D) To extend project duration unnecessarily
Answer: B) To protect the critical chain from delays in non-critical task sequences
Explanation:
Feeding buffers in critical chain project management protect the critical chain from delays in non-critical task sequences that merge into critical chain activities. These buffers are inserted at merge points where non-critical paths join the critical chain preventing delays in feeder chains from impacting critical chain progress. Feeding buffers enable independent progress on parallel work streams without forcing critical chain activities to wait when feeding paths experience delays. This protection maintains critical chain continuity improving overall schedule reliability.
Buffer placement at merge points creates cushions absorbing variability from feeding paths. When multiple task sequences converge before a critical chain activity can begin, delays in any feeding sequence threaten the critical chain start date. Feeding buffers provide time allowance accommodating reasonable delays in feeder sequences without pushing back critical chain work. This strategic buffer placement concentrates protection where schedule convergence creates vulnerability.
Buffer sizing typically uses a percentage of the feeding path duration or statistical estimation based on task uncertainty. Common approaches allocate 50 percent of feeding path duration as buffer providing moderate protection without excessive conservatism. More sophisticated approaches consider feeding path task variance and confidence requirements sizing buffers to achieve desired on-time completion probabilities. Buffer sizing balances protection against duration impacts finding appropriate trade-offs between schedule length and completion confidence.
Independent path management becomes possible with feeding buffers because delays in one feeding path consume that path’s buffer without immediately affecting the critical chain or other paths. Teams work on feeding paths can adjust timing within buffer allowances without disrupting overall project coordination. This independence reduces schedule fragility where every minor delay cascades through dependent work. Feeding buffers compartmentalize variability improving schedule stability.
Buffer monitoring tracks feeding buffer consumption relative to feeding path progress providing early warning of potential critical chain impacts. When buffer consumption exceeds feeding path completion percentage, the feeding path is trending toward depleting its buffer and potentially delaying the critical chain. This early indication enables proactive intervention accelerating feeding path work or alerting critical chain activities to potential delays. Buffer monitoring focuses management attention on schedule threats while confirming that other paths are progressing adequately.
Question 179
What is the purpose of a project steering committee?
A) To replace the project manager
B) To provide strategic oversight, guidance, and decision-making support for the project
C) To perform daily project work
D) To eliminate all project governance
Answer: B) To provide strategic oversight, guidance, and decision-making support for the project
Explanation:
Project steering committees provide strategic oversight, governance, and high-level decision support ensuring projects remain aligned with organizational strategy and have necessary resources and support for success. These senior stakeholder groups typically include project sponsor, key business leaders, functional managers, and subject matter experts who guide project direction, resolve escalated issues, approve major decisions, and remove organizational obstacles. Steering committees bridge between project execution and organizational leadership ensuring adequate attention and support for important initiatives.
Strategic alignment oversight ensures projects remain consistent with organizational objectives, priorities, and constraints as both projects and organizational contexts evolve. Steering committees assess whether project direction continues serving intended strategic purposes or whether changed circumstances warrant project modifications or even cancellation. This strategic governance prevents projects from proceeding on autopilot when organizational needs have shifted making original plans obsolete or suboptimal.
Major decision approval provides authority for significant project commitments, changes, or trade-offs that exceed project manager discretion. Decisions about substantial budget increases, major scope changes, significant schedule revisions, or fundamental approach modifications typically require steering committee approval. This governance ensures important decisions receive appropriate senior review and authorization preventing project managers from making commitments beyond their authority. Decision escalation paths clarify what decisions require committee versus project manager approval.
Issue escalation resolution addresses problems that project managers cannot resolve within their authority or that require organizational intervention. Resource conflicts across projects, inter-departmental disputes, funding constraints, or political obstacles might need steering committee intervention. Committee members use their organizational authority and influence to remove impediments enabling project progress. Effective steering committees respond promptly to escalated issues preventing prolonged delays while projects await decisions.
Resource commitment ensures projects have necessary funding, staff, facilities, and other resources throughout project lifecycles. Steering committees authorize resource allocation, resolve resource conflicts with other initiatives, and advocate for project needs within organizational resource allocation processes. This senior backing provides projects with organizational muscle to obtain resources that might otherwise be diverted to competing priorities. Committees periodically review resource adequacy ensuring projects aren’t under-resourced relative to their importance and commitments.
Question 180
What is the purpose of the Estimate at Completion (EAC) in earned value management?
A) To document original project budget
B) To forecast total project cost at completion based on current performance
C) To eliminate cost tracking
D) To increase project scope
Answer: B) To forecast total project cost at completion based on current performance
Explanation:
Estimate at Completion forecasts the expected total project cost at completion based on current performance trends and assumptions about future performance. EAC provides forward-looking cost projections enabling proactive management decisions about funding, scope, or approach before projects fully spend their budgets. Multiple EAC calculation methods exist reflecting different assumptions about whether current performance trends will continue, correct, or require different approaches for remaining work.
The most common EAC formula assumes current cost performance continues for remaining work: EAC equals Budget at Completion divided by Cost Performance Index. This calculation projects current cost efficiency forward over all remaining work. If a project is currently earning 85 cents of value per dollar spent (CPI equals 0.85) and this continues, the total cost will be original budget divided by 0.85. This formula applies when current performance accurately predicts future performance which often occurs after projects pass initial startup phases and establish patterns.
Alternative EAC formulas accommodate different performance assumptions. EAC equals Actual Cost plus Budget at Completion minus Earned Value assumes remaining work will be performed at originally estimated efficiency regardless of past performance. This formula applies when past performance problems are considered atypical and future work is expected to proceed as originally planned. EAC equals Actual Cost plus new estimate for remaining work allows complete re-estimation of remaining work when past performance proves irrelevant to future work or when significant changes make original estimates obsolete.
EAC comparison with Budget at Completion reveals projected cost variance at project completion enabling early assessment of whether budgets will be adequate. Large differences indicate serious cost problems requiring intervention through scope reduction, funding increases, cost reduction initiatives, or potentially project cancellation if costs become untenable. Early EAC visibility enables proactive responses while options remain versus discovering budget inadequacy only when funds are exhausted.
Management action based on EAC analysis includes requesting additional funding when projections show budget shortfalls, implementing cost reduction initiatives when modest improvements might achieve EAC aligned with budget, reducing scope to align remaining work with available funding, or accepting cost overruns while minimizing their extent when other options prove infeasible. EAC provides quantitative foundation for these strategic discussions enabling fact-based decisions rather than relying on optimism or wishful thinking about cost recovery.
