Interviews

When you need detailed, individual input from stakeholders.

PM interviews marketing lead to define campaign requirements.

Focus Groups

When you want diverse stakeholder input quickly.

Gather customers + users to discuss features of a new mobile app.

Facilitated Workshops (e.g., JAD)

When you need cross-functional alignment.

Business, IT, and compliance meet to define system requirements.

Brainstorming

For idea generation, especially early in project.

Team brainstorms features for a new e-commerce site.

Questionnaires / Surveys

When you need input from large groups.

Online survey sent to 1,000 potential customers.

Prototypes

When requirements are unclear → show model, refine through feedback.

Create wireframes for a new web platform.

Observation (“Job Shadowing”)

When you want to see how users actually work.

PM shadows warehouse staff to define inventory system requirements.

Benchmarking

When you want to compare practices with industry peers.

Compare logistics practices with leading competitors.

Document Analysis

When historical/legacy systems exist.

Analyze current process manuals to extract requirements.

Avoid (AMTA)

Negative (Threat)

Use when the risk cannot be accepted and you want to eliminate it completely.

Change the project plan, scope, or approach to remove the threat.

Changing the supplier to avoid a high-risk vendor.

Mitigate (AMTA)

Negative (Threat)

Use when you cannot remove the risk but can reduce its probability or impact.

Add safeguards, quality checks, redundancies, or training.

Adding extra testing to reduce defects.

Transfer (AMTA)

Negative (Threat)

Use when you cannot manage the risk directly but can shift the responsibility to a third party.

Use contracts, warranties, or insurance.

Purchasing cyber insurance to handle potential data breaches.

Accept (AMTA & EESA)

Negative (Threat) & Positive (Opportunity)

Use when the cost or effort to manage the risk is higher than its impact.

Do nothing proactively but monitor the risk.

Accepting minor shipment delays.

Exploit (EESA)

Positive (Opportunity)

Use when you want to ensure the opportunity happens.

Assign extra resources or modify plans to guarantee success.

Adding a dedicated team to secure a key client deal.

Enhance (EESA)

Positive (Opportunity)

Use when you want to increase the likelihood or impact of an opportunity.

Improve processes, add resources, or optimize schedules.

Offering early delivery discounts to attract more customers.

Share (EESA)

Positive (Opportunity)

Use when the opportunity can be maximized by partnering with others.

Collaborate with another organization or stakeholder.

Partnering with a vendor to co-develop a product.

NPV
(Net Present Value)

Measures the value added by the project today, considering the time value of money.

- NPV > 0 → Accept ✅
- NPV < 0 → Reject ❌

Choose the project with the highest positive NPV.

- Considers time value of money
- Shows actual monetary value added

- Sensitive to discount rate
- Requires cashflow estimates

IRR
(Internal Rate of Return)

The discount rate at which NPV = 0; represents the project’s expected annual return.

- IRR > Cost of Capital → Accept ✅
- IRR < Cost of Capital → Reject ❌

Choose the project with the highest IRR if risks are similar.

- Easy to interpret as a % return
- Useful for ranking projects

- Complex to calculate
- Misleading when projects have non-normal cashflows

ROI
(Return on Investment)

Measures the profitability percentage relative to investment cost.

Higher ROI = Better project ✅

Use when comparing profitability quickly; not as robust as NPV/IRR.

- Simple to calculate
- Intuitive for stakeholders

- Ignores time value of money
- Can be misleading if project duration differs

Payback Period

Time required to recover the initial investment.

Shorter Payback Period = Better ✅

Use for risk-sensitive projects or when liquidity is critical.

- Simple and quick
- Good for risk analysis

- Ignores time value of money
- Ignores benefits after payback

Predictive (Waterfall)

- Clear, stable requirements- Compliance/regulatory projects- Construction, manufacturing

- Detailed planning upfront- Easy to track progress vs. plan- Works well with fixed scope & budget

- Inflexible to change- Risk of late discovery of issues- Customer sees product late

Iterative

- Scope is evolving but you want early feedback on partial solutions- R&D, prototyping

- Early delivery of working versions- Stakeholder feedback guides improvements

- More planning effort- Can feel slow if increments don’t add much value

Incremental

- When you can deliver value in usable pieces (modules, features)- Software product rollouts

- Value delivered early- Reduces risk by smaller releases

- Integration challenges- May need strong release management

Agile

- Requirements are uncertain or changing- High stakeholder involvement- Innovation-driven environments

- Very flexible- Frequent customer feedback- Prioritizes high-value features

- Needs mature, engaged team- Less effective with fixed contracts/budgets- Harder in regulated environments

Hybrid

- Large, complex projects where some parts are predictable and others are adaptive- Digital transformation, public works with IT component

- Balances stability and flexibility- Tailors to different workstreams

- More complex governance- Requires strong coordination between predictive and agile tracks

Scope

Fixed

Evolving

Cost/Schedule

Fixed baseline

Flexible, iterative

Change Mgmt

Formal CR process

Welcomed & integrated

Role of PM

Directs, controls

Facilitator, servant leader

Documentation

Heavy

Just enough

Delivery

End of project

Incremental

Product Owner (PO)

- Owns product vision & roadmap- Manages backlog (ordering/prioritizing)- Ensures value delivery to stakeholders

