Project Management — End-Term

Exam Study Guide

(Simple Language + Key Points + Summary for Each
Question)

Q1. Define a ‘Project’ (PMBOK) and its

three primary characteristics
Definition: A Project is a temporary endeavor undertaken to create
a unique product, service, or result.

Key Points (3 characteristics): - Temporary – has a definite start

and end date (not ongoing forever). - Unique – produces something
that didn’t exist before (not repetitive routine work). - Progressive
Elaboration – details get clearer as the project moves forward
(planning improves over time).

Summary: A project is a short-term, one-time job with a clear goal,

done step by step, and it ends once the goal is achieved — unlike daily
operations which repeat forever.

Q2. Five Process Groups and Ten

Knowledge Areas
Key Points — 5 Process Groups (the “phases” every project goes
through): 1. Initiating – starting the project 2. Planning – making the
roadmap 3. Executing – doing the actual work 4. Monitoring &
Controlling – tracking progress, fixing issues 5. Closing – finishing and
handing over

Key Points — 10 Knowledge Areas (the “subjects” managed

throughout): 1. Integration Management 2. Scope Management 3.
Schedule (Time) Management 4. Cost Management 5. Quality
Management 6. Resource Management 7. Communications
Management 8. Risk Management 9. Procurement Management 10.
Stakeholder Management

Summary: Think of Process Groups as “WHEN” (stages of the

project) and Knowledge Areas as “WHAT” (topics you must manage in
every stage).

Q3. Types of Work Breakdown Structures

(WBS)
Key Points: - Deliverable-based WBS – organized by product/output
(e.g., “Login Module,” “Payment Module”). - Phase-based WBS –
organized by project phases (e.g., Design, Development, Testing). -
Responsibility-based WBS – organized by team/department doing
the work. - Geographical/Location-based WBS – organized by
location (used in multi-site projects).

Summary: WBS just means “breaking a big project into smaller

pieces,” and you can slice it by deliverable, by phase, by team, or by
location depending on what’s easiest to manage.
Q4. Four Foundational Values of the Agile
Manifesto
Key Points: 1. Individuals and interactions over processes and
tools 2. Working software over comprehensive documentation 3.
Customer collaboration over contract negotiation 4. Responding
to change over following a plan

Summary: Agile values people, working results, teamwork with the

customer, and flexibility — more than rigid rules, paperwork,
contracts, and fixed plans (though the right-side items still matter, just
less).

Q5. Define ‘Scrum’ and its core roles

Definition: Scrum is an Agile framework used to manage and
complete complex projects through short, repeated cycles called
Sprints (usually 2–4 weeks).

Key Points — 3 Core Roles: - Product Owner – decides WHAT to

build (manages the backlog/priorities) - Scrum Master – helps the
team follow Scrum, removes obstacles (facilitator/coach) -
Development Team – actually builds the product

Summary: Scrum breaks work into small sprints, with three roles:
one person decides priorities (Product Owner), one supports the
process (Scrum Master), and the rest build the product (Dev Team).

Q6. What is a Gantt Chart? Its

components
Definition: A Gantt Chart is a visual bar chart used for scheduling
that shows tasks against time.

Key Points — Main Components: - Tasks/Activities listed

vertically - Timeline (dates) on the horizontal axis - Bars showing
start date, duration, and end date of each task - Dependencies
(arrows connecting related tasks) - Milestones (diamond markers for
key checkpoints) - % Complete indicator for progress tracking

Summary: A Gantt Chart is a timeline picture of the whole project —

showing which task happens when, how long it takes, and how tasks
depend on each other.

Q7. Three-Point Estimation Formula

(PERT)
Key Points: - Formula: Expected Time (TE) = (O + 4M + P) / 6 - O
= Optimistic time (best case) - M = Most Likely time - P = Pessimistic
time (worst case)

Summary: PERT estimates task duration by combining the best-case,

most-likely, and worst-case times into one weighted average — giving
a more realistic estimate than a single guess.

Q8. Stages of an Agile Project

Key Points (typical Agile lifecycle stages): 1. Envision – define
vision/goal of the product 2. Speculate – plan releases and create
backlog 3. Explore – build features in iterations/sprints 4. Adapt –
review, get feedback, adjust 5. Close – finalize and release the
product

(Some curriculums simplify as: Concept → Inception →

Iteration/Construction → Release → Production → Retirement)

Summary: Agile projects move through repeating cycles: envision the

goal, plan a bit, build a bit, review and adapt, and repeat until the
product is ready to close/release.

