Leading and managing the team

PMP's 'People' domain is about 42% of the exam, and this is its beating heart. You are expected to know servant leadership, conflict handling, team development, and how to spot and fix performance issues - all through an agile-and-predictive-agnostic lens.

Servant leadership

Modern PMI doctrine favours servant leadership over command-and-control. The servant leader removes blockers, coaches, shields the team from noise, and grows people's capability rather than directing every task. Emotional intelligence (EI) is the tool: self-awareness, self-management, social awareness, relationship management.

Tuckman's stages of team development

• Forming - polite, unsure, low output.
• Storming - conflict emerges as roles and ideas clash.
• Norming - team starts cooperating and trusting.
• Performing - high performance, low supervision needed.
• Adjourning - team disbands at project close.

A project manager's leadership style should flex per stage - directive early, more hands-off by Performing.

Conflict resolution modes (know all five)

• Withdraw/avoid - retreat from a conflict; use when the issue is trivial or more time is needed.
• Smooth/accommodate - emphasise agreement over differences; preserves harmony but doesn't solve root cause.
• Compromise - both sides give up something; lose-lose but fast.
• Force/direct - one view wins; use only in emergencies or on safety issues.
• Collaborate/problem-solve - the gold-standard win-win; incorporates multiple viewpoints, takes longest, PMI's preferred default.

Common mistakes to avoid on exam questions

• Don't pick 'force' or 'compromise' when 'collaborate' is offered as an option - collaborate is nearly always the best answer unless time-critical or safety-critical.
• Don't confuse a Team Charter (ground rules the team agrees together) with a RACI chart (who does what).
• Recognise that conflict is normal and often healthy - the PM's job is to manage it, not eliminate it.
• Escalation is a last resort, only after the PM and team have tried to resolve it directly.
• Virtual/distributed teams need extra deliberate communication planning - don't assume co-located norms apply.

Motivation theories worth knowing

• Maslow's hierarchy - physiological through self-actualisation.
• Herzberg's two-factor - hygiene factors (pay, conditions) prevent dissatisfaction but don't motivate; motivators (growth, recognition) drive performance.
• McGregor's Theory X/Y - X assumes people dislike work and need control, Y assumes people are self-motivated; PMI favours Theory Y thinking.

Remember: exam scenarios test judgement, not memorised definitions - always pick the answer that best serves the team and the project's outcome, in that order.

What 'technical project management' covers

This is the biggest of the three PMP domains (about half the exam). It is the hands-on mechanics of running a project: planning, scheduling, budgeting, scope, risk, quality, and integrating all of it into one coherent plan. It applies whichever approach you use - predictive (waterfall), agile, or hybrid.

Planning and integration

• The project charter authorises the project and names the project manager - work never starts on scope, budget or schedule before it exists.
• The project management plan is the master document; subsidiary plans (scope, schedule, cost, quality, resource, communications, risk, procurement, stakeholder) all roll up into it.
• Integrated change control means every change request goes through one controlled process, usually via a Change Control Board (CCB) - never action a change informally, even a 'small' one.
• Progressive elaboration: plans get more detailed as more information becomes available, especially on agile or hybrid projects.

Scope, schedule and cost

• Scope baseline = scope statement + WBS + WBS dictionary; decomposition breaks deliverables down until each work package is manageable (roughly 8-80 hours as a rule of thumb).
• Critical path = the longest sequence of dependent tasks; it has zero float and sets the shortest possible project duration.
• Float (slack) is the time a task can slip without delaying the finish date - free float affects only the next task, total float affects the whole path.
• Earned Value Management: SV = EV - PV, CV = EV - AC, SPI = EV/PV, CPI = EV/AC. A CPI or SPI below 1.0 means over budget or behind schedule; above 1.0 is favourable.
• Three-point (PERT) estimate: (Optimistic + 4×Most likely + Pessimistic) / 6.

Risk and quality

• Risks are logged in the risk register; each gets a probability, impact, owner and response strategy.
• Response strategies: for threats - avoid, mitigate, transfer, accept; for opportunities - exploit, enhance, share, accept.
• Quality is planned in, not inspected in at the end - cost of quality (prevention + appraisal) is cheaper than cost of poor quality (internal + external failure).
• Contingency reserve covers known-unknowns (identified risks); management reserve covers unknown-unknowns and needs sponsor approval to use.

Common mistakes to avoid on the exam

• Don't confuse the critical path (longest duration) with the highest-risk path - they're different concepts.
• Don't pick 'escalate to sponsor' as a default answer - PMP favours the PM solving problems directly first.
• Remember CPI/SPI: numbers ABOVE 1.0 are good, BELOW 1.0 are bad - it's easy to mix these up under exam pressure.
• A change, even a tiny one, always goes through the change control process - there's no such thing as an off-the-books favour.

Why this topic matters

