Phase 5 of 5  ·  Management
Week 18 / 20   ·   Ch 22

Project
Management

"Why great engineers fail as managers — and what it actually takes"

📚 Ch 22 — Project Management👥 People Management⚠️ Risk Management⏱ ~20 min read

🔍Concept Deep Dives

Click each concept to expand — real examples, diagrams, pros & cons.

👥

Managing People

The most important and most underestimated part of SE management. Motivation, trust, retention.

When to Use

From day 1 as a tech lead or engineering manager.

Real-World Example

Google's Project Aristotle: psychological safety was #1 predictor of team performance — above skills or structure.

✓ Advantages

  • High-performing teams outperform systems/processes
  • Retention saves hiring costs

⚠ Watch Out

  • No formula — each person is different
  • Takes years to master
Maslow's hierarchy — applied to engineering teams
Self-actualization Meaningful work & growth
Esteem Recognition & technical respect
Social Team trust & belonging
Safety Job & psychological safety
Physical Good tools, reasonable hours
📋

Project Planning

Breaking down work, estimating effort, scheduling, tracking progress. Plans will change — build in slack.

When to Use

Start of every project and every sprint. Planning ≠ prediction — it's a shared conversation.

Real-World Example

'Plans are useless, but planning is indispensable' — Eisenhower. The act of planning reveals unknowns.

✓ Advantages

  • Shared team understanding
  • Identifies risks early
  • Basis for tracking progress

⚠ Watch Out

  • Estimates are always wrong
  • Over-planning = wasted effort
  • Plans become outdated
What a project plan contains
Work BreakdownWBS — tasks decomposed
Effort estimatesHow big each task is
ScheduleGantt / roadmap
Resource allocationWho does what
Risk registerKnown risks & mitigations
MilestonesReview & checkpoint dates
⚠️

Risk Management

Identify risks → Assess likelihood/impact → Develop mitigation strategies → Monitor.

When to Use

Start of every project. Revisited every sprint/milestone.

Real-World Example

Risk: 'Key developer may leave.' Mitigation: pair programming, documentation, bus factor reduction.

✓ Advantages

  • Reduces surprises
  • Forces proactive thinking
  • Stakeholder communication

⚠ Watch Out

  • Easy to identify risks, hard to mitigate them
  • Risk registers become stale
Risk register — two example entries
Key dev leaves
  • Likelihood: medium
  • Impact: high
  • Mitigate: pair-program, document
  • Contingency: hire contractor
Requirements change
  • Likelihood: high
  • Impact: medium
  • Mitigate: agile + change management
📊

Project Metrics

Measure progress, velocity, quality. Use data to make decisions — not just gut feel.

When to Use

Throughout the project — measure what matters, not what's easy to measure.

Real-World Example

DORA metrics: Deployment Frequency, Lead Time, MTTR, Change Failure Rate — the 4 that actually predict performance.

✓ Advantages

  • Objective basis for decisions
  • Early warning signals
  • Accountability

⚠ Watch Out

  • Goodhart's Law: metric becomes target and stops being good measure
  • Gaming the metric
DORA metrics — elite performer benchmarks
Many/dayDeployment frequency
<1 hrLead time for changes
<1 hrMean time to restore
<5%Change failure rate

📋Quick Reference

θ Ch 22 Cheat Sheet — Project Management
Risk Management
Identify → Assess (likelihood × impact) → Mitigate → Monitor. Every project, every sprint.
Bus Factor
How many people must be hit by a bus before the project fails? Keep it > 1.
Work Breakdown
Decompose project into tasks. Each task: 1 owner, measurable completion, ≤2 days.
DORA Metrics
Deployment Frequency, Lead Time, MTTR, Change Failure Rate. Elite teams excel in all 4.
Psychological Safety
Team members feel safe to speak up, ask questions, make mistakes. Google #1 team predictor.
Estimation
Planning poker, story points, t-shirt sizing. Estimates ≠ commitments. Add 20-30% buffer.
θ
Sommerville's Key Points — Ch 22
Author's own summary from the end of the chapter.
  • 1Software project management: scheduling, risk management, people management.
  • 2People management: most important skill — motivation, trust, team building.
  • 3Planning: break down work, estimate effort, schedule, track. Plans will change.
  • 4Risk management: identify, assess likelihood/impact, mitigate, monitor.
  • 5Project metrics: velocity, quality, DORA metrics — data-driven management.
  • 6Communication: regular status, clear escalation paths, stakeholder management.

🌍From the Book & Beyond

📖

Case Study — Alice, Dorothy & the Motivation Problem (Fig 22.8)

Sommerville's motivation case study (Figure 22.8) follows Alice, a project manager at an alarm-systems company entering the assistive technology market with a six-person team. Months in, Dorothy — the team's hardware expert — starts coming in late, her work quality drops, and she stops talking to teammates. The cause isn't laziness: the product direction left her writing C code instead of using her hardware interfacing skills, and she fears her career is stalling. Alice's fix is textbook people management — more design autonomy plus training that opens future opportunities. The takeaway: motivation problems are usually job-design problems in disguise.

2026 Perspective — Remote Teams, DORA Metrics & AI Agents

Managing engineers in 2026 means managing people you rarely see — and "teammates" that aren't people at all. Hybrid and remote-first teams are normal, so Sommerville's informal communication now flows through chat threads and recorded standups. Gut-feel progress tracking is giving way to DORA metrics — deployment frequency, lead time, change failure rate, time to restore — as the standard team health check. And the newest challenge: AI coding agents as a resource to be planned, reviewed, and budgeted, shifting the manager's question from "who writes this?" to "who verifies it?" Motivation and trust still decide everything else.

🧠Quiz — Test Yourself

Think through your answer first, then reveal.

Q1
Recall
What is the 'bus factor' and why does it matter?
Bus factor = how many people must be hit by a bus (or win the lottery and quit) before the project fails. If 1 person holds all critical knowledge, bus factor = 1 — one departure kills the project. Mitigation: pair programming, documentation, knowledge sharing, avoid knowledge silos.
Q2
Apply
What is Goodhart's Law and how does it apply to software metrics?
'When a measure becomes a target, it ceases to be a good measure.' Examples: measuring lines of code → developers write bloated code. Measuring tickets closed → developers close them without fixing. Measuring test coverage → developers write useless tests. Good metrics measure outcomes (DORA metrics), not activities.
Q3
Analyze
Why is psychological safety important for engineering teams?
Google's Project Aristotle found it's the #1 predictor of team performance. Teams with psychological safety: raise bugs early (saving money), ask questions (less rework), disagree openly (better decisions), experiment more (more innovation). Fear of judgment leads to silence, which leads to disasters.
Up Next → Week 19
Project Planning & Estimation
Why your 2-day estimate becomes a 2-week reality
Continue → Week 19