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.
Software project management isn't generic project management. Specific features:
Software estimates are notoriously bad early; they get better as work progresses. Plans should accommodate this — fixed estimates with no revision are fictional.
Real requirements emerge as the work proceeds. A "complete" spec at project start has misunderstandings; finding them is part of the work.
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.
The team's knowledge of the system isn't fully captured in documents. Losing a key engineer mid-project changes everything.
In software, "technical project manager" means many things:
A senior engineer who runs the project alongside coding. Common pattern; the PM understands the technical work because they're doing it.
Someone whose primary job is coordination, not engineering. Useful for large projects with many stakeholders.
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.
The hard problem.
Stakeholders want commitments. Treating estimates as commitments without acknowledging uncertainty leads to:
The honest approach: explicit confidence levels and ranges. "We're 80% confident in 4-6 weeks" beats "5 weeks."
The longest dependent chain of work. Determines the minimum time. Identify the critical path; protect it.
Independent work streams happen in parallel. Reduces total time even if individual streams are unchanged.
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.
Visible progress every 1-2 weeks. Stakeholders see real work; team sees progress. Long stretches without visible progress destroy confidence.
The PM's communication work:
Team knows where things stand. Standup, written updates, dashboards. Don't manage by surprise.
External communication translated to non-engineering language. Focus on:
Avoid technical detail at the wrong level. "We refactored the persistence layer" means nothing to a stakeholder; "the order service is 30% faster" does.
When things go wrong, communicate immediately. Hidden bad news compounds; revealed bad news is uncomfortable but actionable.
Jira, Linear, GitHub Issues. Useful for tracking; harmful if they become the work itself.
Quarterly or annual. Direction without commitment. Useful for visibility; harmful if treated as commitment.
Sometimes useful; usually false precision in software. The honest version shows uncertainty (wide bars, ranges).
Daily or every other day. Coordination, not status reports. If standup runs long, it's the wrong format.
After phases or projects. What worked, what didn't, what to change. Genuine improvement requires actual changes, not just recording.
Three options:
Pretending the date is achievable when it isn't is the worst option.
New requirements during execution. Either:
The "fit it in" option is usually fiction.
Sometimes a project hits a problem nobody anticipated. Options:
PMs need to recognize this case and not let the project drift while engineers struggle silently.