PMP exam content is split across three domains: People, Process, and Business Environment. Business Environment is the smallest slice (about 8 percent of exam questions) but it trips people up because it is less about mechanics and more about judgement — connecting project work to organisational strategy, governance, compliance and benefit realisation.

Core ideas to know

• Projects exist to deliver business value, not just outputs. Always tie project decisions back to the organisation's strategic goals and business case.
• The business case justifies the investment before the project charter is signed off. It should be revisited at phase gates to confirm the project is still worth doing.
• Benefits realisation does not stop at project closure. A benefits management plan tracks value delivery often long after the project team disbands, sometimes owned by an operations or business owner.
• Compliance means meeting external laws, regulations, standards and internal policies. The project manager must identify applicable compliance requirements early (during initiating and planning) and build them into scope, quality and risk plans, not bolt them on later.
• Regulatory and legal requirements are usually non-negotiable constraints, unlike organisational policies which may sometimes be tailored with sponsor approval.
• External business environment factors to scan for: legal, regulatory, geopolitical, market, social and technological changes (a classic PESTLE-style scan), because any of these can trigger scope or risk changes mid-project.
• Organisational Process Assets (OPAs) and Enterprise Environmental Factors (EEFs) both shape how compliance is handled: EEFs are things you don't control (laws, market conditions, culture); OPAs are internal templates, policies and lessons learned you do control.
• A project manager should support organisational change management, helping the business adopt project outputs so benefits are actually realised.

Common mistakes

• Treating compliance as a one-off checkbox at the start rather than an ongoing thread through the whole lifecycle.
• Confusing the business case (why do this project) with the benefits management plan (how we will measure and sustain the value afterwards) — they are separate but linked artefacts.
• Assuming the project manager owns benefits realisation alone; it is usually a shared responsibility with the sponsor and business owner.
• Ignoring external environment shifts (new law, new regulation) once the project is underway — the exam rewards proactively monitoring and adapting.
• Forgetting that non-compliance can trigger legal, financial and reputational risk, so compliance requirements belong in the risk register too.

Exam tip

When a scenario mentions a new regulation, an audit, or a question of whether the project still aligns with strategy, think 'business environment' first — the correct answer usually involves updating the business case, checking compliance requirements, or escalating to the sponsor rather than the PM unilaterally deciding.

What 'agile' means on the PMP

Agile is a mindset built on the Agile Manifesto's 4 values and 12 principles - individuals and interactions over processes and tools, working product over documentation, customer collaboration over contract negotiation, responding to change over following a plan. The exam tests values, not just frameworks like Scrum.

Hybrid approaches

A hybrid approach blends predictive (waterfall) and agile elements - for example fixed-scope hardware delivered predictively while the software layer is built in sprints. Choose hybrid when parts of the project have high certainty and other parts have high uncertainty or changing requirements. The PMP treats 'tailoring' as picking the right blend for the context, not forcing one method everywhere.

Key agile roles and events

• Product Owner: owns and prioritises the backlog, maximises product value.
• Scrum Master / team facilitator: removes impediments, protects the team, coaches agile practice.
• Development team: cross-functional, self-organising, typically 3-9 people.
• Sprint length: fixed timebox, commonly 1-4 weeks, most often 2 weeks.
• Daily standup: 15 minutes, same time/place, three questions (done, doing, blockers).
• Sprint review: inspect the increment with stakeholders.
• Retrospective: inspect the process and agree improvements for next sprint.

Estimating and flow

Story points size relative effort/complexity, not hours. Velocity = story points completed per sprint, used to forecast future capacity - never compare velocity between different teams. Kanban uses a pull system with WIP limits and measures cycle time and lead time rather than sprints. Burndown charts show remaining work over time; burnup charts show progress against a growing or fixed scope.

Servant leadership

Agile favours servant leadership - the PM/coach serves the team, removes obstacles, and pushes decision-making down to the team rather than commanding. This is a heavily tested mindset shift from traditional command-and-control PM.

Common mistakes

• Do not pick 'predictive' just because the question mentions a large or complex project - complexity plus changing requirements usually points to agile or hybrid.
• Do not confuse story points (relative sizing) with hours (absolute time).
• Do not assume Scrum Master is a project manager - the role facilitates, it does not direct.
• Do not think agile means no documentation - it means just enough documentation, only what adds value.
• Remember tailoring is a PMBOK/PMP principle: adapt the approach, artefacts and events to fit the project, team and organisation.

Risk management

Risk is 'an uncertain event that, if it occurs, has a positive or negative effect'. PMP tests that you treat threats AND opportunities the same process.

