🧭 Overview
🧠 One-sentence thesis
Project planning transforms approved projects into executable roadmaps by defining work, estimating resources, scheduling tasks, budgeting costs, and preparing strategies to manage risks, quality, procurement, stakeholders, and communication.
📌 Key points (3–5)
- Planning follows initiation: After approval and team appointment, planning creates the guides for execution, monitoring, and closure phases.
- Core planning trilogy: Work identification (scope/WBS), schedule development (sequencing and critical path), and cost estimation form the foundation.
- Methodology shapes planning: Predictive (waterfall) defines everything upfront; adaptive (agile) plans iteratively through sprints and product backlogs.
- Common confusion—scope creep vs. planned change: Unintentional scope expansion (scope creep) harms predictive projects; formal change analysis protects timeline/budget commitments.
- Why planning matters: Educated guesses about staff, resources, and equipment enable teams to deliver on time, within budget, and meeting quality expectations.
🎯 What planning delivers
🎯 The planning phase outputs
After initiation, the project leader collaborates with sponsors to identify the work for the project or iteration. The planning phase produces:
- Work breakdown structure (WBS): Visual decomposition of deliverables into manageable components (work packages in predictive; sprints in agile).
- Project schedule: Documents timeframes, dependencies, and resources; uses critical path to determine earliest completion date.
- Budget: Cost estimates for labour, equipment, and materials; monitored during implementation and closure.
- Risk management plan: Identifies threats and opportunities with response actions to optimize success likelihood.
- Quality management plan: Defines quality targets, assurance, and control measures plus acceptance criteria.
- Procurement management plan: Identifies vendor types and selection criteria for external products/services.
- Communication plan: Ensures stakeholders remain informed and supportive (project leaders spend ~90% of time communicating).
🔄 Methodology determines planning approach
| Aspect | Predictive (Waterfall) | Adaptive (Agile) |
|---|
| When scope is defined | Upfront, full project scope | Iteratively, sprint by sprint |
| Requirements | Completed before development | Developed in cycles (epics → user stories) |
| Budget/schedule | Detailed estimates at start | ROM refined per iteration |
| Change management | Formal change control critical | Flexible, adjustments per sprint |
Don't confuse: Choosing the wrong methodology causes problems—if the outcome is unclear but you use predictive, scope will remain fluid while stakeholders expect fixed timelines/budgets.
📐 Tailoring and integration
- Project plan creation: Comprehensive plans are created for medium-to-high complexity projects; rarely for low complexity.
- Integration management: The project leader integrates all subsidiary plans (schedule, budget, risk, quality, etc.) to ensure cohesion and alignment.
- Tailoring: Determining the need for formal plans is part of tailoring work done at each project's outset.
📋 Requirements elicitation
📋 What requirements describe
Requirements: Characteristics of the final outcome (product, service, or result) that describe functionality and specific conditions to meet project objectives.
- Project requirements describe what the project accomplishes and the organizational transformation (current "as-is" to future "to-be" state).
- Solution requirements describe how the end-user community expects the solution to function.
- Without clear project requirements, teams cannot deliver organizational value.
🔍 Three types of requirements
🔍 End-user (functional) requirements
- Focus on user experience: what users want the solution to do and how it should perform.
- Written as user stories describing valued features.
- Help narrow design alternatives and identify quality expectations.
- Example: A user wants to access financial data remotely.
🔍 Technical requirements
- Specify how the system must be designed/implemented to provide functionality and fulfill quality.
- Emerge from understanding end-user requirements.
- Example: For remote financial data access, technical requirements specify database elements, programming language, hardware, telecommunication protocols, backup power for 95% uptime.
🔍 Regulatory/industry-specific requirements
- Rules mandated by government (e.g., privacy laws protecting confidential client information).
- Very industry-specific; compliance is mandatory.
🛠️ Elicitation techniques
Document review:
- Process flows, policies/procedures, problem logs, user cases/stories.
Direct consultation with end-users:
- Interviews, focus groups, facilitated sessions.
- Group creativity: brainstorming, mind-mapping.
- Observation of clients/customers/end-users.
- Surveys and questionnaires.
- Group decision-making: consensus, majority voting, dictatorship (sponsor decides).
Prototyping (adaptive approaches):
- Stakeholders experiment with an evolving model.
- Helps articulate needs when verbal/written descriptions are difficult.
- Allows realistic measurement of functionality/performance; prototype is refined based on feedback.
📊 Requirements traceability matrix
A tracking tool that links requirements to objectives, design, development, and testing.
Benefits:
- Supports prioritization by linking value to effort ("must have" vs. "nice to have").
- Supports stakeholder management by tracking requirement sources.
- Tracks status (design consideration, delivery completion).
- Provides structure for managing scope changes.
Includes:
- Requirements → organizational value/objectives.
- High-level → detailed requirements.
- Requirements → WBS, design, development, test strategy.
- Attributes: unique ID, description, rationale, owner, source, priority, version, status, date completed, acceptance criteria.
Sign-off: Stakeholders confirm needs are accurately recorded; requirements are incorporated into project/iteration plans.
Don't confuse: Requirements are not "nice-to-have wish lists"—they must be measurable, testable, and tied to organizational needs.
🗂️ Scope management
🗂️ Defining scope
During initiation, scope is broadly defined (especially in high-complexity projects). Planning refines scope by identifying deliverables.
Deliverables: Tangible outcomes (project management deliverables + product/service/result deliverables) that must be produced for project/iteration completion.
Scope statement denotes what work will be done (other plans denote how).
| Methodology | Scope approach |
|---|
| Predictive | Full project scope statement created upfront; development team designs/develops entire solution |
| Adaptive | Product backlog = total scope; prioritized into small sprints (few weeks each); scope adjusts as team learns |
⚠️ Scope creep
Scope creep: Unintentional expansion of project scope.
Causes:
- Poorly defined scope at onset (poor statement, lack of stakeholder input/approval).
- Wrong methodology chosen (predictive when outcome is unclear).
- Stakeholders preserve timeline/budget commitments while scope remains fluid.
How to manage: Analyze and formally approve scope changes (vs. automatic/unintentional pursuit). Communicate impact on timeline, budget, quality (triple constraints) so stakeholders make effective priority decisions.
Don't confuse: Scope should not never change—the key is how it changes (formal analysis and approval vs. chaotic drift).
🌳 Work breakdown structure (WBS)
WBS: Visual depiction of work (scope) broken into smaller, more manageable components.
Predictive (deliverable-oriented or phase-oriented):
- Hierarchy: Project → Major deliverables → Sub-deliverables → Work packages (lowest level).
- Example phases: Initiation, Planning, Development, Testing, Rollout, Closure.
Adaptive (agile):
- Hierarchy: Project (epic) → Capabilities → Features/Enablers → User stories → Sprints (tasks).
Key principle: WBS defines what needs to be done, not how (the "how" is developed by work package leaders using schedules/budgets).
Formats:
- Graphical (boxes in cascading hierarchy).
- List format (indented outline with intelligent numbering, e.g., 1.0, 1.1, 2.1.1).
Intelligent numbering: Numbering system has meaning (e.g., all packing activities begin with "3").
Unique identifiers: Numbers track costs, durations, resources; linked to organization's chart of accounts; referenced in schedules/budgets.
Work packages/sprints:
- Assignable to a team with clear accountability.
- Team leaders collaborate with stakeholders to: confirm involvement, identify tasks, create detailed schedule (resources, durations, sequencing, monitoring points), identify costs, identify assumptions/risks/issues.
- Project leader compiles all work into integrated project plans.
Example: In John's move, major deliverable "3. Packing" breaks down into 3.1 (confirm help), 3.2 (pick up supplies), 3.3 (pack apartment), which further breaks into 3.3.1 (kitchen), 3.3.2 (living room), 3.3.3 (bedroom with sub-tasks 3.3.3.1 closet, 3.3.3.2 drawers, 3.3.3.3 blankets).
👥 Resource management
👥 What resources are
Resources: People, equipment, space, money, and anything else needed to produce deliverables.
Two types of team members:
- Functional participants: Business owners, subject matter experts (SMEs) who ensure the team understands solution requirements.
- Process participants: Experts in estimating, cost tracking, planning, scheduling.
Staffing considerations:
- Exact start/end dates negotiated to meet individual and project needs.
- Core team: Project management team + key functional experts; provide continuity and "corporate memory."
- Staffing varies by phase (early conceptual members often not needed in closeout).
- External resources acquired when internal expertise is lacking or to temporarily replace internal staff assigned to the project.
📅 Resource planning
- Each task requires assigned resources.
- Determine resource availability before assignment (external consultants, training rooms must be scheduled in advance).
- Match requirements with availability through negotiation with functional managers.
- Software applications simplify resource management.
📆 Schedule management
📆 Schedule development goals
Effective schedule management is integral to project success. The objective: create a schedule that uses allocated resources efficiently to complete the project in the shortest time possible.
Critical path: Technique to determine the earliest completion date for a project/iteration.
Stakeholder communication:
- Confirm if the calculated completion date meets sponsor expectations.
- Keep stakeholders updated on delays deviating from the agreed schedule.
- If completion is needed sooner, examine critical path tasks (change resource assignments, complete more tasks in parallel).
- If completion is sooner than expected, extra contingency (buffer) increases on-time delivery likelihood.
🧩 Defining and sequencing tasks
🧩 Task identification
- Review project scope (scope statement for predictive; product backlog for agile).
- Use WBS as a visual guide.
- Work package leaders/scrum masters identify specific tasks and estimate durations.
🧩 Sequencing
Sequencing: Defines the order in which tasks must be completed.
Tools:
- Network diagrams: Graphically depict which tasks must be completed before others and which can be done in parallel (similar to flowcharts).
- Software (MS Project) or low-tech (digital whiteboards, sticky notes).
Information sources:
- Project repository: Examples of task lists, sequencing, duration estimates from past similar projects.
- Expert judgment: Knowledge of team members with prior experience; experts review/improve draft task lists.
Integration: Work package leader/scrum master schedules are given to the project leader, who develops an integrated project schedule.
📏 Estimating resources and durations
📏 Resource estimating techniques
- Expert judgment: Input from experts with similar project experience.
- Alternative analysis: Examine several options for resource assignment (number and kind of resources).
- Published estimating data: Analyze data from articles, books, journals, others' projects.
- Project management software: Programs (e.g., MS Project) estimate needs, constraints, and optimal assignments.
📏 Duration estimating approaches
Top-down (±50% accuracy):
- High-level estimates; simple and inexpensive.
- Used at project selection stage and for small internal projects.
- Techniques:
- Apportion method: Apply proportions from similar past projects (e.g., if a past 1-year project had deliverables taking 25%, 50%, 25% of time, apply same percentages to current project).
- Expert judgment: Settle on high-level estimate based on expert input.
- Ratio method: Apply significant determining factor (e.g., 20-page website × 5 days/page = 100 days).
Bottom-up (±30% accuracy):
- Task-level estimates based on specific task information and assigned resources.
- Used when accuracy is a priority (e.g., inflexible launch deadline).
- Takes considerable time.
- Techniques:
- WBS method: Estimate task durations within work packages/iterations; roll up to major deliverable/project level.
- Parametric estimating: Use formula/spreadsheet/program that extrapolates from database of past project durations.
- Three-point estimates: Average of realistic (most likely), optimistic (best-case), and pessimistic (worst-case) scenarios.
Duration unit: Typically working days (could be hours, weeks, months); chosen based on detail needed; used consistently.
Effort vs. duration:
- Effort: Time spent on the task (excludes wait time).
- Duration: Includes effort + wait time (e.g., approval delays).
- Example: John packs clothes in 2 hours, friends move boxes the next day in 15 minutes → duration = 2 days; effort = 2 hours 15 minutes.
- Duration is for scheduling; effort is for budgeting (labour costs).
📏 Factors impacting estimate accuracy
- Planning horizon: Distant-future tasks are harder to estimate (unpredictable).
- Project complexity: More complex work = harder to estimate accurately.
- People: Skill/experience of estimators matters; similar past project experience improves accuracy.
- Project structure: Dedicated teams produce most accurate estimates (vs. functional environments where members balance project + day-to-day work).
- Human tendency to pad: Overestimating to increase success likelihood; better to add contingencies at project level based on risk.
- Organizational culture: Value placed on accuracy affects accuracy level (high-level vs. meticulous).
- Other factors: Equipment downtime, staff illness (unpredictable); vacation periods (more predictable, should be considered).
📅 Resource calendars and leveling
📅 Resource calendars
Resource calendar: Indicates each resource's availability.
- Company calendar: Tracks working days, weekends, holidays.
- Individual calendars: Show vacation/personal days.
- Equipment calendars: Show availability periods for major equipment.
Application: When a 3-day activity starts Thursday and the resource has weekends off, it ends Monday. If Monday is a holiday (e.g., Labour Day), it ends Tuesday.
📅 Resource leveling
Resource leveling: Examining unbalanced resource use over time and resolving over-allocations/conflicts.
- When resources are needed more than available, tasks are rescheduled sequentially.
- Can balance workload of primary resources over the project.
- Often impacts timeline, budget, and/or scope (triple constraints).
- In project software (MS Project), leveling delays tasks until resources are available.
- In complex environments, leveling may be performed at company level (across multiple concurrent projects).
- Can result in later completion date if affected tasks are on the critical path.
🔗 Task relationships and dependencies
🔗 Predecessors and successors
Predecessor: Activity that comes before.
Successor: Activity that comes after.
Dependency: Relationship between predecessor and successor (successor is dependent on predecessor).
Natural dependency: Successor can only occur once predecessor is completed (e.g., conversation with friends before scheduling a meeting).
Finish-start relationship: Most common; first activity must finish before next can start (activities occur sequentially).
Concurrent activities: Occur at the same time.
- Start-start: Must start at the same time.
- Finish-finish: Can start at different times but must finish at the same time.
Example: In John's move, "Contact Dion and Carlita" (1.1) is predecessor to "Planning Lunch" (1.2); conversation provides availability and confirms commitment.
🔗 Network diagrams
Precedence diagram method (PDM): Graphically displays sequence logic by placing activities in boxes (nodes) with arrows showing finish-start relationships.
- Easier to trace sequential paths.
- Illustrates predecessor-successor relationships visually.
🔗 Lag and lead times
Lag time: Required delay before successor task can begin.
Example: Concrete must harden for several days after pouring before construction continues; cheques must clear before money is spent.
Lead time: Successor task overlaps the end of predecessor and begins before predecessor finishes.
Example: John sets aside small/delicate items (1 day) before gathering packing materials; when materials arrive, packing is already partially done, shortening total time by 1 day.
Task attributes: Identifying code, description, predecessors, lead/lag times (easily displayed in scheduling software).
🏁 Milestones and critical path
🏁 Milestones
Milestones: Significant events in a project; consume no resources and have no duration.
- Represent major constraints (e.g., government contract must be signed by specific date for funding eligibility).
- Indicated on schedules with a diamond symbol.
Example: In John's move, "Accept job offer in Atlanta" is a milestone; any delay delays the project start and all downstream activities.
🏁 Critical path
Critical path: The longest series of activities resulting in the earliest completion date of the project/phase/iteration.
- Any delay on the critical path delays the completion date by an equal amount.
- Contains tasks with greatest total duration and least slack.
- To determine: Add duration of each successor to previous activity; series with longest total duration is the critical path.
- Tasks on the critical path receive needed resources and support to stay on track.
Example: In John's move, the critical path takes 8 days; the Gantt chart shows project duration is also 8 days (driven by critical path).
🏁 Float (slack)
Float (slack): Amount of time a task/path/phase can be delayed from early start without changing the completion date of its successor(s) or project.
Total float: Difference between finish date of last critical path task and stakeholder-expected completion date.
- Negative float: Calculated completion is later than expected completion.
Example: In John's move, last critical path task (5.4 unpack/assemble) completes May 25; John starts work June 1 → total float = 6 days (buffer). If a critical path task is delayed a few days, John still starts on time.
🔧 Ongoing schedule management
Approval and baseline:
- Schedule approved/signed off by key stakeholders (especially functional managers providing SMEs).
- Approval ensures stakeholders understand dates, resource commitments, and will support resource needs.
- Approved schedule becomes the baseline; progress is monitored against it.
Revising estimates:
- Estimates are just estimates; new information may require revisions.
- Minor revisions may not impact milestones/completion date.
- Significant revisions may require calculating a new baseline.
- Discuss expectations with stakeholders about when/how to inform them of changes.
- High-complexity projects: document in formal schedule management plan.
- Low-complexity projects: document in stakeholder register.
Schedule compression techniques:
- Crashing: Add more resources to critical path tasks or reassign from non-critical tasks; can be expensive and doesn't always work; not effective if budget is limited.
- Fast-tracking: Two tasks originally planned sequentially occur concurrently (start-start, finish-finish); risky—work may need redoing if issues arise that would have been identifiable in sequential execution.
📊 Gantt charts
Gantt chart (bar chart): Time-scaled graphic representing each task with a bar reflecting its duration, start, and finish time.
- Developed by Henry Gantt; used on major projects (Hoover Dam, U.S. interstate highway system).
- Relationships between activities are easier to recognize graphically.
💰 Cost management
💰 Cost management goals
Completing the project within budget is a component of success. Developing and controlling a budget to accomplish objectives is a critical skill.
Budget flexibility varies:
- Some projects prioritize completion date (flexible budget to meet inflexible deadline).
- Others have limited funding (budget is highest priority; trade-offs with scope, quality, time may be required).
💰 Cost estimation evolution
Project selection phase:
- Rough order of magnitude (ROM): Developed using available information, expert knowledge, past experience.
- Past project estimates scaled to match current project size/complexity.
- ROM is not accurate but helps determine if project should be approved.
Initiation phase:
- Project leader refines ROM if more information is available.
- If solution cannot be clearly defined, cost estimates remain vaguely defined.
Planning phase:
- Development methodology determines how budget is created.
| Methodology | Budget approach |
|---|
| Adaptive (agile) | Loosely defined ROM; focus on iteration (sprint) costs to refine total project cost; budget developed collaboratively with product owner(s) and scrum master(s) |
| Predictive (waterfall) | End outcome is clear; broken into work packages; work package leaders estimate costs; integrated into detailed project budget |
Monitoring and control phase (Chapter 7):
- Actual costs tracked and compared to approved estimates.
- Significant variances explored; appropriate action taken to manage future costs.
💰 Why costs deviate
- Actual marketplace prices differ from expectations.
- Project performance (more materials required than expected).
- Effort differs from initial estimate.
- Trends of consistent over/underestimating require revised future estimates and corrective action.
Revising estimates:
- Effective project leaders revise as new information becomes available.
- Assess overall impact on objectives.
- Stakeholders expect to be kept informed of significant changes.
- Most organizations require approval for changes to existing estimates.
- Cost management plan (very large complex projects): Identifies who provides approval; guides when/how to communicate changes; establishes approval thresholds (e.g., project leader discretion for ≤2% of budget; sponsor approval for >2%).
💰 Types of project costs
- Direct costs: Directly related to specific tasks (labour, time, materials for specific tasks).
- Direct overhead costs: Incurred due to project's existence but not tied to specific tasks (project leader/support staff compensation; materials, facilities, equipment for project in general; workspace rental, computers, IT, supplies, lunch).
- General administrative costs: Indirectly related; incurred even if project is not carried out (marketing, HR, accounting department expenses); may provide ad-hoc minimal support; portion of costs may be allocated to all projects (provides full cost picture); allocation methods are subjective; many organizations exclude from project budget (time to reach consensus may not be worth the benefit).
Exception: If administrative functions are directly involved (e.g., HR re-evaluates job descriptions for new technology project), they are a work package and costs are direct costs.
💰 Estimation techniques
Top-down (±50% accuracy):
- High-level estimates; simple and inexpensive.
- Used at project selection stage and for small internal projects.
- Techniques:
- Apportion method: Review actual costs from similar projects; apply same proportions (e.g., past $500,000 project had deliverables costing 20%, 10%, 10%, 40%, 30%; apply same percentages to current project).
- Expert judgment: Consult experts with similar work experience to settle on high-level estimate.
- Ratio method: Identify significant determining factor (e.g., 20-page website × $1,000/page = $20,000).
Bottom-up (±30% accuracy):
- Used when accuracy is valued (high priority on project cost; fixed budget).
- Takes considerable time.
- Techniques:
- WBS method: Estimate task costs within work packages/iterations; roll up to work package/iteration level; roll up to major deliverable/capability level; roll up to project level.
- Parametric estimating: Enter data into formula/spreadsheet/database/program based on database of actual costs from past projects.
- Three-point estimates: Average of realistic (most likely), optimistic (best-case), and pessimistic (worst-case) scenarios.
Level of detail: Determined by project complexity (large complex projects need more coordination). Clarity of end outcome affects detail achievable at project start (predictive: detailed estimates from onset; agile: detailed estimates only as user requirements become clear).
💰 Additional cost considerations
Labour costs: Often the largest cost component; estimate labour rates (may require market analysis).
Vendor bid analysis:
- RFQ (Request for Quotation): Used when team knows required solution but cannot provide it internally.
- RFP (Request for Proposal): Used when team does not know required solution; requests proposals from organizations with relevant expertise.
- Bids must be analyzed and evaluated to determine best for project.
Cost of quality: Often overlooked; includes error-proofing solutions, creating checklists, inspecting deliverables before stakeholder review/sign-off. Cheaper to identify flaws early than later; always quality costs associated with everything produced.
Reserve analysis: Set aside money for cost overruns; higher-risk projects require more reserve.
Two types of reserves:
- Contingency reserves: Funds for identified risks; incorporated into project budget; if adequate, project completes within budget.
- Management reserves: Funds for unanticipated situations (positive or negative); example: new technology discovery (positive); available at project sponsor's discretion; may result in significant scope change (especially in predictive); unlikely to be spent; not part of cost baseline but may be included in funding.
Documentation: Document assumptions and supporting information sources; makes it easier to analyze variances and revise projections.
Example: In John's move, apportion estimate based on friend's move ($600 total: 60% truck, 25% gas, 10% hand truck, 2% pads, 2% boxes, 1% rope); John sets initial estimate at $700 for rising gas prices and apportions accordingly ($426 truck, $183 gas, $61 hand truck, $12 pads, $12 boxes, $6 rope).
Parametric estimate: Truck rental company uses number of bedrooms as parameter (John has 1-bedroom → 14-foot truck); other parameters (distance, days) estimate truck rental cost.
Bottom-up estimate: John looks up prices for packing materials and truck rental; detailed list of items, quantities, costs; sum = $661.25; can be rolled up (subtotaled) for less detail; easier with computer software (spreadsheet for low complexity; MS Project for high complexity, which manages schedules and costs, sortable by activity and category).
💰 Cost budgeting and baseline
Goal: Produce a cost baseline (time-phased budget to measure and monitor cost performance after stakeholder approval).
Process:
- Aggregated budget integrated with project schedule → time-phased budget.
- Costs associated with tasks; each task has start date and duration → calculate money spent by any date.
- Not all money needed upfront → manage cash flow needs effectively.
- For smaller organizations with cash flow challenges: transfer money to project account shortly before needed (timed so money is there without delaying task start).
- If transferred too early: lose opportunity to use money elsewhere or pay unnecessary interest (if borrowed).
Managing the budget:
- Baseline budgets often change after approval.
- Estimates are just estimates; new information/experience may require revisions.
- Minor revisions may not impact total budget.
- Significant revisions may require new baseline.
- Discuss expectations with stakeholders about when/how to inform them of changes.
- Very large complex projects: document in formal Cost Management Plan.
- Tools and techniques help project leaders monitor and control budgets.
⚠️ Risk and issue management
⚠️ What risks are
Risks: Uncertainties that exist in all projects; can be positive or negative.
- Opportunity: Positive risk (e.g., finding an easier way to do a task, lower material prices).
- Negative risk: Examples include technology failure, vendor missing delivery.
Project team role: Understand types and severity of risks; develop and implement response plans.
Risk variation: Type and severity vary by industry, project complexity, and project phase.
Human tolerance: Risk tolerance varies significantly; can be difficult for team members to reach consensus on riskiness; understanding stakeholder risk tolerance is a critical success factor.
⚠️ Four steps in risk management
-
Identifying uncertainties: Some easy (e.g., damaging storm in Caribbean), others less obvious (e.g., poor team health). Industry/company risk checklists from past experience stimulate discussion.
-
Assessing each risk: Estimate likelihood (probability) and impact on project goals. Outcome: prioritized list with values (high, medium, low) for likelihood and impact. Probability/impact matrix is a key tool.
-
Developing risk responses: Accept (do nothing), eliminate (change project to avoid), transfer (to third party via insurance), or mitigate (reduce likelihood/impact).
-
Implementing and monitoring response: Balance cost of response against anticipated benefit. Monitoring is important because new risks emerge; understanding effectiveness of response strategies ensures risks are managed throughout lifecycle.
⚠️ Risk management plan
Risk management plan: Allows team to reduce likelihood of negative surprises, proactively take advantage of opportunities, and ensure risk management is considered in schedules, budgets, and other plans.
Creating and maintaining a risk management plan significantly increases project success likelihood.
Includes:
- Risk sources, categories, assessment definitions (very high to very low).
- Probability/impact assessment (matrix).
- Roles and responsibilities.
- Budget and schedule estimates for risk-related activities.
- Risk register.
Integration: Integrated into project management plan (or execution approach); response strategies assigned to appropriate individuals.
Risk register: Key tool to track risk status, ensure response plans are implemented, and manage new risks; created during initiation, maintained throughout remaining phases.
⚠️ Risk identification sources
Assumptions: Start with assumptions made in project justification document and charter; assumptions represent significant risks (hope they materialize, but not certain).
Project team: Individuals responsible for specific work are best positioned to identify risks/opportunities; risk management should be standing agenda item in status meetings.
Risk checklists: Developed from past projects; helpful in identifying specific risks and expanding thinking. Industry-published checklists should be utilized when feasible.
Common risk categories:
- Technical (technology and equipment).
- Cost (labour and non-labour estimates).
- Schedule (activity durations, work completion methods).
- Client/Customer (willingness to use new product/service).
- Procurement (vendor performance).
- Weather (adverse weather impeding progress).
- Financial (funding sources).
- Environmental (new/changing government regulations).
- Resources (skills, availability, teamwork effectiveness).
- Stakeholders (fulfilling expectations).
- Communications (effectiveness).
Risk breakdown structure (RBS): Risks categorized according to WBS deliverables.
Example: In John's move, he lists things that might go wrong using WBS as guide (e.g., for "Contact Dion and Carlita": Dion backs out, Carlita backs out, no common date available; for "Host planning lunch": restaurant full/closed, wrong ethnic food, food allergies/preferences).
Result: Clearer understanding of where risks are concentrated; helps identify known risks but may prevent creative identification of unknown risks not easily found in WBS.
⚠️ Risk assessment
Process: Project team evaluates each risk based on probability and potential impact (cost/benefit). Not all risks are equal (some more likely, impact varies greatly). Often done in workshop setting.
Criteria for high-impact risks: Narrow focus on critical few requiring responses.
- Example: High-impact = could increase project costs by ≥5%.
- High-probability = likelihood ≥50%.
- Few risks are both high-impact and high-probability → "critical few" → identify early to allocate funds and time.
Probability/impact matrix: Visual tool showing risks plotted by likelihood (y-axis) and impact (x-axis); high-high quadrant = critical risks.
Complexity correlation: Positive correlation between project complexity and risk (both increase/decrease together). High complexity (e.g., new/emerging technology) = high risk → assign appropriate resources to technology managers. More complex technology = more resources needed; each resource could face unexpected problems.
Complexity-based tracking:
- Low complexity: Informal tracking of risk potential.
- Medium complexity: List of higher risks tracked during reviews.
- High complexity: Formal risk assessment meetings throughout lifecycle; outside expert may be included; statistical models (e.g., Monte Carlo simulation) evaluate many risk combinations; output provides probability of risk event occurring with other combinations (e.g., 10% chance key equipment is late and weather is unusually bad).
⚠️ Risk responses to negative risks
After identification and assessment, develop appropriate responses. Balance cost of response against anticipated benefit.
Risk avoidance: Develop alternative strategy with higher success probability (usually higher cost).
- Example: Use proven/existing technologies vs. new techniques (even if new shows promise of better performance/lower costs); choose vendor with proven track record over new vendor with price incentives; drug testing for team members.
Risk mitigation: Response when risk cannot be avoided or avoidance is unwise (too expensive, too time-consuming).
- Reduce likelihood and impact.
- Example: Assign highly skilled resources to activity to reduce likelihood/impact of errors.
Risk transfer: Shift risk from project to another party.
- Example: Purchase insurance (e.g., Caribbean construction project buys hurricane insurance covering damage).
- Usually for risks that can significantly impact project but are out of team's control (weather, political unrest, labour strikes).
Risk acceptance: Do nothing in response.
- Good when likelihood and impact are low.
- Sometimes little else can be done (acceptance is only feasible option).
- Many project leaders develop strategy to deal with risk if it materializes (often involves setting aside contingency reserves in budget).
⚠️ Risk responses to positive risks (opportunities)
Risk-sharing: Partner with others to share responsibility.
- Advantageous when other company has expertise/experience the team lacks.
- Increases likelihood of opportunity materializing; both organizations share gains.
Risk exploitation: Eliminate uncertainty and ensure occurrence.
- Example: Pursue bonus available only if activity is completed early; reallocate resources to ensure early finish and obtain bonus.
Risk enhancement: Increase probability of opportunity materializing but do not ensure occurrence.
- Requires less investment than exploitation.
- Appropriate when positive impact is not as great.
Risk acceptance: Do nothing in response.
- Good when likelihood and impact are low.
⚠️ Risk by project phases
Initiation:
- Most unknowns at project beginning.
- Overall project risk weighed against potential benefit to decide if project should be chosen.
Example: In John's move, he identifies high-impact risks and rates likelihood (low to high):
- New employer changes mind after John gives notice (LOW).
- Current tenants don't move out in time (MEDIUM).
- Movers lose furniture (LOW).
- Movers >1 week late (MEDIUM).
- Accident driving, miss first day (LOW).
Responses:
- Mitigate by keeping relationships cordial, writing thank-you letters.
- Accept (research extended-stay motels) or mitigate (meet current tenants, offer dinner incentive).
- Transfer (check mover's insurance; take photos; seal/number boxes).
- Accept (use extended-stay research) or transfer (check if insurance covers late delivery).
- Mitigate (plan overnight motel stay to avoid driving tired).
John concludes risks can be effectively managed → proceeds.
Planning:
- Additional risks identified; initial risks considered in greater detail.
Example: John asks Dion and Carlita to identify risks during planning meeting; they focus on packing phase; fill out table with risks, impact, likelihood, mitigation plans (e.g., RA = risk avoidance, RS = risk sharing, RM = risk mitigation, RT = risk transfer).
Implementation and Monitoring/Control:
- As more information becomes available and tasks are performed without loss, overall project risk typically reduces.
- Risk management plan updated with new information; completed task risks checked off.
- Changes may arise from risk management strategies (e.g., John discovers rental van too small → sell/give away furniture to avoid failed move, reducing scope/complexity).
- Project timeline may need extension or budget may need increase (or reduction if opportunity discovered).
Understanding risk timing: Important for managing contingency funds. Most organizations finance projects from existing resources (various financial instruments); cost to keep funds (including contingency) available. As risks decrease over project length and contingency is not used, funds can be allocated elsewhere.
Closing:
- Conclude risk-sharing and risk transfer agreements.
- Examine risk management plan to ensure all risk events effectively managed.
- Final risk register update for future project teams.
- Identify how much contingency funds were required (helps future teams set aside appropriate funds).
- If Monte Carlo simulation was done, compare predicted to realized result.
Example: John examines risks and response strategies; adds column to risk register for closeout activities.
Risk timing variation: Risk is not evenly allocated over project life.
- High new technology: Majority of risks in early phases.
- Large equipment budget: Majority during procurement.
- Global projects with political risk: Majority toward implementation and closure.
⚠️ Contingency plan
Contingency funds: Set aside to address unforeseen events causing cost increases.
- High-risk profile projects have large contingency budget.
- Amount often a function of risks identified in risk analysis.
- Can be allocated to specific activities or managed as "one-line item" in budget (when risks are difficult to assign).
- Reviewed during project life to evaluate response effectiveness and need for additional contingency.
🛒 Procurement management
🛒 Procurement cycle overview
Procurement effort varies widely by project type.
Procurement cycle: All procurement-related activities from decision to outsource through payment of bills and closing of contracts.
Terminology: Suppliers and vendors are used interchangeably.
Less complex projects (project team performs):
- Identify required materials, equipment, supplies.
- Identify potential vendors.
- Prepare RFQs and RFPs (product/service specifications, detailed delivery schedule).
- Evaluate RFQs/RFPs to select suitable vendors.
- Award and sign contracts.
- Administer contract and monitor vendor performance.
- Manage contract changes.
- Close out contract upon work completion.
More complex projects: Procurement professionals assigned to assist throughout project lifetime.
Logical order: Determine what to contract → plan → send requirements to potential vendors → vendors bid → select best vendor → sign contract → monitor performance → close out contract.
🛒 Procurement management plan
Procurement management plan (high-complexity projects): Details how procurement process will be managed.
Includes:
- Roles and responsibilities (project team and procurement professionals).
- Vendor selection criteria and selection process.
- Identification of prequalified sellers (if known).
- Types of contracts and metrics for vendor performance.
- Requirements and specifications (products, services, equipment).
- Planned delivery dates.
- Company's standard documents.
- Number of vendors and how they will be managed.
- How purchasing may impact constraints/assumptions.
- Coordination of purchasing lead times with schedule development.
- Closing contracts.
Time/cost: Can take hours or weeks depending on complexity; activities included in project schedule and budget; procurement cycle time influences scheduling of critical activities and decision to self-perform or contract; delivery dates and work completion dates placed on schedule; activities creating project delay or on critical path may require special attention.
Integration: Becomes subsidiary of project management plan.
🛒 Lease-or-buy analysis
Lease-or-buy analysis: Technique to determine if needed equipment should be purchased or leased.
Key questions:
- How long does the organization need equipment for the project?
- What will the organization do with equipment after project completion?
- How will this affect project scope?
- How will it affect project schedule?
- How will it affect stakeholders' quality expectations?
Example: 3-D printer costs $15,000 to purchase + $200/month maintenance; lease is $600/month (includes maintenance).
When does cost to buy = cost to lease?
- $600 × M = $15,000 + ($200 × M)
- ($600 – $200) × M = $15,000
- $400 × M = $15,000
- M = 37.5 months
Decision:
- Project considerably >37.5 months → buy (reassign to future projects or sell).
- Project considerably <37.5 months → lease.
- Project ≈37.5 months → judgment call (consult others about need for equipment in other areas).
After analysis, determine contractual relationship needed; identify potential vendors; move to bid solicitation; evaluate bids; award contract.
🛒 Qualifying bidders
Potential bidders: People/organizations capable of providing materials or performing outsourced work.
Smaller projects: Parent company has list of suppliers/vendors with performance records; project has access.
Unique projects: No supplier list exists; team develops list and qualifies bidders; eligible bidders placed on bidder's list and provided schedule of when work will be bid.
Eligibility criteria:
- Ability to perform: Meet quality specifications and project schedule. During high economic activity, suppliers become busy and stretch resources; investigate to ensure capacity and track record to meet deadlines/quality.
- Financial stability: Credit check or financial report from reputable agency (Dun and Bradstreet, Equifax) provides financial status information.
🛒 Solicitation
Solicitation: Process of requesting price and supporting information from bidders.
Request for Quotation (RFQ):
- Focuses on price.
- Product/service/materials are well-defined and available from several sources.
- Bidder meeting quality/schedule requirements usually wins by quoting lowest price.
Request for Proposal (RFP):
- Issued when team does not know required solution.
- Solicits ideas on how to fulfill project objective with specific solutions.
- Used in predictive and adaptive methodologies.
- Example: Streamline service process project needs new application + desktop computer upgrades; team doesn't know which computer is appropriate → issue RFP to three companies.
- Considers price but focuses on meeting objective by selecting appropriate solution.
- If several proposals successfully illustrate support for objective, price can become deciding factor.
- Developing proposal is time-consuming and expensive for bidder; team should not issue RFP to company not eligible to win.
Logistics:
- Equipment/materials must be transported, inventoried, warehoused, often secured.
- Can be managed within project team (if expertise and facilities exist), by organization's procurement department member (larger complex projects), or externally (if organization lacks skills/facilities; potentially part of RFP/RFQ process).
🛒 Evaluating bids
RFQs for commodity items (e.g., office supplies):
- Heavily weighted toward price.
- Often lowest total price wins (vendors already confirmed they meet specifications/delivery timelines).
- Total price includes: goods/services costs, shipping/delivery, warranty value, additional service adding value.
- Past performance considered (reference checks of existing/past clients) for non-commodity items (e.g., services).
RFPs:
- More complex evaluation.
- Includes price + evaluation of technical approach.
- Team evaluating proposal must include people with expertise to understand technical aspects and value of each approach.
- More complex projects: administrative part evaluated/scored by one team; technical aspect by another team; scores combined to determine best proposal.
- Often scores are not weighted equally.
- Weighted scoring model (Chapter 2) is effective decision-making tool for vendor selection.
🛒 Contract types
Objective: Select type creating fairest and most workable deal for both parties (project team/client and contractor/vendor).
🛒 Fixed-price contracts
Fixed-price contract: Legal agreement where vendor provides goods/services at agreed-on price regardless of time/effort.
- Vendor incorporates all costs (including profit) into price.
- Vendor assumes risks for unexpected increases in labour/materials.
- Contract details quality, timing, price.
- For commodities/goods/services with clear, unlikely-to-change scope: offers predictable cost.
- Responsibility for managing work to meet needs is on vendor.
- Project team tracks quality and schedule progress.
- Risk: Costs associated with project change. Change order from vendor is typically very high price.
- Requirements: Vendors with appropriate qualifications/performance histories; scope unlikely to change.
- Critical aspects: Clear scope based on good information, highly qualified bidders, clear contract reflecting scope.
- Challenge: Solutions developed iteratively (agile) are generally more challenging to manage with fixed-price contracts.
Variations:
-
Fixed-price with price adjustment: For unusually long projects (years); considers inflation-adjusted prices. In high-inflation countries, contract price adjusted accordingly. If adjustment determined upfront, project accepts risk actual inflation is lower; vendor risks actual inflation is higher. Volatility of commodities (e.g., oil) can also be accounted for.
-
Fixed-price with incentive fee: Provides incentive for performing better than stipulated (e.g., delivering ahead of schedule).
-
Fixed-unit-price: If service/materials measured in standard units but amount needed is not known accurately, price per unit is fixed. Project team estimates number of units. If estimate is inaccurate, contract doesn't need change but project will exceed budgeted cost.
| Type | Known Scope | Share of Risk | Incentive for Milestones | Predictability of Cost |
|---|
| Fixed total cost | Very High | All vendor | Low | Very high |
| Fixed unit price | High | Mostly project | Low | Medium |
| Fixed price with incentive fee | High | All vendor | High | Medium-high |
| Fixed fee with price adjustment | High | Depends on adjustment timing | Low | Medium |
🛒 Cost-reimbursable contracts
Cost-reimbursable (cost-plus) contracts: Organization pays vendor for cost of performing service/providing goods.
- Most often used when scope or costs are not well known.
- Vendor has much less risk associated with cost increases.
- When costs are not well known, reduces contingency bidders place in bids to account for risk.
- Different than fixed-price where vendors include as much contingency as possible to protect profit margin.
- Vendor less motivated to reduce project cost (no incentive; client reimburses costs even if unnecessarily high).
- Limit exorbitant costs: Include incentives for supporting project goal accomplishment.
- Require good documentation of costs to ensure vendor receives payment for all work and organization is not paying for incomplete work.
- Vendor guaranteed profit over and above cost reimbursement.
Ways to compensate vendor:
-
Cost-reimbursable with fixed fee: Vendor receives profit amount (fee) determined at contract beginning; does not change.
-
Cost-reimbursable with percentage fee: Vendor receives percentage of allowable costs as profit (e.g., 5% of total allowable costs). Fee changes as costs change.
-
Cost-reimbursable with incentive fee: Encourages performance in areas critical to project. Often attempts to motivate vendors to save/reduce costs. Example: Talent scout reimbursed for allowable costs + predetermined bonus for each musician signed at attractive price.
-
Cost-reimbursable with award fee: Reimburses vendor for allowable costs + fee based on performance criteria. Fee typically based on more subjective goals/objectives. Money set aside for vendor to earn through excellent performance; decision on how much to pay left to project team judgment; amount sufficient to motivate excellent performance. Example: Music producer reimbursed for allowable costs + award fee based on album rating.
| Type | Known Scope | Share of Risk | Incentive for Milestones | Predictability of Cost |
|---|
| CR with fixed fee | Medium | Mostly project | Low | Medium-high |
| CR with percentage fee | Medium | Mostly project | Low | Medium-high |
| CR with incentive fee | Medium | Mostly project | High | Medium |
| CR with award fee | Medium | Mostly project | High | Medium |
| Time and Materials | Low | All project | Low | Low |
Well-suited: Often well-suited to agile development methodology.
🛒 Time and materials (T&M) contracts
Time and materials contract: Client pays rate for time spent + cost of all materials used.
- For activities with high uncertainty, vendor charges hourly rate for labour + cost of materials + percentage of total costs.
- Vendor submits timesheets and receipts for items purchased.
- Project reimburses vendor for time at agreed rate + actual cost of materials.
- Fee (vendor's profit margin) typically percentage of total cost.
- Used for work smaller in scope with uncertainty/risk.
- Often well-suited to agile development methodology.
- Project (not vendor) assumes all risk.
- Challenge: Can be problematic if no limits to effort and materials applied.
Minimize risk: Vendor typically includes not-to-exceed amount (can only charge up to agreed amount).
Flexibility: Allows project to adjust contract as more information about end solution becomes available. Final cost not known until sufficient information available for accurate estimate.
🛒 Deciding on contract type
Considerations:
- Is required work/materials a commodity, customized product/service, or unique skill/relationship?
- How well-known is scope of work?
- What are risks and which party should assume which types?
- Does procurement affect activities on schedule's critical path and how much float is there?
- How important is it to be sure of cost in advance?
🛒 Progress payments and change management
Progress payments: Vendors require payments during contract life (contracts lasting several months incur significant costs; vendor wants payment as early as possible).
Progress payments: Payments made before project end based on work progress.
- Schedule of payments developed as part of contract; connected to completion of defined work amount or milestones.
- Example: Payment for design, then development, then final payment when solution completed and accepted (three payments).
- Defined work amount, time frame, quality standard before vendor is paid.
Change management:
- Just as project has scope defining what team does and what is outsourced, vendors have scope defining what they produce/supply.
- Changes occur requiring adjustments to vendor's scope.
- How changes are managed is typically documented in contract.
- Capture changes early, document what changed and impact, develop change order (change to contract) → important to maintain progress.
- Conflict may arise when changes not documented or team cannot agree on change.
- Effective change management process for vendors minimizes conflict and potential negative effect.
🛒 Managing contracts
Contract type determines effort level and skills needed.
Responsibilities:
- Individual managing contracts develops detailed specifications and ensures compliance.
- Tracks vendor performance against project needs (measurable performance evaluation criteria).
- Supplies support and direction when needed.
Long-lead items: Items taking long time to acquire receive early attention (e.g., equipment designed/built specifically for project; may require weeks, months, or years).
Non-performing vendors:
- Some project leaders refer to contract and impose penalties to persuade improvement.
- Others brainstorm ways vendor could improve performance before imposing penalties.
- Both approaches can work; team must assess what method is most likely to work in each situation.
Importance: Managing vendor performance is as important to overall project outcomes as work performed by project team.
✅ Quality management
✅ Quality management goals
Project success involves more than on time, on budget, within scope. It also involves delivering the right solution that accomplishes objectives and satisfies stakeholder expectations.
Quality management: Ensures the right solution is delivered.
Key principle: High quality achieved by planning for it rather than reacting to problems after identification.
Process: Standards chosen and processes put in place to achieve standards. Similar to triple constraints, quality is managed by setting goals and taking measurements. Understand quality levels stakeholders believe are acceptable; ensure project meets targets.
✅ Requirements and quality
Requirements gathering: Team identifies all specifications stakeholders want so they know how to define and measure quality.
Fitness to use: Making sure product has best design to fit customer/client needs.
- Example: You could pound nail with screwdriver, but hammer is better fit.
Conformance to requirements: Core of customer satisfaction and fitness to use; measure of how well solution meets expectations. Above all, solution must fulfill requirements established by users.
✅ Quality management plan
Quality management plan (large complex projects): Developed with key stakeholders (including end-user community).
Includes:
- What quality expectations are.
- Work required to ensure expectations are fulfilled.
Change management: Project budget, completion dates, and specifications may change over project life. Approach depends on development methodology.
- Predictive/waterfall: Requirements defined upfront; formal change control processes important (commitments regarding duration/cost likely established). Formally assess changes in quality specifications to understand impact on commitments; communicate impacts and seek approvals before implementation.
- Adaptive/agile: End solution cannot be clearly defined; quality expectations defined when capabilities, features, user stories developed in cycles. Scope of sprints may change as team learns about end-user requirements and effort required.
Process improvement tools: Organizations executing several similar project types may find tools useful in identifying and improving baseline processes (cost and schedule improvement opportunities). Students can read about Lean Six Sigma practices for products and applicability to service organizations. Ideally, identify improvement opportunities quickly to influence project performance (especially true for predictive, since planning is upfront). During later stages, as schedule pressures increase, culture is less conducive to work process changes.
Organizational quality policy: States how organization measures quality. Project leaders ensure project follows company policy and government rules/regulations.
Quality tasks: Part of good planning includes identifying tasks to measure solution quality. Specific tasks are part of scope and considered in schedules and budgets.
✅ Quality planning tools and techniques
Extent of tool use determined by project complexity and organization's quality management program.
Cost-benefit analysis: How much quality activities cost vs. how much will be gained.
- Typical costs: Effort and resources for quality activities.
- Typical benefits: Greater user satisfaction, less reworking, greater productivity.
Benchmarking: Using quality planning results from other projects to set goals for current project.
- Example: If last project had 20% fewer defects than previous, learn from it and put ideas into practice.
- Benchmarks serve as reference points for evaluating project before work begins.
Design of experiments: List of array of tests to run on product; lists test procedures, approaches, tests themselves (in software: test planning).
Cost of quality: Sum of all prevention and inspection activities.
- Includes: Testing, time writing standards, reviewing documents, meetings to analyze root causes of defects, reworking to fix defects… everything done to ensure quality.
- Can be compared from one project to another to identify innovative ideas and best practices.
Control charts: Define acceptable limits. If project functions are repetitive, statistical process controls identify trends and keep processes within control limits. Planning includes determining control limits and how process will be sampled.
Cause-and-effect diagrams: Help discover problems. When control charts indicate assignable cause for variation, not always easy to identify cause. Discussions facilitated using cause-and-effect (fishbone) diagram where participants identify possible causes of defect.
Example: Small manufacturing firm identifies six possibilities for variations: low-quality raw materials, power fluctuation, ambient temperature, worker absenteeism, poor training, old equipment. Each organized into fishbone diagram. Each branch expanded (e.g., power fluctuation branch: utility reliability, overloaded circuits from space heaters/motor start-up, lighting).
Check sheets, histograms, Pareto charts: Used to solve quality problems. When quality-control issue occurs, choose which problem to address first by determining which occur most frequently.
Check sheet: Basic form where user makes check in appropriate box each time problem occurs (or automate data collection).
Histogram: Frequency distribution chart (column chart where column widths fill x-axis space, proportional to category values; column height proportional to frequency).
Pareto chart: Variation on histogram invented by economist Vilfredo Pareto; columns arranged in decreasing order (most common on left) + line showing cumulative total. Combination allows user to tell at a glance which problems are most frequent and what fraction of total they represent.
Example: Six reasons travelers arrive late at airport. Traffic is #1 (55 participants out of ~154 total = ~36%). Child care issues #2 (~26%). Cumulatively, traffic + child care = 62%. Public transportation issues brings cumulative to ~80%. Understanding what causes majority allows team to prioritize and focus on key factors. If airport wants to reduce late arrivals, focus on traffic, child care, public transportation.
✅ Quality and grade
Quality (per ISO): "The degree to which a set of inherent characteristics fulfill requirements."
Grade: Requirements of product/process can be categorized or given a grade providing basis for comparison. Quality determined by how well something meets requirements of its grade.
Value: For most people, quality implies good value (getting money's worth). Even low-grade products should work as expected, be safe, last reasonable time.
Example: John has antique furniture in excellent condition (sentimental value) → hires movers ("high-grade professionals") with padding/restraints. Standard for high quality: no observable damage. If furniture arrives without dent/scratch, activity is high quality. John's dishes/glassware/utensils are old and cheap → lower standard → trusts inexperienced friends ("low-grade amateurs") to pack kitchen. If few dishes/glassware chipped/broken, savings in labour more than makeup for loss and still produce good value.
✅ Measurement terminology
During implementation, services/products sampled and measured to determine if quality is within control limits and analyze possible causes for variations. Often done by separate quality control group; knowledge of process measurement terms necessary to understand reports.
Control limits: Project teams identify limits; size of range between limits is tolerance. Often written as mean value ± tolerance.
Tool selection: Tools selected to measure samples closely enough to determine if measurements are within control limits and whether trends emerge. Each measurement tool has its own tolerances.
Cost of quality (COQ): Choice of tolerance directly affects COQ. Generally costs more to produce and measure products with small tolerances. Costs associated with small tolerances can be very high and not proportional to gains.
- Example: If cost of evaluating each screen in online tutorial is greater than delivering product and fixing issues after the fact, COQ may be too high and instructional designer will tolerate more defects.
Statistics: Mathematical interpretation of numerical data; useful when interpreting large numbers of measurements to determine how well product meets grade requirements (when same product made repeatedly). Measurements on samples must be within control limits (upper and lower extremes of allowable variation); project team designs process to consistently produce products between limits.
Central limit theorem: Impossible to control all small factors causing product to differ slightly from desired measurement. Some factors produce larger measurements, some opposite. If several random factors affect process, they tend to offset each other; most common results near middle of range.
Frequency distribution: If range of possible measurement values divided equally into subdivisions (bins), measurements sorted and counted per bin. Shows how many measurements fall into each bin.
Normal distribution: If effects causing differences are random and tend to offset each other, frequency distribution resembles bell shape with edges flaring out. Edges of theoretical normal distribution curve get very close to zero but do not reach zero.
✅ Quality assurance
Purpose: Create confidence that quality plan and controls are working properly. Allocate time to review original quality plan and compare to how quality is ensured during implementation.
Process analysis:
- Flowcharts of quality processes compared to processes followed during actual operations.
- If plan not followed, analyze process and take corrective action (educate people on following plan or revise plan).
- Examine experiments sampling products/processes and collecting data to see if following statistically valid sampling techniques and measurement methods have small enough tolerances to detect variation within control limits.
Learning and improvement: Projects are temporary, so fewer opportunities to learn/improve within project (especially short duration). Even in short projects, quality manager should have way to learn from experience and change process for next similar complexity project.
Purpose reiterated: Build confidence in user that quality standards/procedures are followed. Done by internal review of plan, testing, revision policies or audit by external group/agency.
👥 Stakeholder and communications management
👥 Stakeholder management importance
Achieving objectives requires focused, well-organized project leader who can engage committed team and gain support of all stakeholders. Building strong, trusting relationships from start can make difference between success and failure.
Challenge: One of most important and challenging aspects. Project leaders must rely on soft skills. Effective project leaders spend significant time building relationships.
👥 Understanding stakeholder interests
"What is in it for them?": Understanding stakeholder interest is about this question.
Defining success: Ask stakeholders how they define project success (powerful way to identify expectations). Knowing what each needs/wants enables project leader to anticipate support level and identify potential conflicts.
Conflicts: Common and often healthy. When managed effectively, lead to good decisions optimizing project value.
Common conflicts:
- Prioritizing project constraints (one stakeholder: aggressive timeline priority; another: minimize cost priority).
- Defining solution requirements (voice of stakeholders continuously heard during design/development; differences of opinion need respectful, timely resolution).
Resolving conflicts: Depending on methodology, resolving differences may be part of product owner, business SME, scrum master, business analyst, and/or project leader's accountabilities. When project leaders are accountable, interpersonal skills are key: active listening, clear willingness to facilitate relationship-building, staying "passionately neutral" (not about what's best for you; about what's best for project/organization and passionately pursuing that). Resolving conflicts respectfully is skill developed over time.
Resistant stakeholders: Some not supportive (feel project won't benefit them/their team as it should; resist necessary changes). Some upfront about resistance, others not. Project Sponsor may be integral to winning them over. Knowing when to tactfully involve others is another key success factor.
👥 Building trust and communication
Critical: Building trust and maintaining open communication. Keeping stakeholders involved requires more than sharing information. Project leader must ask for input and demonstrate understanding of stakeholder's unique business challenges. Understanding often done through simple, regular check-ins. Successful relationship builders understand each stakeholder's capacity to participate and honour time constraints.
Stakeholder register (Chapter 4): Effective tool for project leaders throughout project. Keeps track of all stakeholders and ensures needs are represented in communications plan.
👥 Communication types
Synchronous: All parties take part in exchange at same time.
- Examples: Conference calls, live meetings, instant messaging.
- Methods: Telephone, computer-assisted conference audio/video calls.
- Platforms: Skype, Zoom, Microsoft Teams (made virtual collaboration much more effective).
- Challenge: Getting team together at same time (especially across time zones).
Asynchronous: Parties not present at same time (prefix "a" means "not").
- Examples: Mailing legal documents, web-based collaboration platforms.
- Global projects: Consider availability of collaboration technology (varies significantly by country).
- Web-based platforms transformed communication; some organizations still use email to manage projects.
Choosing method:
- Some messages best conveyed synchronously (e.g., conflict resolution more effective when body language observable).
- Large amounts of technical information best done asynchronously (gives reader opportunity to review, process, respond after absorbing in written form).
👥 Communications plan
Communications plan: Strategic documentation of how and when project information will be communicated.
Questions answered:
- What information do stakeholders need?
- When is this information needed?
- How should this information be collected and analyzed? (systems and/or people?)
- How and when should this information be distributed? (technology platforms and/or people?)
- How will the team ensure communication is effective? (feedback loops)
First step critical: Planning flows from communication needs analysis. In deciding what information stakeholders need, consider information needed to keep stakeholders engaged, supportive, able to make good decisions. Project information is abundant; easy to overwhelm stakeholders. Teams must turn information into insight and determine what stakeholders will value.
Transparency: Communicating valuable information doesn't mean always painting rosy picture. Stakeholders should not be sheltered from bad news. Teams proactively communicating bad news are much more likely to earn respect (transparency is valued).
Common needs: After needs analysis, common needs emerge: project objectives, scope, milestones, budget, risks, issues, action items, performance measures, approvals required, etc.
Technology influence: Types of communication technology present heavily influence approaches to how/when information is communicated and who is responsible. In some cases, team already has IT needed. When not, assess new communication technologies.
👥 Assessing new communication technologies
New technologies appear with increasing frequency. Using unfamiliar technology increases technical complexity, causing delays and increased costs.
Questions to decide if new tool/application should be included:
- Does it provide benefit by increasing access to information, reducing cost/time for creating/disseminating information, and/or preventing mistakes?
- Does project team have expertise and capacity to learn new technology quickly?
- Does company offer support (e.g., help desk) to assist team members?
- Does organization (and project) have money to acquire new tools/applications?
Additional considerations: Determine urgency, complexity, audiences of information to help match communication tool to nature of information.
👥 Communications plan template
Answers to all questions documented in communications plan. Many different types exist. Good template includes:
- Who stakeholders are (individuals and groups).
- Communications necessary to satisfy stakeholder expectations.
- Timeframe and/or frequency of communication messages.
- Tools/applications used to communicate messages.
- Roles and responsibilities for creating and disseminating messages.
Note: The excerpt ends mid-chapter; Chapter 6 (Project Execution) begins but contains only a brief overview paragraph stating that implementation creates the unique product/service/result and the nature of work varies by project type (e.g., technology projects develop/test/deploy applications; export market research projects carry out research plans).