Q9. Portfolio Management vs Program

Management
Definition (Portfolio Management): Managing a collection of
projects/programs together to achieve strategic business goals.

Key Points — Difference: | Portfolio Management | Program

Management | |—|—| | Manages multiple unrelated projects/programs
| Manages related/grouped projects | | Focus: strategic business goals
| Focus: coordinated benefits between related projects | | Broadest
scope | Narrower than portfolio |

Summary: Portfolio = the whole basket of projects/programs aligned

to company strategy. Program = a smaller group of related projects
managed together for shared benefits.

Q10. Two Open-Source and Two

Proprietary PM Tools
Key Points: - Open-Source: GanttProject, OpenProject (also:
Redmine, Taiga) - Proprietary: Microsoft Project, Jira (also: Asana,
Trello — Trello has free tier but is proprietary company product)

Summary: Open-source tools are free/customizable (e.g.,

GanttProject, OpenProject); proprietary tools are paid, company-
owned software (e.g., MS Project, Jira).

Q11. Project Life Cycle & Influence

vs. Cost of Changes
Key Points — Life Cycle Phases: Starting → Organizing/Preparing →
Carrying out the work → Closing

Key Points — The Important Relationship: - Stakeholder

influence is HIGH at the start and decreases as project
progresses. - Cost of changes is LOW at the start and increases
sharply as project progresses.

Summary: Early in a project, it’s cheap to make changes and

stakeholders have lots of power to shape it. Later, changes become
very expensive, and stakeholders have less power to influence
direction — so plan carefully at the start!

Q12. Traditional (Waterfall) vs Agile using

Triple Constraint
Key Points — Triple Constraint = Scope, Time, Cost (affecting
Quality)

Aspect Waterfall Agile

Fixed early, hard to
Scope Flexible, evolves
change
Time Fixed with detailed plan Fixed (sprint-boxed)
Fixed but scope adjusts to
Cost Fixed budget
fit
Approach Sequential phases Iterative & incremental

Summary: In Waterfall, scope is fixed, so time/cost adjust if

problems occur. In Agile, time and cost are fixed (sprints), and
scope is the flexible variable — features are adjusted to fit the
schedule.

Q13. Purpose of the WBS Dictionary

Key Points: - It’s a supporting document that describes each WBS
component in detail. - Contains: task description, responsible person,
resources needed, cost estimate, deadlines, acceptance criteria. -
Prevents confusion by giving clear ownership and definition of every
work package.

Summary: If the WBS is the “table of contents” of the project, the

WBS Dictionary is the “detailed explanation” for each item — essential
so nothing about scope is left vague or missed.

Q14. Plan-driven vs Agile Development —

When to choose which
Key Points: - Plan-driven (Waterfall): requirements documented
upfront, predictable, good for stable, well-understood
requirements (e.g., construction, regulated industries like
banking/aerospace). - Agile: requirements evolve, good for
uncertain, changing requirements (e.g., startups, new software
products, innovative apps).

When to choose: - Choose Plan-driven when requirements are

clear, low risk of change, strict compliance needed. - Choose Agile
when requirements are unclear, fast delivery and flexibility needed,
customer feedback is important.

Summary: Use Waterfall when you already know exactly what you’re
building; use Agile when things are likely to change and you need to
adapt as you go.

Q15. Extreme Programming (XP) and

Technical Practices
Definition: XP is an Agile methodology that focuses on
engineering/technical excellence to support frequent releases.

Key Points — Practices: - Pair Programming – two developers

code together (catches bugs early) - Test-Driven Development
(TDD) – write tests before code - Continuous Integration – merge
and test code frequently - Refactoring – continuously improving code
without changing behavior - Small Releases – deliver working
software often - Collective Code Ownership – anyone can improve
any part of the code

Summary: XP supports fast, reliable delivery by combining teamwork

(pair programming) with strong coding discipline (testing first,
integrating often, and constantly cleaning up code).

Q16. Scaling Agile from Small Team to

Large Enterprise
Key Points: - Small teams use plain Scrum/Kanban. - Large
enterprises need Scaling frameworks because multiple teams must
coordinate: - SAFe (Scaled Agile Framework) – layers of planning
(team, program, portfolio) - LeSS (Large-Scale Scrum) – extends
Scrum rules to multiple teams - Scrum of Scrums – representatives
from each team sync regularly - Spotify Model – Squads, Tribes,
Chapters, Guilds

Summary: As a company grows, single-team Agile isn’t enough —

scaling frameworks (like SAFe or Scrum of Scrums) add extra
coordination layers so many teams can stay aligned on one big
product.

