Technical Project Management

Project management for software projects has different dynamics than construction or manufacturing. Software work has more uncertainty, more knowledge work, more rework. The PM frameworks imported from non-software (Gantt charts, fixed scope and date, etc.) often fit poorly.

This page covers the practices that work for software projects.

What software projects need

Software project management isn't generic project management. Specific features:

High uncertainty in early estimates

Software estimates are notoriously bad early; they get better as work progresses. Plans should accommodate this — fixed estimates with no revision are fictional.

Discovery during execution

Real requirements emerge as the work proceeds. A "complete" spec at project start has misunderstandings; finding them is part of the work.

Quality work that doesn't show

Engineers spend significant time on testing, refactoring, debugging — work that doesn't appear in feature lists. PMs who ignore this end up with technical debt.

Knowledge concentrated in heads

The team's knowledge of the system isn't fully captured in documents. Losing a key engineer mid-project changes everything.

The role

In software, "technical project manager" means many things:

Engineer-with-PM-skills

A senior engineer who runs the project alongside coding. Common pattern; the PM understands the technical work because they're doing it.

Dedicated PM

Someone whose primary job is coordination, not engineering. Useful for large projects with many stakeholders.

Engineering manager doubling as PM

The line manager handles project coordination. Common in startups.

The right setup depends on team size, project complexity, and organizational culture. Larger and more complex usually justifies a dedicated PM.

Estimation

The hard problem.

Why estimates are bad

- Engineers underestimate by default (optimism bias)

- Unknown unknowns dominate large projects

- Translation issues with non-engineers (one estimate becomes a commitment)

What helps

- **Estimate at the right granularity**: 1-3 day chunks. Smaller is more accurate; larger is too vague.

- **Track actuals**: estimate, finish, compare. Calibrate over time.

- **Use ranges, not points**: "5-10 days" is more honest than "7 days"

- **Budget for unknowns**: explicit slack in the plan

- **Re-plan as you learn**: not a failure; it's how software works

The trap of "just commit"

Stakeholders want commitments. Treating estimates as commitments without acknowledging uncertainty leads to:

- Padded estimates that nobody believes

- Or thin estimates that miss

- Either way, trust erodes

The honest approach: explicit confidence levels and ranges. "We're 80% confident in 4-6 weeks" beats "5 weeks."

Sequencing

Critical path

The longest dependent chain of work. Determines the minimum time. Identify the critical path; protect it.

Parallelize where possible

Independent work streams happen in parallel. Reduces total time even if individual streams are unchanged.

Risk-first

Tackle the highest-risk work first. Discoveries that invalidate the project should happen early, not at the end.

This is counter-intuitive — engineers often prefer easy work first to "build momentum." But postponing risk costs more than starting with it.

Demos and milestones

Visible progress every 1-2 weeks. Stakeholders see real work; team sees progress. Long stretches without visible progress destroy confidence.

Status communication

The PM's communication work:

Internal status

Team knows where things stand. Standup, written updates, dashboards. Don't manage by surprise.

Stakeholder status

External communication translated to non-engineering language. Focus on:

- What's done

- What's in progress

- Risks

- Decisions needed

- Timeline

Avoid technical detail at the wrong level. "We refactored the persistence layer" means nothing to a stakeholder; "the order service is 30% faster" does.

Bad-news fast

When things go wrong, communicate immediately. Hidden bad news compounds; revealed bad news is uncomfortable but actionable.

Specific tools

Tickets / issues

Jira, Linear, GitHub Issues. Useful for tracking; harmful if they become the work itself.

Roadmaps

Quarterly or annual. Direction without commitment. Useful for visibility; harmful if treated as commitment.

Gantt charts

Sometimes useful; usually false precision in software. The honest version shows uncertainty (wide bars, ranges).

Standups

Daily or every other day. Coordination, not status reports. If standup runs long, it's the wrong format.

Retrospectives

After phases or projects. What worked, what didn't, what to change. Genuine improvement requires actual changes, not just recording.

When projects go wrong

Behind schedule

Three options:

- Add scope reduction

- Add resources (rarely helps; "Mythical Man-Month")

- Slip the date

Pretending the date is achievable when it isn't is the worst option.

Scope creep

New requirements during execution. Either:

- Cut existing scope

- Slip the date

- Add resources for the new scope

The "fit it in" option is usually fiction.

Stuck on hard problem

Sometimes a project hits a problem nobody anticipated. Options:

- Spend the time to solve it

- Replace the approach

- Reduce scope to avoid it

PMs need to recognize this case and not let the project drift while engineers struggle silently.

Common failure patterns

- **Treating estimates as commitments.** Trust erodes when estimates miss.

- **No visibility on risks.** Discovered too late.

- **Too much process.** Team spends time on PM rituals instead of work.

- **Too little process.** Surprises everywhere.

- **Stakeholders managed via surprise.** Trust destroyed.

- **Long projects with no demos.** Loss of confidence.