Project Management interview questions

A project is a temporary endeavor undertaken to create a unique product, service, or result. It has a defined beginning and end, distinct from ongoing operations. Key characteristics: 1. Temporary - Every project has a definite start and finish date - Unlike ongoing business operations (payroll, customer support), which repeat indefinitely 2. Unique - Produces a deliverable that has never been produced in exactly this way before - Even if similar work has been done, every project has different people, risks, timelines, or context 3. Progressive elaboration - Details are developed incrementally as more information becomes available - Initial scope may be broad; it becomes more detailed as the project progresses 4. Purpose-driven - Every project exists to deliver specific business value or achieve a defined objective 5. Constrained by the triple constraint (Iron Triangle) - Scope: what are we delivering? - Time: when must it be done? - Cost: what budget is available? - Quality sits at the center — changes to any one of the three affect quality Project vs. Operations: - Project: Building a new HR system (one-time, defined end) - Operation: Running payroll every month (ongoing, repeatable) Projects end when: - Objectives are achieved - Project is cancelled (no longer feasible or needed) - Need no longer exists

The PMBOK Guide (Project Management Body of Knowledge) defines five Process Groups that apply throughout a project's lifecycle. 1. Initiating - Defines the project and authorizes it to begin - Key outputs: Project Charter (formal authorization), stakeholder identification - Key questions: Why are we doing this? Is it feasible? Who are the stakeholders? 2. Planning - Establishes the total scope, objectives, and course of action - Most time-intensive process group — good planning prevents problems later - Key outputs: Project Management Plan, WBS (Work Breakdown Structure), schedule, budget, risk register, communication plan 3. Executing - Carrying out the work defined in the project plan - Largest consumer of budget and resources - PM role: direct and manage project work, manage quality, acquire and develop the team, manage communications 4. Monitoring & Controlling - Tracks, reviews, and regulates progress against the plan - Runs in parallel with all other process groups (not just executing) - Key activities: measure performance, manage changes, verify scope, control costs and schedule 5. Closing - Formally completes the project or phase - Key activities: obtain final acceptance, document lessons learned, release team, archive project records, celebrate achievements Important note: These are Process Groups, not sequential phases. Monitoring & Controlling happens throughout; Planning can revisit during execution if major changes occur. In Agile, these groups still apply but within shorter iterations (sprints) rather than once across the full project.

