PMGT-BC cheat sheet

A project is a temporary endeavor producing a unique product, service, or result; operations are ongoing and repetitive.

Triple constraint: scope, time, and cost are interdependent; a change to one typically forces adjustment to at least one other.

Project life cycle phases (generic): starting, organizing and preparing, carrying out the work, and closing.

Process groups are Initiating, Planning, Executing, Monitoring and Controlling, and Closing; they are not sequential phases and repeat as needed.

Ten knowledge areas: integration, scope, schedule, cost, quality, resource, communications, risk, procurement, and stakeholder management.

A stakeholder is anyone who can affect or be affected by the project; influence/interest grids prioritize engagement effort.

Organizational structures: functional (PM has little authority), matrix (weak/balanced/strong), and projectized (PM has high authority).

A project charter authorizes the project and names the project manager; it is issued by the sponsor.

Earned value formulas: CV = EV - AC; SV = EV - PV; CPI = EV/AC; SPI = EV/PV; EAC (typical) = BAC/CPI.

Predictive (waterfall) life cycles define detailed scope early and manage change through formal integrated change control.

WBS decomposition follows the 100% rule: child elements must capture all work of the parent, no more and no less.

A work package is the lowest WBS level at which cost and duration can be reliably estimated and managed.

Critical path is the longest path through the network and determines the shortest possible project duration; its total float is zero.

Total float = LS - ES or LF - EF; a negative float indicates the project is behind a required date.

PERT expected duration = (Optimistic + 4 x Most Likely + Pessimistic) / 6.

Three-point estimating and analogous, parametric, and bottom-up techniques differ in accuracy and cost of preparation.

Cost baseline = approved time-phased budget excluding management reserves; contingency reserves cover known risks.

Change control steps: request, assess impact, decide (approve/reject/defer), update plans and baselines, communicate, and verify.

Agile Manifesto values: individuals and interactions, working software, customer collaboration, and responding to change over their counterparts.

Scrum roles are Product Owner, Scrum Master, and Developers; the Scrum Master serves the team and removes impediments rather than directing work.

Scrum events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective; the Sprint is the container for the others.

Scrum artifacts: Product Backlog, Sprint Backlog, and Increment; the Definition of Done governs when work counts as complete.

Kanban limits work in progress (WIP) to expose bottlenecks and optimize flow; it prescribes no fixed iterations or roles.

XP practices include pair programming, test-driven development, continuous integration, and small releases.

Velocity = story points completed per iteration; use it for forecasting, not for comparing teams.

Burndown charts track remaining work over time; burnup charts show completed scope against total scope.

Servant leadership, self-organizing teams, and empirical inspection/adaptation underpin agile delivery.

BABOK knowledge areas include planning, elicitation and collaboration, requirements life cycle management, strategy analysis, requirements analysis and design definition, and solution evaluation.

Requirements classification: business requirements, stakeholder requirements, solution requirements (functional and nonfunctional), and transition requirements.

Elicitation techniques include interviews, workshops, observation, surveys, document analysis, and prototyping; technique choice depends on stakeholder access and need type.

A use case describes actor-system interactions toward a goal; a user story is a short placeholder for a conversation, often in 'As a... I want... so that...' form.

MoSCoW prioritizes requirements as Must have, Should have, Could have, and Won't have this time.

Traceability links requirements to their source, to design elements, and to test cases, supporting impact analysis and coverage.

A context diagram defines solution scope by showing the system as a single process with external entities and data flows.

Root cause analysis (for example, the five whys or fishbone diagram) precedes recommending a solution to a business problem.

Requirements must be verified for characteristics such as unambiguous, complete, consistent, feasible, and testable.