• Identify Risks feeds a living Risk Register (owner, trigger, response) and the Risk Report (overall project exposure).
• Qualitative analysis uses a probability-impact matrix to rank risks fast; Quantitative analysis (e.g. Monte Carlo, expected monetary value/EMV) puts numbers on cost and schedule exposure.
• EMV = probability x impact. Add EMVs across a decision tree's branches to pick the best option.
• Threat responses: avoid, mitigate, transfer, escalate, accept.
• Opportunity responses: exploit, enhance, share, escalate, accept.
• Contingency reserve covers KNOWN risks (identified, in the register); management reserve covers UNKNOWN-unknowns and needs a change request to release. Common trap: exam mixes these two up.
• Risk appetite (broad willingness to take on risk) vs risk threshold (the measurable line you won't cross) vs risk tolerance (the acceptable range of variation).
• A risk is only 'closed' when it can no longer occur or its response is complete - review this at every status meeting.

Procurement

• Contract types sit on a risk spectrum: Fixed Price (seller carries cost risk), Cost-Reimbursable (buyer carries cost risk), Time & Materials (hybrid, used for small/undefined scope).
• Common fixed-price variants: FFP (Firm Fixed Price), FPIF (Fixed Price Incentive Fee - shares savings/overruns via a Price Ceiling), FP-EPA (Economic Price Adjustment - for multi-year contracts vulnerable to inflation).
• Point of Total Assumption (PTA) is the cost above which the seller absorbs all further overrun in an FPIF contract.
• Cost-reimbursable variants: CPFF (fixed fee, no incentive), CPIF (fee varies with performance), CPAF (fee is mostly subjective, buyer-determined).
• Procurement documents: RFI (gather information), RFQ (get a price for standard items), RFP (full proposal for complex needs) - know which one fits which scenario.
• The Procurement Statement of Work (SOW) is what goes OUT to sellers; the make-or-buy analysis decides whether you need a seller at all.
• Source selection criteria should be set BEFORE bids arrive, never adjusted afterwards to favour a preferred bidder.

Stakeholder management

• Process order: Identify Stakeholders -> Plan Stakeholder Engagement -> Manage Stakeholder Engagement -> Monitor Stakeholder Engagement.
• The Stakeholder Engagement Assessment Matrix tracks each stakeholder's CURRENT vs DESIRED engagement level: Unaware, Resistant, Neutral, Supportive, Leading.
• Power/interest grid decides communication effort: high power + high interest = manage closely; high power + low interest = keep satisfied.
• The exam favours proactive, continuous stakeholder engagement over one-off identification at kickoff - stakeholders change across the lifecycle, so re-assess regularly.
• Common mistake: treating a difficult stakeholder as a 'people problem' to escalate immediately, rather than first trying to understand their underlying interest and adjust the engagement plan.

What the project lifecycle actually is

A project moves through phases from start to finish: starting the project, organising and preparing, carrying out the work, and closing the project. PMI does not mandate one fixed set of phase names — lifecycles can be predictive (plan-driven, phases done in sequence), adaptive/agile (iterative, work delivered in short cycles), or hybrid (a mix, e.g. predictive planning with agile delivery). The exam expects you to pick the right lifecycle for the context, not recite one true version.

Predictive vs adaptive vs hybrid

• Predictive: scope, schedule and cost are defined early and changes go through formal change control. Good for well-understood, low-uncertainty work (construction, regulated builds).
• Adaptive: requirements emerge and evolve through iterations; change is expected and welcomed. Good for high-uncertainty, evolving-requirement work (new software features).
• Hybrid: blends both, often predictive at a programme level with adaptive delivery teams underneath.

The 8 performance domains (replaced the old 5 process groups + 10 knowledge areas in the 7th edition)

• Stakeholders — identifying, understanding and engaging people affected by or affecting the project.
• Team — leadership, team culture, and creating a high-performing team environment.
• Development approach and life cycle — choosing predictive, adaptive or hybrid and setting cadence.
• Planning — evolving plans across scope, schedule, cost, quality, resources and risk.
• Project work — managing processes, resources, procurement and continuous learning.
• Delivery — meeting requirements, scope and quality to produce the intended business value.
• Measurement — tracking performance and taking appropriate action (EVM, KPIs, forecasts).
• Uncertainty — identifying and responding to risk, ambiguity and complexity.

Common mistakes

• Confusing performance domains (7th edition, outcome-focused, interacting throughout the project) with the old 5 process groups (initiating, planning, executing, monitoring & controlling, closing) — both can appear on the exam, but the process groups describe sequential-ish activity, while domains are continuous and overlapping.
• Assuming every project must use one lifecycle type throughout — hybrid is common and PMI-endorsed.
• Thinking phases must always be sequential — in adaptive lifecycles, phases can overlap and repeat.
• Forgetting that performance domains are interdependent — a change in one (e.g. uncertainty) affects others (e.g. planning, delivery) simultaneously, not in isolation.

Exam tip

Situational questions describing an outcome (e.g. 'the team is not engaging stakeholders effectively') map to a performance domain, not a single process step. Read for which domain is failing, then pick the action that best serves that domain's intent — value delivery over rigid process-following.