Project Management in IT: Still Needed, Just Not the Old Way
Agile teams, product owners and self-organizing squads have led many people to ask whether IT still needs project managers. The short answer is yes for some work and no for other work, and the job looks different from the one described in older textbooks. This guide separates what moved to the team from what still needs an owner, uses a simple counting rule to show why coordination grows quickly, draws on two sources (O*NET and a large study of IT project costs), and offers ways to stay useful. The rest of our project management section covers the methods in detail.
The short answer
Project management as a set of tasks is still needed in IT: planning, budgeting, risk, vendor and stakeholder management, and keeping several teams in step. Project management as a separate job title is needed less on small, stable, product-style teams and more on large, multi-team or vendor-heavy work.
Many of the old duties did not disappear. They moved to product owners, scrum masters, engineering managers and delivery leads, or were absorbed by tools. If you work in IT, the useful question is not “is the title obsolete?” but “who owns these jobs here?”
Why people ask
- Agile and product teams. Small teams plan their own work in short cycles, so the plan-and-control model looks heavy. Our guide to the growth of agile project management covers the trend.
- Continuous delivery. Where software ships frequently, “the project” no longer has a clear end date.
- New roles. Product owners decide priorities, and scrum masters or delivery leads manage the team’s process.
- Tools and AI. Boards, dashboards and assistants automate status gathering. See our guide to AI in project management.
- Bad experiences. Some teams have met project managers who only collected status. That job is easy to replace, but it is not the whole role.
What moved, and where it went
| Traditional duty | Where it often lives now | Still needs someone to own it? |
|---|---|---|
| Detailed task planning | The team, in short planning cycles | Less, for a single team |
| Deciding what to build and in what order | Product owner | Yes, with a clear decision maker |
| Running team events and process | Scrum master or delivery lead | Yes, though not always full time |
| Status collection | Boards, dashboards and automation | Less, but someone must interpret it |
| Budget and funding | Product or engineering leadership, finance | Yes, especially for large programs |
| Cross-team dependencies | Program or technical program managers | Yes |
| Vendor and contract management | Project or program manager, procurement | Yes |
| Risk, compliance and security sign-off | Mixed: project manager, security, legal | Yes |
| Stakeholder communication | Product owner, project manager, delivery lead | Yes |
| Change and release coordination | Release manager, operations, project manager | Yes, where many systems are touched |
The pattern: work inside one team moves to that team. Work between teams, between the company and its vendors, or between delivery and the wider business tends to stay with someone who spans those boundaries.
What still needs an owner
- Dependencies. One team’s release waits on another’s interface. Someone has to see this early and arrange it.
- Money and commitments. Budgets, contracts and promised dates to customers or regulators need an accountable person.
- Risk across the whole. Teams see their own risks. The combined picture (security, data, legal, third parties) needs one view.
- Trade-offs. When three teams ask for the same engineer, someone must decide, or escalate.
- Alignment. Executives, users and delivery teams often hold different expectations. A person who keeps them in sync saves expensive surprises.
- Closing out. Handover to operations, retiring the old system and capturing lessons rarely happen on their own.
A made-up coordination count
A simple counting rule shows why spanning roles keep appearing as organizations grow. If n teams all need to coordinate with each other, the number of possible pairs is n × (n − 1) ÷ 2.
| Teams involved | Calculation | Possible pairs to coordinate |
|---|---|---|
| 3 | 3 × 2 ÷ 2 | 3 |
| 5 | 5 × 4 ÷ 2 | 10 |
| 6 | 6 × 5 ÷ 2 | 15 |
| 12 | 12 × 11 ÷ 2 | 66 |
Doubling from 6 to 12 teams more than quadruples the possible pairs (15 to 66). Not every pair needs to talk regularly, and good design reduces the number that do. But the rule explains why a handful of independent teams may need no coordinator, while a dozen sharing one platform often does. It is a rough illustration, not a prediction of cost.
What the evidence says
No single study answers the question, but two sources help.
Job data. O*NET, the U.S. occupational database, has an entry for information technology project managers. Its description is to plan, initiate and manage IT projects, lead technical staff, and link business and technical teams. Listed tasks include managing execution to budget, schedule and scope, resolving problems with project staff, monitoring milestones, approving changes to plans and identifying when more resources are needed. Sample job titles on the entry include IT project manager, IT program manager and scrum master, which shows how the labels overlap. O*NET lists 2025 employment of 471,200 and projected growth of 5% to 6% for 2025 to 2035, described as faster than average, with 27,000 projected openings including replacements. Those figures come from U.S. government projections and may cover a broader occupation group, so treat them as a rough indicator.
Risk data. A study by Bent Flyvbjerg and Alexander Budzier, Why Your IT Project Might Be Riskier Than You Think, examined 1,471 IT projects. It found an average cost overrun of 27%, but also that about one in six projects (the authors call them “Black Swans”) had an average cost overrun of 200% and a schedule overrun of almost 70%. The authors argue that the real risk lies in these extreme outliers, not in the average. It is one study with its own sample, but the lesson fits the table above: someone should watch for the rare project that goes badly wrong, and have the authority to stop, re-plan or escalate early.
Neither source proves that every IT team needs a project manager. They suggest that the tasks remain, the demand has not vanished, and the cost of getting large projects wrong is high.
Where a project manager adds less
- One stable product team with a strong product owner, clear funding and few outside dependencies.
- Very small projects where the team can coordinate itself in minutes.
- Roles reduced to reporting. If the job is only collecting and reformatting status, tools can do it.
- Teams that already have the skills. An experienced engineering manager and product owner may cover the work.
That does not mean planning and risk work stops. It means the team covers it, and nobody needs the title.
How to stay relevant
- Own the cross-team picture. Dependencies, shared risks, release coordination.
- Learn how modern teams work. Agile, DevOps and product management basics, so you can work with teams instead of around them.
- Get fluent with data. Use flow and delivery measures to forecast. See our guide to project management metrics.
- Strengthen commercial skills. Budgets, contracts and vendor management are hard to automate. Our guide to preventing contract scope creep is a useful companion.
- Build influence. Facilitation, negotiation and clear writing. See soft skills for project managers.
- Use AI for the routine parts and spend the saved time on judgment.
- Show outcomes. Say what changed for the business, not only that the plan was followed.
- Consider a credential if your market asks for one. See our guide to PMI certifications.
Common mistakes
- Treating the title as the job. Ask which tasks are owned and by whom.
- Removing coordination without replacing it. Dependencies then surface late.
- Keeping the role but giving it no authority. A coordinator who cannot escalate adds meetings, not value.
- Applying one method everywhere. Fixed-scope vendor work and exploratory product work need different handling.
- Tracking activity instead of outcomes. The measure is delivered value, not tasks closed.
- Ignoring tail risk. The rare project that spirals is the costly one.
Learn more
If you want structured study of modern project delivery, online providers such as Coursera and Udemy list project management courses, including agile and hybrid ones. We may earn a commission if you sign up, at no cost to you. We are not affiliated with any university. Check the syllabus for agile, risk and stakeholder content. For more on the roles around IT projects, see our guide to project manager jobs.
Frequently asked questions
Is project management still relevant in IT?
Yes, as a set of tasks: planning, risk, budgets, vendors, dependencies and stakeholders. The job title is less common on small product teams and more common on large, multi-team or vendor-heavy work.
Does agile replace project managers?
Not entirely. Agile moves some duties, such as task planning and priorities, to the team and the product owner. Cross-team coordination, budgets, contracts and risk often still need an owner.
What does an IT project manager do?
According to O*NET, they plan, initiate and manage IT projects, lead technical staff and link business and technical teams, including managing to budget, schedule and scope, monitoring milestones and approving changes.
What is the difference between a project manager and a scrum master?
A scrum master focuses on one team’s process and agile practice. A project manager focuses on delivering a defined piece of work across teams and stakeholders. Some employers combine the two titles.
Is IT project management a good career?
O*NET projects faster-than-average growth for the occupation for 2025 to 2035. Pay and demand vary by region and employer, so check job postings near you.
How do IT projects fail?
Common causes include unclear goals, changing scope, poor estimates, weak ownership and unmanaged dependencies. One large study found that a minority of projects have very large overruns, which is why early warning matters.
What skills do IT project managers need?
Planning and tracking, communication, risk management, budgeting, vendor management, facilitation and enough technical and agile knowledge to work credibly with engineers.
Browse certificate, course and degree programs side by side.