- What features to build- Priority of work- Accept/reject increments

- How the team delivers- Technical decisions- People management

Scrum Master (SM)

- Servant-leader- Coaches Agile practices- Removes impediments- Facilitates ceremonies

- Team process improvements- How Agile ceremonies are run

- Product scope or priorities- Technical implementation

Agile Team (Developers/Testers/Designers)

- Self-organize to deliver increments- Estimate work- Commit to sprint goals- Ensure quality (DoD)

- How to build the solution- Technical choices- Work estimates

- What features to build- Final say on priorities

Project Manager (in Hybrid/Scaled Agile)

- Aligns Agile work with organizational strategy- Manages stakeholders outside the team- Ensures governance, budget, reporting

- Governance & compliance- Integrating Agile outputs with larger program/portfolio

- Daily team decisions- Detailed backlog management

Definition of Ready (DoR)

A checklist of conditions that a backlog item must meet before the team can pull it into a sprint.

Ensures items are clear, small, and testable before committing. Prevents half-baked work entering the sprint.

- User story well-written (INVEST)- Acceptance criteria defined- Dependencies identified- Story estimated- Business value understood

Definition of Done (DoD)

A shared understanding of what “complete” means for work delivered by the team.

Ensures increments are truly finished, potentially shippable, and meet quality standards.

- Code completed & peer reviewed- Unit & acceptance tests passed- Integrated into main branch- No critical defects open- Documentation updated

Resource Leveling

Adjusts start/finish dates based on resource availability (no one is overallocated). May extend schedule.

Balances resource usage.

- Prevents burnout- Realistic plan

- Can delay project- May change critical path

Resource Smoothing

Adjusts activities within available float only → project end date does not change.

Optimizes resource usage without delaying project.

- Keeps end date fixed- Reduces peaks in resource demand

- Less flexible- Only possible if float exists

Crashing

Add extra resources (people, overtime, money) to critical path activities to shorten schedule.

To finish project sooner.

- Shortens schedule- Keeps sequence same

- Increases cost- May cause inefficiency

Fast Tracking

Perform activities in parallel that were originally sequential.

To finish earlier without adding cost.

- No direct cost increase- Can save significant time

- Increases risk- May cause rework

Scatter Diagram

To check if there’s a correlation between two variables (e.g., defect rate vs. temperature).

- Simple visual correlation- Helps identify cause–effect hypotheses

- Doesn’t prove causation- Hard to interpret with many variables

Affinity Diagram

To organize ideas/issues after brainstorming or collecting customer feedback.

- Groups complex ideas clearly- Great for root cause exploration

- Subjective grouping- Doesn’t quantify importance

Control Chart

To monitor process stability over time and check if a process is “in control.”

- Identifies common vs. special cause variation- Helps avoid over-adjusting processes

- Requires data collection over time- Can be misread if limits aren’t set correctly

Histogram

To see the distribution or frequency of defects or measurements.

- Easy to interpret- Highlights most frequent problems

- No info on sequence or time- Doesn’t show relationships between causes

Pareto Chart (80/20 rule)

To identify the vital few causes that contribute to most problems.

- Prioritizes issues by impact- Focuses efforts on what matters most

- Oversimplifies (not all problems fit 80/20)- Needs accurate data collection

Fishbone (Ishikawa) Diagram

To analyze root causes of a problem across categories (Machines, Methods, Materials, People).

- Structured brainstorming- Reveals multiple root causes

- Qualitative, not quantitative- Needs follow-up data to confirm causes

Test-Driven Development (TDD)

When you want high code quality and fast defect detection. Write tests first, then code to pass them.

- Forces clear requirements - Prevents over-coding - Reduces bugs early

- Requires skilled devs - Slows initial development

Behavior-Driven Development (BDD)

When you want business + technical alignment. Uses natural language scenarios (Given–When–Then).

- Improves communication with non-tech stakeholders - Ensures features meet business needs

- Needs strong collaboration - Can be time-consuming

Acceptance Test-Driven Development (ATDD)

When you want to ensure requirements are validated before coding begins. Acceptance criteria drive the development.

- Builds shared understanding between PO, testers, and devs - Ensures features meet agreed expectations - Reduces rework

- Needs clear, upfront acceptance criteria - Can delay start if PO is not engaged

Continuous Integration (CI)

When multiple devs commit code frequently. Builds and tests automatically.

- Detects integration errors quickly - Encourages frequent commits - Supports Agile delivery pace

- Needs automation setup - Fails if tests aren’t comprehensive

Pair Programming

When you want knowledge sharing and fewer errors. Two devs work at one workstation.

- Higher code quality - Cross-training - Real-time review

- More effort/cost upfront - Can slow down if pairs don’t collaborate well

Automated Regression Testing

When frequent changes risk breaking existing features.

- Saves time in long run - Catches recurring defects <

Q30

~35 minutes

~185 minutes

If you’re slower, speed up a bit.

Q60

~75 minutes

~155 minutes

Break 1 checkpoint.

Q90

~115 minutes

~115 minutes

Halfway in time and questions.

Q120

~150 minutes

~80 minutes

Break 2 checkpoint.

Q150

~190 minutes

~40 minutes

Final stretch – keep pace.

Q180

~225 minutes

~5 minutes

Buffer for review / flagged Qs.