A Work Breakdown Structure (WBS) is a hierarchical decomposition of the total scope of work into smaller, more manageable components. Purpose: - Makes the full scope of work visible and manageable - Foundation for estimating, scheduling, budgeting, and assigning work - Prevents scope omissions ("we forgot about testing" won't happen with a good WBS) Structure: - Level 1: Project name (top) - Level 2: Major deliverables or phases - Level 3: Sub-deliverables - Level n: Work packages (bottom level — specific, assignable, estimable tasks) The 100% Rule: The WBS must include 100% of the work in the project scope — nothing more, nothing less. Every work package rolls up to its parent, and all parents roll up to the project. Creating a WBS: 1. Start with the project objective 2. Identify major deliverables (Level 2) — think in nouns (deliverables), not verbs (activities) 3. Decompose each deliverable into sub-deliverables until you reach work packages 4. A work package should be: - Assignable to one person or team - Estimable (time and cost can be estimated) - Completable within a single reporting period (ideally ≤ 2 weeks) Example — Website Redesign Project: - 1.0 Website Redesign - 1.1 Requirements - 1.1.1 Stakeholder interviews - 1.1.2 Requirements document - 1.2 Design - 1.2.1 Wireframes - 1.2.2 Visual mockups - 1.3 Development - 1.3.1 Frontend - 1.3.2 Backend - 1.4 Testing - 1.5 Deployment WBS dictionary: A companion document describing each work package (scope, acceptance criteria, responsible party, estimated effort).

A Gantt chart is a horizontal bar chart that visually represents a project schedule — showing tasks, their durations, start/end dates, and dependencies. Key elements: - Y-axis: Tasks or work packages - X-axis: Time (days, weeks, months) - Bars: Duration of each task (bar length = task duration) - Dependencies: Arrows showing which tasks must complete before others can start - Milestones: Diamond symbols marking key dates or deliverables - Critical path: Typically highlighted — the longest sequence of dependent tasks that determines project duration Types of dependencies: - Finish-to-Start (FS): Task B cannot start until Task A finishes (most common) - Start-to-Start (SS): Task B cannot start until Task A starts - Finish-to-Finish (FF): Task B cannot finish until Task A finishes - Start-to-Finish (SF): Rare; Task B cannot finish until Task A starts How PMs use Gantt charts: 1. Planning: Lay out all tasks, estimate durations, connect dependencies 2. Communication: Share timeline with stakeholders and team 3. Progress tracking: Mark completed tasks; identify slippage visually 4. What-if analysis: Change one task duration and see the ripple effect on the whole schedule Limitations: - Can become unwieldy for large, complex projects (100+ tasks) - Shows task timing but not resource allocation or task complexity - Can create false sense of precision in estimates Tools: MS Project (industry standard), Jira (with timelines), Asana, Monday.com, Smartsheet, ProjectLibre (free), Excel In Agile: Gantt charts are less common; sprint boards and burndown charts replace them. However, for release planning or cross-team coordination, Gantt-style roadmaps are still useful.

The Critical Path Method (CPM) is a scheduling technique that identifies the longest sequence of dependent tasks in a project — determining the minimum project duration and which tasks have no scheduling flexibility. Key concepts: Critical Path: The longest path from project start to project end through the network of task dependencies. Any delay on a critical path task delays the entire project. Float (Slack): The amount of time a task can be delayed without delaying the project end date. - Critical path tasks have zero float — they cannot slip at all - Non-critical tasks have positive float — they have scheduling flexibility How to calculate: Step 1: List all tasks with durations and dependencies A(3d) → B(5d) → D(4d) → End A(3d) → C(2d) → D(4d) → End Step 2: Forward pass (calculate Early Start and Early Finish) - ES of first task = 0 (or project start date) - EF = ES + Duration - ES of next task = EF of predecessor Step 3: Backward pass (calculate Late Start and Late Finish) - LF of last task = project end date - LS = LF - Duration - LF of predecessor = LS of successor Step 4: Calculate float Float = LS - ES (or LF - EF) Tasks with Float = 0 → critical path Why CPM matters: - Tells you where to focus management attention (critical path tasks) - Helps evaluate schedule compression options (crash or fast-track critical path tasks) - Enables "what-if" analysis: if this task slips 2 days, what's the new end date? Fast-tracking: Overlapping tasks that were planned sequentially (increases risk) Crashing: Adding resources to shorten critical path tasks (increases cost)

Risk management is the systematic process of identifying, analyzing, and responding to project risks before they become issues. Risk vs. Issue: - Risk: a potential future event that may or may not occur (uncertain) - Issue: a risk that has already materialized (certain, happening now) The risk management process: 1. Risk Identification - Who: PM, team members, stakeholders, SMEs - Methods: brainstorming, interviews, historical data from past projects, checklists - Output: Risk register (initial list of identified risks) 2. Qualitative Risk Analysis - Assess each risk on two dimensions: - Probability: How likely is it to occur? (Low/Medium/High or 1-5 scale) - Impact: How severe would the consequences be? (Low/Medium/High or 1-5 scale) - Risk Score = Probability × Impact - Plot on a Probability-Impact Matrix to prioritize - High probability + High impact → Top priority risks 3. Quantitative Risk Analysis (for high-priority risks) - Assigns numerical values to probability and impact (in money or time) - Expected Monetary Value (EMV) = Probability × Impact in $ - Monte Carlo simulation: runs thousands of scenarios to model schedule/cost uncertainty 4. Risk Response Planning Four strategies for negative risks (threats): - Avoid: Eliminate the threat (change the plan to remove it entirely) - Transfer: Shift the impact to a third party (insurance, contracts, outsourcing) - Mitigate: Reduce probability or impact (more testing, early prototypes, hiring expertise) - Accept: Acknowledge and set aside contingency reserve (active) or do nothing (passive) For positive risks (opportunities): Exploit, Share, Enhance, Accept 5. Risk Monitoring & Control - Review risk register regularly (weekly or at key milestones) - Update probabilities and impacts as project progresses - Watch for risk triggers (early warning signs) - Manage residual risks (what remains after mitigation)

Earned Value Management (EVM) is a project performance measurement technique that integrates scope, schedule, and cost to give an objective view of project health. Core values: - PV (Planned Value): Budgeted cost of work scheduled to be done by now - EV (Earned Value): Budgeted cost of work actually completed by now - AC (Actual Cost): Actual cost incurred for work completed by now Key metrics: Schedule Variance (SV): SV = EV - PV - Positive = ahead of schedule - Negative = behind schedule - Zero = on schedule Cost Variance (CV): CV = EV - AC - Positive = under budget - Negative = over budget Schedule Performance Index (SPI): SPI = EV / PV - > 1.0: ahead of schedule - < 1.0: behind schedule (SPI of 0.8 means doing 80% of planned work) Cost Performance Index (CPI): CPI = EV / AC - > 1.0: under budget (getting more value per dollar spent) - < 1.0: over budget (CPI of 0.9 means spending ₹1 to get ₹0.90 of value) Forecasting: Estimate at Completion (EAC): EAC = BAC / CPI (most common; assumes current cost efficiency continues) (BAC = Budget at Completion = total planned budget) Estimate to Complete (ETC): ETC = EAC - AC Variance at Completion (VAC): VAC = BAC - EAC (positive = under budget at end; negative = over budget) Example: Project budget (BAC) = ₹10L; 50% through schedule PV = ₹5L (should have spent ₹5L by now) EV = ₹4L (only completed ₹4L worth of work) AC = ₹4.5L (actually spent ₹4.5L) SV = 4 - 5 = -₹1L (behind schedule) CV = 4 - 4.5 = -₹0.5L (over budget) SPI = 4/5 = 0.8 (doing 80% of planned work) CPI = 4/4.5 = 0.89 (spending ₹1 to get ₹0.89 of value) EAC = 10 / 0.89 = ₹11.2L (projected to cost ₹11.2L total)

Scrum is an Agile framework for developing and delivering complex products through short, iterative cycles called sprints. Three pillars: Transparency, Inspection, Adaptation 3 Roles: 1. Product Owner (PO) - Owns the product vision and product backlog - Prioritizes backlog; maximizes product value - Single person; not a committee - The "what and why" decision maker 2. Scrum Master (SM) - Servant-leader who facilitates the Scrum process - Removes impediments; coaches the team on Scrum - NOT a project manager — has no authority over the team - Protects the team from external distractions 3. Development Team (Scrum Team) - Cross-functional, self-organizing group (3-9 people) - Owns the "how" — decides how to do the work - Collectively accountable for delivering the Sprint Goal 5 Events: 1. Sprint — 1-4 week timebox; the heartbeat of Scrum 2. Sprint Planning — Team selects backlog items and plans how to deliver them 3. Daily Scrum (Standup) — 15-minute daily sync: what did I do, what will I do, any blockers? 4. Sprint Review — Demo of completed work to stakeholders; backlog updated based on feedback 5. Sprint Retrospective — Team reflects on process: what went well, what to improve? 3 Artifacts: 1. Product Backlog — Ordered list of all desired product features/improvements (PO owns) 2. Sprint Backlog — Items selected for the current sprint + the plan to deliver them (Team owns) 3. Increment — The sum of all completed Product Backlog Items; must be "Done" (usable) Definition of Done (DoD): A shared understanding of what "complete" means for any increment — agreed upon by the team and typically includes coded, reviewed, tested, and documented.

Waterfall and Agile are two fundamentally different approaches to managing projects. Waterfall: - Sequential: each phase must complete before the next begins - Phases: Requirements → Design → Development → Testing → Deployment → Maintenance - Requirements defined upfront; changes are expensive - Heavy documentation; formal sign-offs at each phase gate - Delivery: single big release at the end - Customer sees the product only at the end Agile: - Iterative: work is done in short cycles (sprints/iterations) - Requirements evolve; change is embraced - Lightweight, "just enough" documentation - Working software delivered incrementally (every sprint) - Customer involved throughout; continuous feedback Key comparison: | Dimension | Waterfall | Agile | |---|---|---| | Planning | All upfront | Continuous | | Requirements | Fixed at start | Evolve | | Flexibility | Low | High | | Risk | Realized late | Realized early (fast feedback) | | Delivery | End of project | Every sprint | | Documentation | Heavy | Lightweight | | Best for | Fixed scope, stable requirements | Complex, uncertain, changing requirements | When to choose Waterfall: - Requirements are stable and well-understood (regulated industries) - Fixed-price contracts requiring detailed specs upfront - Short, simple projects - Hardware/physical products where rework is extremely expensive When to choose Agile: - Requirements are uncertain or likely to change - Early feedback is critical (digital products) - Speed to market matters - Cross-functional team in close collaboration Hybrid (most common in practice): Waterfall governance at program level + Agile execution at team level (e.g., SAFe framework).

Scope creep is the uncontrolled expansion of project scope — additional features, requirements, or work that weren't part of the original agreed plan, added without corresponding adjustments to schedule, budget, or resources. Why it's dangerous: - Every added task consumes time and budget without being planned for - Leads to missed deadlines, cost overruns, and team burnout - "Just one small thing" 10 times = a 30% scope increase Common causes: - Poorly defined initial scope (vague requirements = everything is in scope) - No formal change control process - Stakeholders making requests directly to developers (bypassing the PM) - PM unable or unwilling to say no - Unclear definition of done Prevention strategies: 1. Define and baseline the scope - Write a clear scope statement: what IS included and what is NOT included - Get formal sign-off from key stakeholders - A scope you can't say no against is no scope at all 2. Establish a Change Control Process - Every change request must be formally documented - Impact assessed: what does this cost in time, money, and resources? - Approved only by authorized parties (sponsor, steering committee) - No verbal approvals — everything in writing 3. Educate stakeholders - Explain that "adding something small" has a real cost - Help them understand the Iron Triangle: adding scope = adding time or cost or reducing quality 4. Use a WBS as the scope baseline - Anything not in the WBS is out of scope — clear and visual 5. Maintain a parking lot - Good ideas that come up mid-project don't disappear — they go to the parking lot for future phases - Stakeholders feel heard; ideas are preserved without derailing the current project 6. PM discipline - When a new request comes in: "That's a good idea. Let me assess the impact and raise a formal change request."

A project charter is a formal document that officially authorizes a project to exist and grants the project manager the authority to apply resources. It is typically created during the Initiating process group — before detailed planning begins. Key contents: 1. Project Title and Description - One-paragraph description of what the project will deliver 2. Business Justification / Purpose - Why is this project being done? What problem or opportunity does it address? - Links to strategic objectives 3. Project Objectives - Specific, measurable outcomes (SMART goals) - Example: "Reduce customer onboarding time from 5 days to 1 day by Q3 2026" 4. High-Level Scope - What IS in scope (major deliverables) - What is explicitly OUT of scope (prevents assumptions) 5. High-Level Milestones and Timeline - Key dates: project start, major phase completions, go-live 6. Budget Summary - Approved budget or budget range; funding source 7. Stakeholders - Project sponsor, key stakeholders, project team roles 8. Project Manager - Named PM with authority granted (what decisions can the PM make independently?) 9. High-Level Risks and Assumptions - Known risks and major assumptions at project initiation 10. Approval / Sign-off - Project sponsor signature authorizes the project Why it matters: - Gives the PM legitimate authority to request resources and make decisions - Aligns all parties on purpose and scope before work begins - A project without a charter often lacks executive support when issues arise In Agile: Equivalent is the Product Vision and initial Epic-level backlog, though some organizations still create a lightweight charter.

A stakeholder register is a project document that records all stakeholders — anyone who may affect or be affected by the project — along with analysis of their interests, influence, and engagement strategy. Why it matters: - Projects fail more often due to people problems than technical ones - Identifying all stakeholders early prevents surprises late - Different stakeholders need different levels of engagement and communication Key fields in a stakeholder register: | Field | Description | |---|---| | Name / Role | Who they are | | Organization | Department or external | | Contact info | Email, preferred channel | | Requirements | What they need from the project | | Expectations | What they expect as outcomes | | Influence | Level of power over the project (High/Med/Low) | | Interest | Level of interest in the project (High/Med/Low) | | Current engagement | Unaware / Resistant / Neutral / Supportive / Leading | | Desired engagement | Where they need to be | | Communication strategy | What, how often, through which channel | Power/Interest Matrix: - High Power, High Interest → Manage Closely (meet weekly, involve in decisions) - High Power, Low Interest → Keep Satisfied (executive summaries; don't overwhelm) - Low Power, High Interest → Keep Informed (regular status updates) - Low Power, Low Interest → Monitor (minimal effort; inform if relevant changes occur) How to use it: - Created during Initiating; updated throughout the project - Informs the Communications Management Plan (who gets what information, how often, in what format) - Review before major milestones — stakeholder attitudes and power can shift Confidentiality: The full register (especially resistance assessments) is typically kept confidential — shared only with the PM and sponsor.