Q17. Project Manager (Traditional) vs

Scrum Master (Agile)
Key Points: | Project Manager | Scrum Master | |—|—| | Directs and
controls the project | Facilitates and coaches (servant-leader) | |
Assigns tasks to team | Team is self-organizing | | Responsible for
scope, cost, schedule | Responsible for removing obstacles, protecting
the process | | Command-and-control style | Supportive, no direct
authority over team |

Summary: A Project Manager “manages” people and plans directly,

while a Scrum Master “serves” the team — removing blockers and
coaching them to self-manage, without giving direct orders.

Q18. Critical Path Significance

Key Points: - The Critical Path is the longest sequence of
dependent tasks that determines the minimum project duration. -
Tasks on this path have zero slack/float (no room for delay). - If a
task on the Critical Path is delayed → the whole project gets
delayed by the same amount. - Tasks NOT on the critical path have
some slack and can be delayed a little without affecting the deadline.

Summary: The critical path is the “no room for error” chain of tasks
— delay any one of them, and your entire project finishes late.

Q19. Objective of Activity Planning &

Sequencing
Key Points: - Activity Planning identifies all tasks needed and
estimates time/resources for each. - Sequencing determines the
order tasks must be done (dependencies: which task must finish
before another starts). - Together, this leads to a project schedule
(often shown as a network diagram or Gantt chart), which sets the
timeline and identifies the critical path.

Summary: First you list all tasks (activity planning), then you arrange
them in logical order (sequencing) — combining both gives you the
actual project schedule/timeline.

Q20. “Online Shopping” Case Study —

Traditional PM Perspective
Key Points (how to answer using Waterfall approach): -
Initiation: Define project charter — goal is to build an online
shopping platform. - Requirement gathering: All features (catalog,
cart, payment, order tracking) documented upfront in detail. -
Planning: Full WBS, fixed schedule, fixed budget created before
development starts. - Execution: Sequential phases — Design →
Development → Testing → Deployment (one phase completes before
next starts). - Closure: Final testing, sign-off, and handover to client.

Summary: In the traditional approach, the whole “Online Shopping”

system’s requirements and design are locked in at the start, and the
team builds it in one long, sequential process with little room for
change mid-way.

Q21. WBS for “Online Shopping” —

Payment Gateway (3-Level Decomposition)
Key Points (Example structure): - Level 1: Payment Gateway
Module - Level 2: Payment Method Integration - Level 3: Credit/Debit
Card Integration, UPI Integration, Net Banking Integration - Level 2:
Transaction Security - Level 3: Encryption Setup, Fraud Detection,
OTP Verification - Level 2: Payment Confirmation & Records - Level
3: Receipt Generation, Order Status Update, Refund Handling

Summary: Breaking “Payment Gateway” down: Level 1 is the whole

module, Level 2 splits it into sub-functions (integration, security,
confirmation), and Level 3 gives specific tasks under each.

Q22. Converting Traditional Requirement

into User Stories (Agile)
Key Points — User Story format: “As a [user], I want [feature], so
that [benefit].”

Example conversions for Online Shopping: - Traditional

requirement: “System shall allow users to search products.” → User
Story: “As a customer, I want to search for products by name, so that I
can quickly find what I need.” - Traditional requirement: “System shall
process payments.” → User Story: “As a customer, I want to pay
securely using my card, so that I can complete my purchase easily.”

Summary: Instead of writing rigid technical requirements upfront,

Agile rewrites each feature as a short story from the user’s point of
view, focusing on their goal and benefit — making the backlog easy to
prioritize and adjust.
Q23. Scrum Workflow — 2-Week Sprint for
“Product Catalog”
Key Points (Sprint Workflow): 1. Sprint Planning (Day 1): Team
selects Product Catalog backlog items to build. 2. Daily Scrum
(Daily, 15 min): Quick sync — what was done, what’s next, blockers.
3. Development Work (Days 2–9): Team builds features (search,
filter, product listing). 4. Sprint Review (Day 10, end): Demo the
working Product Catalog feature to stakeholders. 5. Sprint
Retrospective (Day 10): Team discusses what went well/what to
improve.

Summary: In a 2-week sprint, the team plans first, works daily with
quick check-ins, then ends with a demo of the finished Product
Catalog feature and a review of how the team can improve.

Q24. PERT Calculation Example

Given: Optimistic (O) = 3 days, Most Likely (M) = 6 days, Pessimistic
(P) = 15 days

Formula: TE = (O + 4M + P) / 6

