71. What is the difference between a project and a program in project management?
- A program is a smaller version of a project with fewer deliverables and team members
- A project is a temporary endeavor producing a specific deliverable; a program is a group of related projects managed in a coordinated way to obtain benefits not available from managing them individually
- Programs are ongoing operations; projects are one-time software releases
- There is no meaningful difference — both terms are used interchangeably in PMI standards
Answer : B Explanation: A Project is a temporary, unique endeavor with a defined beginning and end, producing a specific deliverable (product, service, or result). A Program is a group of related projects, subsidiary programs, and program activities managed in a coordinated manner to achieve strategic benefits. Example: “Transform Customer Experience” is a program containing projects for: new CRM system, customer portal redesign, mobile app development, and staff training. A Portfolio is a higher-level collection of programs and projects aligned with organizational strategy. Program Managers focus on delivering strategic benefits; Project Managers focus on specific deliverables within time/cost/scope constraints.
72. What is velocity in Agile project management?
- The speed at which individual developers type code during a sprint
- A metric that measures the amount of work a Scrum team completes in a sprint, typically measured in story points — used to predict future sprint capacity and forecast release dates
- The rate at which software bugs are discovered and fixed during testing sprints
- The speed of the software application measured in transactions per second
Answer : B Explanation: Velocity is the total story points (or other units) of work a Scrum team completes in a sprint. If a team completes 40 story points in Sprint 1, 35 in Sprint 2, and 42 in Sprint 3, their average velocity is approximately 39. Velocity is used for: Sprint Planning (teams take on work up to their average velocity), Release Planning (estimating how many sprints are needed to complete the backlog), and Identifying trends (is velocity increasing/stable/decreasing?). Velocity should NOT be used to compare teams — different teams estimate differently. Velocity typically stabilizes after 3-5 sprints as the team matures. It is a planning tool, not a performance target.
73. What is the purpose of daily stand-up meetings in Scrum?
- A lengthy daily project status meeting where each team member reports to the project manager
- A short (15-minute maximum) daily synchronization meeting where each team member answers three questions: What did I do yesterday? What will I do today? Are there any impediments in my way?
- A daily code review meeting where developers review each other’s code for quality
- A daily customer meeting where new requirements are gathered and added to the sprint
Answer : B Explanation: The Daily Scrum (stand-up) is a 15-minute time-boxed event held at the same time and place every day during the sprint. Each team member answers three questions: What did I accomplish yesterday that helped the team meet the Sprint Goal? What will I do today to help the team meet the Sprint Goal? Do I see any impediment that prevents me or the team from meeting the Sprint Goal? The meeting is for the development team — the Scrum Master facilitates; the Product Owner may attend but doesn’t direct. Extended discussions are taken offline (parking lot). The stand-up promotes team coordination, early problem detection, and accountability without being a status report to management.
74. What is the purpose of a project risk register?
- A financial document registering the monetary impact of each project risk
- A document that records all identified risks along with their probability, impact, priority, risk owner, and planned response strategies — updated throughout the project lifecycle
- A legal document required by regulators to register software project risks
- A database of historical software bugs classified by risk severity level
Answer : B Explanation: The Risk Register is the primary risk management artifact in project management. It typically contains: Risk ID and description, Category (technical, schedule, cost, resource, external), Probability (low/medium/high or percentage), Impact (low/medium/high or monetary value), Risk Score (Probability × Impact), Priority, Risk Owner (accountable person), Risk Response Strategy (Avoid, Transfer, Mitigate, Accept), Contingency Plan (if the risk occurs), and Current Status. The Risk Register is created during risk identification and continuously updated throughout the project. Reviewing the risk register in project status meetings ensures risks are actively monitored and responses are updated as conditions change.
75. What is the difference between a project plan and a project schedule?
- A project plan lists team members; a project schedule lists deliverables
- A project plan is a comprehensive document covering all aspects of how the project will be executed (scope, cost, quality, risk, communication, resources); a project schedule is specifically the timeline of activities with dates, durations, and dependencies
- A project schedule is more important than a project plan for all project types
- Both documents are identical — the terms are used interchangeably by project managers
Answer : B Explanation: The Project Management Plan is the comprehensive “how” document — it integrates all subsidiary plans: Scope Management Plan, Schedule Management Plan, Cost Management Plan, Quality Management Plan, Resource Management Plan, Communications Management Plan, Risk Management Plan, Procurement Management Plan, and Stakeholder Engagement Plan. The Project Schedule is a component of the project plan — specifically the timeline document showing when activities will happen, their sequence, and who is responsible. The schedule is often represented as a Gantt chart or network diagram. The project plan is the overall blueprint; the schedule is the specific calendar of activities.
76. What is the role of communication in project management?
- Communication is only important during the closing phase when final reports are written
- Effective communication is critical throughout all project phases — research shows project managers spend up to 90% of their time communicating, and poor communication is one of the leading causes of project failure
- Communication is the responsibility of the project sponsor, not the project manager
- Communication only involves sending status reports to senior management weekly
Answer : B Explanation: Communication is arguably the most critical project management skill. PMI research indicates that project managers spend approximately 90% of their time communicating. Effective communication includes: identifying stakeholder communication needs, choosing appropriate channels (email, meetings, reports, dashboards), tailoring messages to the audience, managing information flow, and ensuring feedback loops. The Communications Management Plan documents who needs what information, when, in what format, and through which channel. The number of potential communication channels in a project with n people = n(n-1)/2 — this grows rapidly with team size, highlighting why structured communication management is essential.
77. What is the definition of project scope creep?
- A deliberate and planned expansion of project scope approved by the change control board
- The uncontrolled, gradual expansion of project scope beyond its original boundaries — adding features or requirements without corresponding adjustments to time, cost, or resources
- A natural reduction in project scope as requirements become clearer during development
- The process of creeping toward the project deadline as the schedule slips
Answer : B Explanation: Scope creep is one of the most common and dangerous project management problems. It occurs when new requirements, features, or work are added without formal change control — typically without adjusting the schedule, budget, or resources. Causes: vague initial requirements, poor change control processes, stakeholder pressure, and team members adding “nice to have” features without approval. Prevention: clear scope definition in the project charter, strong change control process, well-defined acceptance criteria, regular scope reviews, and effective stakeholder management. In Agile, scope changes go through the Product Owner to the Product Backlog and are prioritized — this manages scope changes while allowing flexibility.
78. What is the difference between a project issue and a project risk?
- Issues are financial problems; risks are technical problems in a project
- A risk is a potential future event that may or may not occur; an issue is a risk that has already occurred and requires immediate action to resolve
- Risks are managed by the project manager; issues are managed by the Scrum Master
- Issues and risks are the same thing — both require the same management approach
Answer : B Explanation: A Risk is uncertain — it might happen in the future and has both probability and impact. You proactively plan responses for risks (avoid, mitigate, transfer, accept). An Issue is certain — it has already happened and is currently impacting the project. Issues require reactive, immediate resolution. Issues are tracked in an Issue Log (separate from the Risk Register) with: issue description, date identified, impact, assigned owner, planned resolution, and resolution date. A risk that occurs becomes an issue. Example: “Key developer might leave the project” is a risk. “Key developer has given notice and is leaving next week” is an issue.
79. What is the Prototyping model in software development?
- A model where the final software product is built only using third-party software prototypes
- A software development approach where an early working model (prototype) of the system is built and refined through iterative feedback from users before the final system is developed
- A manufacturing model adapted for software where physical prototypes are tested first
- A project management model where only prototype features are delivered to customers
Answer : B Explanation: The Prototyping Model involves building a simplified working version (prototype) of the system early, presenting it to users for feedback, refining it based on feedback, and repeating until the users are satisfied — then building the final system. Types: Throwaway/Rapid Prototyping (prototype is discarded after requirements are clarified), Evolutionary Prototyping (prototype evolves into the final system), Incremental Prototyping (multiple prototypes of different subsystems), and Extreme Prototyping (used in web development with three stages). Benefits: reduces risk of building the wrong system, enhances user involvement, and clarifies unclear requirements. Risk: users may mistake the prototype for the finished product.
80. What is the purpose of a feasibility study in project management?
- A study conducted after project completion to evaluate whether the project was successful
- An analysis conducted before project initiation to determine whether the project is technically possible, financially viable, legally permissible, operationally suitable, and scheduled appropriately
- A market research study to identify potential customers for a software product
- A study that identifies the most feasible programming language for a project
Answer : B Explanation: A Feasibility Study evaluates whether a proposed project should be pursued before committing significant resources. It typically examines five dimensions: Technical Feasibility (can we build it with current technology and skills?), Economic/Financial Feasibility (is the ROI positive? — cost-benefit analysis), Legal Feasibility (are there any legal, regulatory, or contractual obstacles?), Operational Feasibility (will the solution work in the existing organizational environment?), and Schedule Feasibility (can it be delivered within the required timeframe?). The output is a Feasibility Report with a recommendation to proceed, modify, or abandon the project. Project Planning begins immediately after a positive feasibility study.
