Agile project management is sometimes presented as "traditional project management, done faster." The actual differences run deeper than pace, touching fundamental assumptions about planning, requirements, and the project manager's role itself.
Different assumptions about planning
Traditional project management assumes detailed upfront planning is both possible and valuable, and deviation represents a problem to correct. Agile project management assumes that for complex, uncertain work, detailed long-range plans are generally wrong in ways only visible once work is underway, and planning should happen continuously rather than comprehensively upfront.
Different assumptions about requirements
Traditional approaches want requirements locked before work begins, with change managed through formal change control that treats change as exceptional. Agile approaches assume requirements will and should evolve as stakeholders see working increments, treating change as expected, valuable information rather than an exception.
A genuinely different role for the project manager
Traditional project managers typically hold direct authority over task assignment and scope. In agile approaches, this authority is deliberately distributed: the Product Owner controls priority, the team controls how work gets done, and there often isn't a traditional project manager role at all.
Organizations sometimes attempt to preserve a project manager's traditional authority while adopting agile ceremonies in name, producing a hybrid that satisfies neither model well, and a common reason adoption fails to produce agile's actual benefits.
What this means for choosing an approach
Agile project management suits work with high requirement uncertainty and high value in incorporating feedback. It's a worse fit for well-understood, stable requirements with low tolerance for schedule variability. The choice isn't "agile is simply better": it's matching the approach to the actual nature of the uncertainty involved.