Calculation: TE = (3 + 4×6 + 15) / 6 = (3 + 24 + 15) / 6 = 42 / 6 = 7

days

Summary: Using the PERT formula, the expected duration of this

task is 7 days.

Q25. Kanban Board for Bug Fixes

Key Points: - Columns: “In-Progress” | “Testing” | “Done”
(sometimes also “To Do” at the start) - Each bug fix is a card that
moves left-to-right across columns as work progresses. - In-Progress:
developer is actively fixing the bug. - Testing: fix is being verified/QA-
checked. - Done: bug fix confirmed working and closed. - WIP (Work-
In-Progress) limits can be set per column to avoid overload.

Summary: A Kanban board visually tracks each bug’s status by

moving its card through columns — giving the whole team an instant
view of what’s being worked on, tested, or finished.

Q26. Gantt Chart for Task Dependencies

(Finish-to-Start)
Key Points: - Finish-to-Start (FS): Task B cannot start until Task A
finishes (most common dependency type). - Example: Design phase
bar ends → Coding phase bar starts right after (no overlap). - On the
Gantt Chart, this is shown with an arrow connecting the end of the
Design bar to the start of the Coding bar.

Summary: In a Finish-to-Start dependency, coding literally cannot

begin until design is 100% complete — the Gantt chart visually shows
this with connected, non-overlapping bars.

Q27. Agile vs Waterfall for “Online

Shopping” — 3 Areas Where Agile Wins
Key Points (pick any 3 with justification): 1. Changing
Requirements: E-commerce trends/features change fast (new
payment methods, UI trends) — Agile adapts easily; Waterfall would
need costly rework. 2. Faster Time-to-Market: Agile releases
working features (like a basic cart) early via sprints; Waterfall waits
till the whole system is done. 3. Customer Feedback: Agile allows
continuous user feedback (e.g., testing checkout flow early) to
improve usability; Waterfall only gets feedback at the end.

Summary: For a fast-changing product like online shopping, Agile

wins because it adapts to new trends quickly, delivers usable features
sooner, and incorporates real customer feedback throughout — not
just at the end.

Q28. Preventing Resource Overallocation

(MS Project style)
Key Points: - Resource Leveling: delay or adjust tasks so no single
resource is scheduled beyond their capacity. - Resource Smoothing:
adjust tasks only within available slack (doesn’t change end date). -
Check resource assignment views (like Resource Usage chart) to
spot overallocated resources (shown in red in MS Project). - Reassign
tasks, adjust timelines, or add more resources to fix conflicts.

Summary: To avoid overloading a team member, tools like MS Project

let you “level” the schedule — spreading tasks out or reassigning
them so no one is working on two things at once.

Q29. Tracking Agile Progress with

Burndown Chart
Key Points: - Burndown Chart: shows remaining work (Y-axis) vs
time (X-axis) during a sprint. - Ideal line trends downward as tasks
are completed. - A horizontal (flat) line means no work was
completed during that period — indicates the team is stuck/blocked
or not progressing.

Summary: A Burndown Chart tracks how much work is left as the

sprint goes on; if the line goes flat instead of sloping down, it’s a
warning sign that the team isn’t making progress (blockers or issues
need attention).

Q30. RACI Matrix for “Online Shopping”

Project
Key Points — RACI meaning: - R = Responsible (does the work) -
A = Accountable (approves/owns the outcome) - C = Consulted
(gives input) - I = Informed (kept updated)

Example Matrix:

Product
Task Developers Testers
Owner
Build Payment Gateway R I A
Test Checkout Flow I R C
Approve Feature for
C C A
Release
Write User Stories I I R/A
Summary: A RACI matrix clearly defines who does the work
(Responsible), who approves it (Accountable), who’s asked for input
(Consulted), and who’s just kept in the loop (Informed) — avoiding
confusion about roles on the Online Shopping project.

Quick Revision Checklist Before

Exam
✅ PMBOK definition + 5 Process Groups + 10 Knowledge Areas
✅ WBS types + WBS Dictionary purpose
✅ Agile Manifesto’s 4 values + Scrum roles
✅ Gantt Chart components + Finish-to-Start dependency
✅ PERT formula: (O + 4M + P) / 6 — practice the calculation!
✅ Waterfall vs Agile (Triple Constraint logic)
✅ Critical Path meaning
✅ Burndown chart interpretation
✅ RACI roles (R/A/C/I)
✅ Apply everything to the “Online Shopping” case study (WBS,
User Stories, Sprint, RACI)

Good luck with your exam!