O conceito de gestão de projetos

Para o Project Management Institute (PMI), um projeto é “um esforço temporário empreendido para criar um produto, serviço ou resultado único”. ^[1] As duas palavras que importam são temporário, porque o projeto tem início e fim definidos, e único, porque o que ele entrega não é a repetição de uma rotina. É isso que separa um projeto da operação, que é contínua e repetitiva.

Gestão de projetos, por sua vez, é “a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto para cumprir os seus requisitos”. ^[1] Acima do projeto, o PMI organiza mais dois níveis:

• Programa: um grupo de projetos relacionados, gerenciados de forma coordenada para obter benefícios que não seriam obtidos separadamente.
• Portfólio: o conjunto de projetos, programas e operações gerenciados como um grupo para alcançar os objetivos estratégicos da organização.

O guia de referência do PMI, o PMBOK Guide, mudou muito nas últimas edições. A definição de projeto continua a mesma desde 1996, mas a forma de gerenciá-lo deixou de ser um conjunto de processos e passou a ser um conjunto de princípios orientados a valor:

Essa evolução já diz muito sobre o tema deste artigo. O próprio PMI reconhece que o centro da gestão não é mais cumprir o plano, e sim entregar valor. ^{[1] [2]} A pergunta que fica é se a ideia de projeto, algo temporário e com fim, é a melhor unidade para gerir um software que, se der certo, nunca termina.

Uma breve história da gestão de projetos

Grandes obras existem desde as pirâmides, mas a gestão de projetos como disciplina, com técnicas, papéis e associações próprias, nasceu no século XX, na engenharia e na indústria de defesa. ^[3]

1. Anos 1910Henry Gantt populariza o gráfico de barras para planejar e acompanhar a produção. O gráfico de Gantt continua, mais de cem anos depois, a ser a imagem mais associada a um projeto. ^[3]
2. 1942–1946O Projeto Manhattan mostra como coordenar milhares de pessoas, fornecedores e frentes de pesquisa sob um prazo rígido, e consolida a ideia de um gerente com autoridade sobre um esforço temporário. ^[3]
3. 1957–1958A DuPont e a Remington Rand criam o método do caminho crítico (CPM), e a Marinha dos Estados Unidos, com a Booz Allen Hamilton, cria o PERT para o programa de mísseis Polaris. Pela primeira vez, o cronograma vira um modelo matemático. ^{[4] [5]}
4. 1965–1969Nascem as associações profissionais: o IPMA na Europa, em 1965, e o PMI nos Estados Unidos, em 1969. ^[3]
5. 1970Winston Royce descreve o desenvolvimento de software em fases sequenciais, o que mais tarde seria chamado de cascata. Ironicamente, o próprio Royce escreveu que essa versão pura “é arriscada e convida ao fracasso”, e recomendou iterar. ^[6]
6. 1986–1995Takeuchi e Nonaka descrevem equipes que desenvolvem produtos como num scrum do rúgbi, e Ken Schwaber e Jeff Sutherland apresentam o Scrum para software em 1995. ^{[7] [8]}
7. 1996O PMI publica a primeira edição do PMBOK Guide e o governo britânico lança o PRINCE2. A gestão de projetos se padroniza e ganha certificações. ^[3]
8. 2001Dezessete profissionais de software assinam o Manifesto Ágil. ^[9]
9. 2017–2025O PMI publica o Agile Practice Guide com a Agile Alliance, reescreve o PMBOK em torno de princípios e valor na 7ª edição e, na 8ª, incorpora a IA. ^{[1] [2] [17]}

Um detalhe dessa história explica boa parte das críticas a seguir: as técnicas clássicas nasceram em obras, fábricas e programas militares, onde o escopo pode ser definido com antecedência e o resultado é físico. Elas foram levadas para o software, onde nenhuma das duas coisas costuma ser verdade.

As críticas à gestão de projetos aplicada à TI

Em 1975, Fred Brooks já avisava que o software é diferente: é invisível, muda o tempo todo e cresce em complexidade. A sua lei mais famosa diz que “adicionar pessoas a um projeto de software atrasado o atrasa ainda mais”. ^[10] Desde então, os números sobre projetos de TI não são animadores:

Os números precisam ser lidos com cuidado. O relatório CHAOS foi duramente criticado por Eveleens e Verhoef, que mostraram que a sua definição de sucesso mede apenas se a estimativa inicial foi cumprida, e não se o projeto gerou valor. ^[12] Mas os estudos acadêmicos que vieram depois confirmaram o essencial: o risco dos projetos de TI está nas caudas, nos poucos projetos que dão muito errado, e o maior prejuízo não é de prazo, é de valor.

As críticas mais frequentes à gestão de projetos aplicada à TI podem ser agrupadas assim:

• A premissa da previsibilidade. O planejamento detalhado pressupõe que os requisitos são conhecidos. Em software, a incerteza no início é enorme: Barry Boehm mostrou que as estimativas iniciais podem errar por um fator de até quatro, para mais ou para menos, o que ficou conhecido como cone da incerteza. ^[16] Em domínios complexos, causa e efeito só ficam claros depois, e o certo é experimentar, não planejar tudo antes. ^[15]
• O sucesso medido pelo plano, não pelo resultado. Um projeto pode terminar no prazo e no orçamento e entregar algo que ninguém usa. O triângulo de prazo, custo e escopo mede a obediência ao plano, e não o valor para o negócio.
• Equipes temporárias. O projeto monta uma equipe, entrega e a desfaz. O conhecimento sai com as pessoas, e o sistema passa para uma equipe de sustentação que não o construiu. O projeto termina, mas o software continua.
• Lotes grandes e risco no fim. Quando tudo é entregue de uma vez, os problemas aparecem tarde, quando já é caro corrigi-los.
• Financiamento por projeto. Como o dinheiro vem uma vez por ano e por projeto, as áreas aprendem a pedir grande, iniciar muitas frentes ao mesmo tempo e defender o escopo inteiro. O resultado é trabalho em andamento demais e entrega de menos.

Vale uma ressalva justa: muitas dessas críticas atingem a má prática, e não o PMI em si, que desde 2017 trata as abordagens adaptativas como legítimas. E Flyvbjerg, um dos críticos mais duros, não propõe abandonar o planejamento: propõe planejar devagar, com base em projetos semelhantes do passado, e executar rápido, em módulos pequenos e repetíveis. ^[34]

Gestão de projetos tradicional × metodologia ágil

O Manifesto Ágil, de 2001, respondeu diretamente às críticas da seção anterior com quatro valores: ^[9]

Indivíduos e interações mais que processos e ferramentas.
Software em funcionamento mais que documentação abrangente.
Colaboração com o cliente mais que negociação de contratos.
Responder a mudanças mais que seguir um plano.

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

A diferença mais visível entre as duas abordagens está no que é fixo e no que é estimado. Na abordagem tradicional, o escopo é fixado no início, e prazo e custo são estimados a partir dele. Na ágil, o triângulo se inverte: prazo e custo são fixados em ciclos curtos, e o escopo se ajusta ao que gera mais valor.

O diagrama vem do DSDM (Dynamic Systems Development Method), um dos primeiros métodos ágeis, criado em 1994 no Reino Unido por um consórcio de empresas usuárias e fornecedoras de tecnologia, o DSDM Consortium, hoje Agile Business Consortium. A inversão do triângulo é um dos seus fundamentos: o DSDM fixa prazo, custo e também qualidade desde o início, e deixa variar apenas as funcionalidades, priorizadas pela técnica MoSCoW, que separa o que é obrigatório (must), o que deveria entrar (should), o que poderia entrar (could) e o que fica de fora desta vez (won’t). ^[37]

Na prática, quase ninguém está num extremo. O Agile Practice Guide e o PMBOK tratam as abordagens como um espectro, e a maioria das organizações trabalha de forma híbrida. ^{[1] [17]} O modelo Cynefin ajuda a escolher: em problemas complicados, que um especialista consegue analisar, o planejamento funciona; em problemas complexos, só a experimentação revela o caminho. ^[15]

O ágil mudou a forma de trabalhar dentro da equipe, mas muitas vezes não mudou o que está em volta dela. A Forrester chamou isso de water-scrum-fall: requisitos e orçamento definidos em cascata no início, Scrum no meio e implantação em cascata no fim. ^[18] O orçamento anual por projeto, as metas de prazo e escopo e as equipes temporárias continuaram iguais. É justamente aí que atuam as abordagens da próxima seção.

Além da gestão atual de projetos

Nos últimos quinze anos surgiu um conjunto de ideias que não discute como gerenciar melhor um projeto, mas se o projeto é a unidade certa para gerir a TI. Cada uma ataca uma camada diferente da organização, e elas se complementam:

#NoProjects (Allan Kelly)

• Origem: 2013
• Camada: mentalidade
• Substitui: o projeto como unidade de trabalho

A hashtag #NoProjects surgiu no Twitter em 2013, usada por Joshua Arnold, Allan Kelly e Steve Smith. Kelly se tornou o principal autor do movimento com os livros Project Myopia e Continuous Digital, ambos de 2018. ^{[19] [20]}

O argumento central é simples: o software bem-sucedido não termina. Enquanto for usado, ele vai precisar de mudanças, correções e melhorias. Tratá-lo como projeto cria datas de término artificiais, desfaz equipes que acabaram de aprender o domínio e mede o sucesso pelo cumprimento do plano, e não pelo valor. Kelly chama essa visão de “miopia de projeto”. ^[19]

No lugar, ele propõe equipes estáveis que trabalham continuamente sobre um produto ou serviço, financiadas como uma capacidade, e não por projeto, e avaliadas pelos resultados que geram.

Cuidado: o nome provoca, mas o movimento não diz que nenhum projeto deve existir. Ele vale para o desenvolvimento contínuo de produtos digitais. Uma mudança de data center ou a troca de um ERP, com começo e fim claros, continuam sendo projetos.

Flow Framework (Mik Kersten, Project to Product)

• Origem: 2018
• Camada: medição
• Substitui: métricas de projeto e de atividade

Em Project to Product, Mik Kersten defende que as empresas estão gerenciando a era do software com ferramentas da era industrial. ^[21] A sua proposta é gerenciar fluxos de valor, que são todo o caminho de uma demanda até chegar ao cliente, e medir esse fluxo com uma linguagem que o negócio e a TI entendam.

Kersten define quatro tipos de item que passam pelo fluxo e cinco métricas para acompanhá-lo:

A métrica de distribuição é a mais reveladora para a gestão. Os quatro tipos de item disputam a mesma capacidade: se toda ela vai para funcionalidades, o débito técnico e os riscos se acumulam até que defeitos e incidentes passam a consumir a equipe. Kersten também insiste que as métricas de fluxo precisam ser ligadas a resultados do negócio, como receita, custo, qualidade e satisfação do cliente e da equipe.

Beyond Budgeting

• Origem: 1998
• Camada: dinheiro
• Substitui: o orçamento anual fixo

O Beyond Budgeting Round Table (BBRT) nasceu em 1998, e Jeremy Hope e Robin Fraser publicaram o livro que deu nome ao movimento em 2003. ^[22] Os casos mais conhecidos são o banco sueco Handelsbanken, que abandonou o orçamento tradicional nos anos 1970, e a norueguesa Statoil, hoje Equinor, onde Bjarte Bogsnes liderou a mudança. ^[23]

A ideia central de Bogsnes é que o orçamento tradicional mistura três coisas que deveriam estar separadas:

• Meta: o que queremos alcançar. Deve ser ambiciosa e, de preferência, relativa, por exemplo em comparação com concorrentes ou com o próprio histórico.
• Previsão: o que achamos que vai acontecer. Deve ser realista e revista sempre, num rolling forecast.
• Alocação de recursos: quanto liberar e quando. Deve acontecer quando a necessidade aparece, e não uma vez por ano.

O movimento resume a proposta em doze princípios, seis de liderança e seis de processos de gestão. Para a TI, a consequência é direta: se o dinheiro deixa de ser preso a projetos aprovados uma vez por ano, fica possível financiar equipes e produtos de forma contínua e mudar de rumo no meio do ano sem um novo processo de aprovação.

OKRs

• Origem: anos 1970
• Camada: direção
• Substitui: metas de prazo e escopo

Os Objectives and Key Results nasceram na Intel com Andy Grove, que os descreveu em High Output Management, de 1983. ^[24] John Doerr levou o método para o Google em 1999 e o popularizou com o livro Measure What Matters, de 2018. ^[25] A fórmula de Doerr é: “Vou [objetivo] medido por [resultados-chave]”.

A mudança para a TI está no que se mede. Em vez de “entregar o projeto do novo portal até junho”, o OKR descreve o resultado esperado. O exemplo abaixo é apenas ilustrativo: foi criado para este artigo, e a situação, os números e as metas são fictícios.

Exemplo ilustrativo

Objetivo: tornar a contratação de seguros pelo celular simples o bastante para dispensar o corretor.

Resultados-chave: reduzir o tempo médio de contratação de 25 para 8 minutos; aumentar de 30% para 55% as contratações concluídas sem ajuda; manter a nota de satisfação acima de 4,5.

Assim, a equipe ganha liberdade para descobrir o que construir, e o escopo vira uma hipótese, não um compromisso. Cuidados: resultados-chave que são apenas tarefas (“lançar o portal”), OKRs demais e o uso dos OKRs na avaliação individual e no bônus, que Doerr recomenda separar para não estimular metas tímidas. ^[25]

O paradoxo do escopo

Na minha visão, existe um paradoxo em tentar delimitar com precisão aquilo que é intangível. Definir em detalhe o escopo de algo que ainda não se conhece por inteiro, como a experiência do usuário, o ganho de produtividade de uma equipe ou o valor de uma nova capacidade, pode consumir mais tempo e recursos do que o valor que a entrega vai gerar durante o tempo em que for usada.

O cone da incerteza ajuda a explicar por quê: no início, cada detalhe especificado tem grande chance de mudar, e o esforço de defini-lo se perde. ^[16] Nesses casos, sai mais barato fixar o resultado esperado, como faz um OKR, e deixar que o escopo seja descoberto em ciclos curtos, medindo o progresso pelos resultados-chave.

Isto é o que preconiza a monitoria de negócios: em vez de especificar de saída todos os indicadores e regras, ela começa com poucos indicadores para os processos que mais importam, parte das perguntas do negócio e deixa que cada incidente mostre o que ainda falta medir.

Regra prática: só vale a pena delimitar o escopo em detalhe quando o custo de defini-lo for claramente menor do que o valor da entrega multiplicado pelo tempo em que ela será aproveitada.

Lean Portfolio Management (SAFe)

• Origem: SAFe, anos 2010
• Camada: dinheiro
• Substitui: o PPM baseado em projetos

O Scaled Agile Framework (SAFe) define o Lean Portfolio Management (LPM) como a função que alinha estratégia e execução em um portfólio ágil. Ele tem três dimensões: estratégia e financiamento de investimentos, operações ágeis do portfólio e governança enxuta. ^[26]

• Orçamento por fluxo de valor: o dinheiro vai para fluxos de valor e as suas equipes, e não para projetos. Os responsáveis decidem como usá-lo dentro de limites combinados, os guardrails.
• Orçamento participativo: os líderes do negócio e da TI distribuem juntos o orçamento entre os fluxos de valor, em ciclos curtos, em vez de uma negociação anual.
• Kanban do portfólio: as grandes iniciativas, chamadas épicos, passam por um fluxo visível, com um caso de negócio enxuto e um produto mínimo viável antes de receber mais investimento.
• Governança enxuta: conformidade e auditoria contínuas, com métricas de fluxo, no lugar de marcos de aprovação fase a fase.

O SAFe é criticado por ser prescritivo e pesado, mas as ideias do LPM podem ser aplicadas mesmo sem adotar o resto do framework. Elas são, na prática, a tradução do Beyond Budgeting para o portfólio de TI.

Team Topologies

• Origem: 2019 (2ª edição em 2025)
• Camada: estrutura
• Substitui: equipes montadas por projeto

Matthew Skelton e Manuel Pais partem da lei de Conway, de 1968: as organizações produzem sistemas que copiam a sua estrutura de comunicação. ^{[27] [28]} Se a arquitetura que queremos depende de como as equipes estão organizadas, a estrutura das equipes deve ser desenhada de propósito, e não ao sabor de cada projeto.

O livro propõe equipes estáveis, com uma carga cognitiva que caiba nelas, de apenas quatro tipos, e três modos de interação entre elas:

Para a gestão de projetos, a consequência é a inversão do fluxo: em vez de montar uma equipe para cada projeto, o trabalho é levado às equipes que já existem. A pergunta deixa de ser “quem está livre para este projeto?” e passa a ser “qual fluxo de valor é dono desta mudança?”.

IA aplicada diretamente sobre projetos

• Origem: anos 2020
• Camada: todas
• Substitui: boa parte do trabalho administrativo

Em 2019, o Gartner previu que, até 2030, 80% do trabalho da gestão de projetos daquela época seria eliminado, com a IA assumindo a coleta de dados, o acompanhamento e os relatórios. ^[29] A adoção está acelerando: em 2024, o PMI registrou que o grupo de profissionais que usa IA generativa em mais da metade dos projetos cresceu 86% em um ano, e já são cerca de dois em cada cinco entrevistados. ^[30]

Os dados sobre o efeito real, porém, pedem cautela. No relatório DORA de 2024, um aumento de 25% na adoção de IA veio acompanhado de uma queda estimada de 1,5% na vazão de entregas e de 7,2% na estabilidade. ^[31] Em 2025, a vazão passou a melhorar, mas a instabilidade continuou crescendo, e o DORA concluiu que a IA é um amplificador: aumenta os pontos fortes das organizações que já funcionam bem e as disfunções das que não funcionam. ^[32] Num experimento controlado do METR, desenvolvedores experientes levaram 19% mais tempo com ferramentas de IA, embora acreditassem que tinham ficado mais rápidos. ^[33]

A lição se liga às outras ideias desta seção: acelerar uma etapa não acelera o fluxo inteiro. Se a IA faz o código sair mais rápido, mas a aprovação, os testes e a implantação continuam iguais, o gargalo só muda de lugar. A IA rende mais onde o fluxo de valor já está visível e medido.

O futuro

Nenhuma dessas ideias substitui sozinha a gestão de projetos. O que se vê é uma convergência: cada uma resolve uma parte do problema, e juntas desenham um modelo de gestão da TI diferente do atual. Marty Cagan chama esse conjunto de modelo operacional de produto. ^[35] As tendências abaixo são a minha leitura das fontes citadas:

Três ressalvas tornam esse futuro mais realista:

• Os projetos não vão desaparecer. Migrações, implantações de ERP, fusões, exigências regulatórias e obras de infraestrutura têm começo e fim reais. Para eles, as técnicas clássicas, somadas às lições de Flyvbjerg sobre planejamento por referência e entregas modulares, continuam valendo. ^[34]
• As competências de projeto vão valer mais, não menos. O PMI estima que o mundo vai precisar de 25 milhões de novos profissionais de projetos até 2030. ^[36] O que muda é o conteúdo do trabalho: menos atualização de cronograma e mais negociação, priorização, gestão de riscos e liderança, as competências que a IA não substitui.
• O gargalo vai migrar. Se a IA reduz o custo de construir, o recurso escasso passa a ser decidir o que construir e validar se funcionou. Isso favorece apostas menores e mais frequentes, ciclos curtos de financiamento e uma medição honesta de resultados, exatamente o que as abordagens deste artigo propõem. É a lição da Teoria das Restrições de Goldratt: um sistema só entrega no ritmo do seu gargalo, e quando uma restrição é eliminada outra aparece em seu lugar. Acelerar a codificação sem olhar para a nova restrição apenas acumula trabalho parado na frente dela.

Conclusões

A gestão de projetos nasceu em obras e programas militares, onde o escopo podia ser definido antes e o resultado era físico. Levada para a TI, ela trouxe disciplina, mas também uma premissa que o software raramente cumpre: a de que é possível saber tudo no início. Os estudos de Flyvbjerg e da McKinsey mostram que o maior prejuízo dos projetos de TI não é o atraso, é o valor que deixa de ser entregue.

O ágil corrigiu a forma de trabalhar dentro das equipes, mas deixou intactos o orçamento anual, as metas de escopo e as equipes temporárias. As abordagens que vão além dos projetos atacam exatamente essas camadas: o #NoProjects muda a unidade de trabalho, os OKRs mudam a direção, o Beyond Budgeting e o Lean Portfolio Management mudam o dinheiro, o Team Topologies muda a estrutura e o Flow Framework muda a medição.

A IA vai absorver boa parte do trabalho administrativo da gestão, mas não resolve sozinha um fluxo mal desenhado; ela amplifica o que já existe. O futuro dos projetos de TI, portanto, não é o fim da gestão. É a troca de uma gestão centrada no plano por uma gestão centrada no fluxo de valor, com equipes estáveis, dinheiro que acompanha os resultados e gerentes que dedicam o tempo liberado pela IA às decisões que importam.

Referências

1. Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Seventh Edition and The Standard for Project Management, PMI, 2021.
2. Project Management Institute, PMBOK Guide – Eighth Edition, PMI, 2025, pmi.org/pmbok-guide.
3. Garel, Gilles, “A history of project management models: From pre-models to the standard models”, International Journal of Project Management, v. 31, n. 5, p. 663–669, 2013.
4. Kelley, James E.; Walker, Morgan R., “Critical-Path Planning and Scheduling”, Proceedings of the Eastern Joint Computer Conference, 1959.
5. Malcolm, D. G.; Roseboom, J. H.; Clark, C. E.; Fazar, W., “Application of a Technique for Research and Development Program Evaluation”, Operations Research, v. 7, n. 5, 1959.
6. Royce, Winston W., “Managing the Development of Large Software Systems”, Proceedings of IEEE WESCON, 1970.
7. Takeuchi, Hirotaka; Nonaka, Ikujiro, “The New New Product Development Game”, Harvard Business Review, janeiro de 1986.
8. Schwaber, Ken, “SCRUM Development Process”, OOPSLA Business Object Design and Implementation Workshop, 1995.
9. Beck, Kent et al., Manifesto para Desenvolvimento Ágil de Software, 2001, agilemanifesto.org.
10. Brooks, Frederick P., The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, 1975.
11. The Standish Group, The CHAOS Report, 1994.
12. Eveleens, J. Laurenz; Verhoef, Chris, “The Rise and Fall of the Chaos Report Figures”, IEEE Software, v. 27, n. 1, p. 30–36, 2010, ieeexplore.ieee.org/document/5232804.
13. Flyvbjerg, Bent; Budzier, Alexander, “Why Your IT Project May Be Riskier Than You Think”, Harvard Business Review, setembro de 2011, arxiv.org/abs/1304.0265.
14. Bloch, Michael; Blumberg, Sven; Laartz, Jürgen, “Delivering large-scale IT projects on time, on budget, and on value”, McKinsey & Company, 2012, mckinsey.com.
15. Snowden, David J.; Boone, Mary E., “A Leader’s Framework for Decision Making”, Harvard Business Review, novembro de 2007.
16. Boehm, Barry W., Software Engineering Economics, Prentice Hall, 1981.
17. Project Management Institute; Agile Alliance, Agile Practice Guide, PMI, 2017.
18. West, Dave, “Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today”, Forrester Research, 2011.
19. Kelly, Allan, Project Myopia: Why projects damage software, Software Strategy, 2018, leanpub.com/noprojects.
20. Kelly, Allan, Continuous Digital: An agile alternative to projects for digital business, Software Strategy, 2018, leanpub.com/cdigital.
21. Kersten, Mik, Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework, IT Revolution, 2018, flowframework.org.
22. Hope, Jeremy; Fraser, Robin, Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap, Harvard Business School Press, 2003.
23. Bogsnes, Bjarte, Implementing Beyond Budgeting: Unlocking the Performance Potential, 2ª ed., Wiley, 2016; Beyond Budgeting Round Table, bbrt.org.
24. Grove, Andrew S., High Output Management, Random House, 1983.
25. Doerr, John, Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs, Portfolio/Penguin, 2018.
26. Scaled Agile, Inc., “Lean Portfolio Management”, SAFe Framework, acesso em 02/10/2026, framework.scaledagile.com/lean-portfolio-management.
27. Skelton, Matthew; Pais, Manuel, Team Topologies: Organizing Business and Technology Teams for Fast Flow, IT Revolution, 2019; 2ª ed., 2025, teamtopologies.com.
28. Conway, Melvin E., “How Do Committees Invent?”, Datamation, abril de 1968.
29. Gartner, “Gartner Says 80 Percent of Today’s Project Management Tasks Will Be Eliminated by 2030 as Artificial Intelligence Takes Over”, comunicado de imprensa, 20/03/2019, gartner.com.
30. Project Management Institute, Pushing the Limits: Transforming Project Management with GenAI Innovation, 2024, pmi.org.
31. DORA (Google Cloud), Accelerate State of DevOps Report 2024, 2024, dora.dev.
32. DORA (Google Cloud), State of AI-assisted Software Development, 2025, dora.dev/research/ai.
33. Becker, Joel; Rush, Nate; Barnes, Elizabeth; Rein, David (METR), “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, julho de 2025, metr.org.
34. Flyvbjerg, Bent; Gardner, Dan, How Big Things Get Done, Currency, 2023.
35. Cagan, Marty, Transformed: Moving to the Product Operating Model, Wiley, 2024.
36. Project Management Institute, Talent Gap: Ten-Year Employment Trends, Costs, and Global Implications, 2021, pmi.org.
37. Agile Business Consortium, The DSDM Agile Project Framework, 2014, agilebusiness.org.

The concept of project management

For the Project Management Institute (PMI), a project is “a temporary endeavor undertaken to create a unique product, service, or result”. ^[1] The two words that matter are temporary, because the project has a defined start and end, and unique, because what it delivers is not the repetition of a routine. That is what separates a project from operations, which are ongoing and repetitive.

Project management, in turn, is “the application of knowledge, skills, tools, and techniques to project activities to meet project requirements”. ^[1] Above the project, PMI defines two more levels:

• Program: a group of related projects managed in a coordinated way to obtain benefits that would not be available if they were managed separately.
• Portfolio: the set of projects, programs and operations managed as a group to achieve the organization’s strategic objectives.

PMI’s reference guide, the PMBOK Guide, has changed a lot in its recent editions. The definition of a project has stayed the same since 1996, but the way to manage it has moved from a set of processes to a set of value-oriented principles:

This evolution already says a lot about the subject of this article. PMI itself acknowledges that the core of management is no longer following the plan, but delivering value. ^{[1] [2]} The open question is whether the project, something temporary that comes to an end, is the best unit for managing software that, if it succeeds, never ends.

A brief history of project management

Large undertakings have existed since the pyramids, but project management as a discipline, with its own techniques, roles and associations, was born in the twentieth century, in engineering and in the defense industry. ^[3]

1. 1910sHenry Gantt popularizes the bar chart to plan and track production. More than a hundred years later, the Gantt chart is still the image most associated with a project. ^[3]
2. 1942–1946The Manhattan Project shows how to coordinate thousands of people, suppliers and research fronts under a strict deadline, and consolidates the idea of a manager with authority over a temporary endeavor. ^[3]
3. 1957–1958DuPont and Remington Rand create the critical path method (CPM), and the US Navy, with Booz Allen Hamilton, creates PERT for the Polaris missile program. For the first time, the schedule becomes a mathematical model. ^{[4] [5]}
4. 1965–1969The professional associations are born: IPMA in Europe, in 1965, and PMI in the United States, in 1969. ^[3]
5. 1970Winston Royce describes software development in sequential phases, what would later be called waterfall. Ironically, Royce himself wrote that this pure version “is risky and invites failure”, and recommended iterating. ^[6]
6. 1986–1995Takeuchi and Nonaka describe teams that develop products like a rugby scrum, and Ken Schwaber and Jeff Sutherland present Scrum for software in 1995. ^{[7] [8]}
7. 1996PMI publishes the first edition of the PMBOK Guide and the British government launches PRINCE2. Project management becomes standardized and gains certifications. ^[3]
8. 2001Seventeen software practitioners sign the Agile Manifesto. ^[9]
9. 2017–2025PMI publishes the Agile Practice Guide with the Agile Alliance, rewrites the PMBOK around principles and value in the 7th edition and, in the 8th, brings in AI. ^{[1] [2] [17]}

One detail of this history explains much of the criticism that follows: the classic techniques were born on construction sites, in factories and in military programs, where scope can be defined in advance and the result is physical. They were carried over to software, where neither is usually true.

Criticism of project management applied to IT

As early as 1975, Fred Brooks warned that software is different: it is invisible, it changes all the time and it grows in complexity. His most famous law says that “adding manpower to a late software project makes it later”. ^[10] Since then, the numbers on IT projects have not been encouraging:

The numbers must be read with care. The CHAOS report was harshly criticized by Eveleens and Verhoef, who showed that its definition of success only measures whether the initial estimate was met, not whether the project created value. ^[12] But the academic studies that came later confirmed the essentials: the risk of IT projects lies in the tails, in the few projects that go very wrong, and the biggest loss is not time, it is value.

The most frequent criticisms of project management applied to IT can be grouped like this:

• The predictability assumption. Detailed planning assumes that requirements are known. In software, uncertainty at the start is huge: Barry Boehm showed that early estimates can be off by a factor of up to four, in either direction, which became known as the cone of uncertainty. ^[16] In complex domains, cause and effect only become clear in hindsight, and the right move is to experiment, not to plan everything up front. ^[15]
• Success measured by the plan, not by the outcome. A project can finish on time and on budget and deliver something nobody uses. The triangle of time, cost and scope measures compliance with the plan, not business value.
• Temporary teams. The project assembles a team, delivers and disbands it. Knowledge leaves with the people, and the system is handed over to a maintenance team that did not build it. The project ends, but the software goes on.
• Large batches and risk at the end. When everything is delivered at once, problems show up late, when they are already expensive to fix.
• Project-based funding. Because money comes once a year and per project, areas learn to ask big, start many fronts at the same time and defend the whole scope. The result is too much work in progress and too little delivered.

A fair caveat: many of these criticisms target bad practice, not PMI itself, which since 2017 has treated adaptive approaches as legitimate. And Flyvbjerg, one of the harshest critics, does not propose abandoning planning: he proposes planning slowly, based on similar past projects, and acting fast, in small, repeatable modules. ^[34]

Traditional project management × agile methodology

The Agile Manifesto, in 2001, responded directly to the criticisms in the previous section with four values: ^[9]

Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.

The most visible difference between the two approaches lies in what is fixed and what is estimated. In the traditional approach, scope is fixed at the start, and time and cost are estimated from it. In agile, the triangle is inverted: time and cost are fixed in short cycles, and scope adjusts to whatever creates the most value.

The diagram comes from DSDM (Dynamic Systems Development Method), one of the first agile methods, created in 1994 in the United Kingdom by a consortium of technology users and suppliers, the DSDM Consortium, now the Agile Business Consortium. Inverting the triangle is one of its foundations: DSDM fixes time, cost and also quality from the start, and lets only the features vary, prioritized with the MoSCoW technique, which separates what the solution must have, should have, could have and won’t have this time. ^[37]

In practice, almost nobody sits at one extreme. The Agile Practice Guide and the PMBOK treat the approaches as a spectrum, and most organizations work in a hybrid way. ^{[1] [17]} The Cynefin framework helps to choose: in complicated problems, which an expert can analyze, planning works; in complex problems, only experimentation reveals the way. ^[15]

Agile changed the way of working inside the team, but often did not change what surrounds it. Forrester called this water-scrum-fall: requirements and budget defined waterfall-style at the start, Scrum in the middle and waterfall release at the end. ^[18] The annual budget per project, time and scope targets and temporary teams stayed the same. That is exactly where the approaches in the next section come in.

Beyond today’s project management

Over the last fifteen years a set of ideas has emerged that does not discuss how to manage a project better, but whether the project is the right unit for managing IT at all. Each one tackles a different layer of the organization, and they complement each other:

#NoProjects (Allan Kelly)

• Origin: 2013
• Layer: mindset
• Replaces: the project as the unit of work

The #NoProjects hashtag appeared on Twitter in 2013, used by Joshua Arnold, Allan Kelly and Steve Smith. Kelly became the movement’s main author with the books Project Myopia and Continuous Digital, both from 2018. ^{[19] [20]}

The central argument is simple: successful software does not end. As long as it is used, it will need changes, fixes and improvements. Treating it as a project creates artificial end dates, disbands teams that have just learned the domain and measures success by compliance with the plan rather than by value. Kelly calls this view “project myopia”. ^[19]

Instead, he proposes stable teams that work continuously on a product or service, funded as a capability rather than per project, and assessed by the outcomes they create.

A caveat: the name is provocative, but the movement does not say that no project should ever exist. It applies to the continuous development of digital products. Moving a data center or replacing an ERP, with a clear start and end, are still projects.

Flow Framework (Mik Kersten, Project to Product)

• Origin: 2018
• Layer: measurement
• Replaces: project and activity metrics

In Project to Product, Mik Kersten argues that companies are managing the age of software with tools from the industrial age. ^[21] His proposal is to manage value streams, the whole path from a demand to the customer, and to measure that flow in a language that both the business and IT understand.

Kersten defines four types of item that move through the flow and five metrics to track it:

Flow distribution is the most revealing metric for management. The four item types compete for the same capacity: if all of it goes to features, technical debt and risks pile up until defects and incidents start consuming the team. Kersten also insists that flow metrics must be tied to business results, such as revenue, cost, quality and customer and team satisfaction.

Beyond Budgeting

• Origin: 1998
• Layer: money
• Replaces: the fixed annual budget

The Beyond Budgeting Round Table (BBRT) was founded in 1998, and Jeremy Hope and Robin Fraser published the book that named the movement in 2003. ^[22] The best-known cases are the Swedish bank Handelsbanken, which abandoned traditional budgeting in the 1970s, and Norway’s Statoil, now Equinor, where Bjarte Bogsnes led the change. ^[23]

Bogsnes’s central idea is that the traditional budget mixes three things that should be kept apart:

• Target: what we want to achieve. It should be ambitious and, ideally, relative, for example compared with competitors or with one’s own track record.
• Forecast: what we think will happen. It should be realistic and constantly updated, in a rolling forecast.
• Resource allocation: how much to release and when. It should happen when the need arises, not once a year.

The movement sums up its proposal in twelve principles, six on leadership and six on management processes. For IT, the consequence is direct: if money is no longer tied to projects approved once a year, it becomes possible to fund teams and products continuously and change course mid-year without a new approval process.

OKRs

• Origin: 1970s
• Layer: direction
• Replaces: time and scope targets

Objectives and Key Results were born at Intel with Andy Grove, who described them in High Output Management, in 1983. ^[24] John Doerr took the method to Google in 1999 and popularized it with the book Measure What Matters, in 2018. ^[25] Doerr’s formula is: “I will [objective] as measured by [key results]”.

The change for IT lies in what is measured. Instead of “deliver the new portal project by June”, the OKR describes the expected outcome. The example below is purely illustrative: it was created for this article, and the situation, the numbers and the targets are fictitious.

Illustrative example

Objective: make buying insurance on a phone simple enough to do without a broker.

Key results: cut the average purchase time from 25 to 8 minutes; raise purchases completed without help from 30% to 55%; keep the satisfaction score above 4.5.

This gives the team freedom to discover what to build, and scope becomes a hypothesis, not a commitment. Pitfalls: key results that are just tasks (“launch the portal”), too many OKRs and using OKRs for individual appraisal and bonuses, which Doerr recommends keeping apart so as not to encourage timid goals. ^[25]

The scope paradox

In my view, there is a paradox in trying to pin down precisely what is intangible. Defining in detail the scope of something that is not yet fully understood, such as the user experience, a team’s productivity gain or the value of a new capability, can consume more time and resources than the value the delivery will create during the time it is used.

The cone of uncertainty helps explain why: early on, each specified detail has a high chance of changing, and the effort to define it is lost. ^[16] In these cases, it is cheaper to fix the expected outcome, as an OKR does, and let the scope be discovered in short cycles, measuring progress through the key results.

This is what business monitoring advocates: instead of specifying every indicator and rule up front, it starts with a few indicators for the processes that matter most, begins with the business questions and lets each incident show what still needs to be measured.

Rule of thumb: detailing the scope is only worth it when the cost of defining it is clearly lower than the value of the delivery multiplied by the time during which it will be used.

Lean Portfolio Management (SAFe)

• Origin: SAFe, 2010s
• Layer: money
• Replaces: project-based PPM

The Scaled Agile Framework (SAFe) defines Lean Portfolio Management (LPM) as the function that aligns strategy and execution in an agile portfolio. It has three dimensions: strategy and investment funding, agile portfolio operations and lean governance. ^[26]

• Value stream budgets: money goes to value streams and their teams, not to projects. Those accountable decide how to use it within agreed limits, the guardrails.
• Participatory budgeting: business and IT leaders allocate the budget across value streams together, in short cycles, instead of an annual negotiation.
• Portfolio Kanban: large initiatives, called epics, move through a visible flow, with a lean business case and a minimum viable product before receiving more investment.
• Lean governance: continuous compliance and auditing, with flow metrics, instead of phase-by-phase approval gates.

SAFe is criticized for being prescriptive and heavy, but LPM ideas can be applied without adopting the rest of the framework. In practice, they are the translation of Beyond Budgeting into the IT portfolio.

Team Topologies

• Origin: 2019 (2nd edition in 2025)
• Layer: structure
• Replaces: teams assembled per project

Matthew Skelton and Manuel Pais start from Conway’s law, from 1968: organizations produce systems that copy their communication structure. ^{[27] [28]} If the architecture we want depends on how teams are organized, team structure must be designed on purpose, not left to the whims of each project.

The book proposes stable teams, with a cognitive load they can handle, of only four types, and three modes of interaction between them:

For project management, the consequence is an inversion of the flow: instead of assembling a team for each project, work is brought to teams that already exist. The question is no longer “who is free for this project?” but “which value stream owns this change?”.

AI applied directly to projects

• Origin: 2020s
• Layer: all of them
• Replaces: much of the administrative work

In 2019, Gartner predicted that by 2030, 80% of the project management work of the time would be eliminated, with AI taking over data collection, tracking and reporting. ^[29] Adoption is accelerating: in 2024, PMI found that the group of professionals using generative AI in more than half of their projects grew 86% in one year, and now accounts for about two in five respondents. ^[30]

The data on the actual effect, however, calls for caution. In the 2024 DORA report, a 25% increase in AI adoption was accompanied by an estimated 1.5% drop in delivery throughput and a 7.2% drop in stability. ^[31] In 2025, throughput began to improve, but instability kept growing, and DORA concluded that AI is an amplifier: it magnifies the strengths of organizations that already work well and the dysfunctions of those that do not. ^[32] In a controlled trial by METR, experienced developers took 19% longer with AI tools, even though they believed they had become faster. ^[33]

The lesson ties in with the other ideas in this section: speeding up one step does not speed up the whole flow. If AI makes code come out faster, but approval, testing and deployment stay the same, the bottleneck just moves. AI pays off most where the value stream is already visible and measured.

The future

None of these ideas replaces project management on its own. What we see is a convergence: each one solves part of the problem, and together they sketch a way of managing IT that differs from today’s. Marty Cagan calls this set the product operating model. ^[35] The trends below are my reading of the sources cited:

Three caveats make this future more realistic:

• Projects will not disappear. Migrations, ERP rollouts, mergers, regulatory demands and infrastructure work have a real start and end. For them, the classic techniques, combined with Flyvbjerg’s lessons on reference-class planning and modular delivery, remain valid. ^[34]
• Project skills will be worth more, not less. PMI estimates that the world will need 25 million new project professionals by 2030. ^[36] What changes is the content of the work: less schedule updating and more negotiation, prioritization, risk management and leadership, the skills AI does not replace.
• The bottleneck will move. If AI lowers the cost of building, the scarce resource becomes deciding what to build and validating whether it worked. That favors smaller, more frequent bets, short funding cycles and honest measurement of outcomes, exactly what the approaches in this article propose. This is the lesson of Goldratt’s Theory of Constraints: a system only delivers at the pace of its bottleneck, and when one constraint is removed another takes its place. Speeding up coding without looking at the new constraint only piles up idle work in front of it.

Conclusions

Project management was born in construction and military programs, where scope could be defined beforehand and the result was physical. Carried over to IT, it brought discipline, but also an assumption that software rarely fulfills: that it is possible to know everything at the start. The studies by Flyvbjerg and by McKinsey show that the biggest loss in IT projects is not delay, it is the value that never gets delivered.

Agile fixed the way of working inside teams, but left the annual budget, scope targets and temporary teams untouched. The approaches that go beyond projects target exactly those layers: #NoProjects changes the unit of work, OKRs change direction, Beyond Budgeting and Lean Portfolio Management change the money, Team Topologies changes the structure and the Flow Framework changes measurement.

AI will absorb much of the administrative work of management, but it does not fix a poorly designed flow on its own; it amplifies what already exists. The future of IT projects, therefore, is not the end of management. It is the shift from management centered on the plan to management centered on the value stream, with stable teams, money that follows outcomes and managers who spend the time AI frees up on the decisions that matter.

References

1. Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Seventh Edition and The Standard for Project Management, PMI, 2021.
2. Project Management Institute, PMBOK Guide – Eighth Edition, PMI, 2025, pmi.org/pmbok-guide.
3. Garel, Gilles, “A history of project management models: From pre-models to the standard models”, International Journal of Project Management, vol. 31, no. 5, pp. 663–669, 2013.
4. Kelley, James E.; Walker, Morgan R., “Critical-Path Planning and Scheduling”, Proceedings of the Eastern Joint Computer Conference, 1959.
5. Malcolm, D. G.; Roseboom, J. H.; Clark, C. E.; Fazar, W., “Application of a Technique for Research and Development Program Evaluation”, Operations Research, vol. 7, no. 5, 1959.
6. Royce, Winston W., “Managing the Development of Large Software Systems”, Proceedings of IEEE WESCON, 1970.
7. Takeuchi, Hirotaka; Nonaka, Ikujiro, “The New New Product Development Game”, Harvard Business Review, January 1986.
8. Schwaber, Ken, “SCRUM Development Process”, OOPSLA Business Object Design and Implementation Workshop, 1995.
9. Beck, Kent et al., Manifesto for Agile Software Development, 2001, agilemanifesto.org.
10. Brooks, Frederick P., The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, 1975.
11. The Standish Group, The CHAOS Report, 1994.
12. Eveleens, J. Laurenz; Verhoef, Chris, “The Rise and Fall of the Chaos Report Figures”, IEEE Software, vol. 27, no. 1, pp. 30–36, 2010, ieeexplore.ieee.org/document/5232804.
13. Flyvbjerg, Bent; Budzier, Alexander, “Why Your IT Project May Be Riskier Than You Think”, Harvard Business Review, September 2011, arxiv.org/abs/1304.0265.
14. Bloch, Michael; Blumberg, Sven; Laartz, Jürgen, “Delivering large-scale IT projects on time, on budget, and on value”, McKinsey & Company, 2012, mckinsey.com.
15. Snowden, David J.; Boone, Mary E., “A Leader’s Framework for Decision Making”, Harvard Business Review, November 2007.
16. Boehm, Barry W., Software Engineering Economics, Prentice Hall, 1981.
17. Project Management Institute; Agile Alliance, Agile Practice Guide, PMI, 2017.
18. West, Dave, “Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today”, Forrester Research, 2011.
19. Kelly, Allan, Project Myopia: Why projects damage software, Software Strategy, 2018, leanpub.com/noprojects.
20. Kelly, Allan, Continuous Digital: An agile alternative to projects for digital business, Software Strategy, 2018, leanpub.com/cdigital.
21. Kersten, Mik, Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework, IT Revolution, 2018, flowframework.org.
22. Hope, Jeremy; Fraser, Robin, Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap, Harvard Business School Press, 2003.
23. Bogsnes, Bjarte, Implementing Beyond Budgeting: Unlocking the Performance Potential, 2nd ed., Wiley, 2016; Beyond Budgeting Round Table, bbrt.org.
24. Grove, Andrew S., High Output Management, Random House, 1983.
25. Doerr, John, Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs, Portfolio/Penguin, 2018.
26. Scaled Agile, Inc., “Lean Portfolio Management”, SAFe Framework, accessed 02/10/2026, framework.scaledagile.com/lean-portfolio-management.
27. Skelton, Matthew; Pais, Manuel, Team Topologies: Organizing Business and Technology Teams for Fast Flow, IT Revolution, 2019; 2nd ed., 2025, teamtopologies.com.
28. Conway, Melvin E., “How Do Committees Invent?”, Datamation, April 1968.
29. Gartner, “Gartner Says 80 Percent of Today’s Project Management Tasks Will Be Eliminated by 2030 as Artificial Intelligence Takes Over”, press release, 20/03/2019, gartner.com.
30. Project Management Institute, Pushing the Limits: Transforming Project Management with GenAI Innovation, 2024, pmi.org.
31. DORA (Google Cloud), Accelerate State of DevOps Report 2024, 2024, dora.dev.
32. DORA (Google Cloud), State of AI-assisted Software Development, 2025, dora.dev/research/ai.
33. Becker, Joel; Rush, Nate; Barnes, Elizabeth; Rein, David (METR), “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, July 2025, metr.org.
34. Flyvbjerg, Bent; Gardner, Dan, How Big Things Get Done, Currency, 2023.
35. Cagan, Marty, Transformed: Moving to the Product Operating Model, Wiley, 2024.
36. Project Management Institute, Talent Gap: Ten-Year Employment Trends, Costs, and Global Implications, 2021, pmi.org.
37. Agile Business Consortium, The DSDM Agile Project Framework, 2014, agilebusiness.org.

Il concetto di gestione dei progetti

Per il Project Management Institute (PMI), un progetto è “uno sforzo temporaneo intrapreso per creare un prodotto, un servizio o un risultato unico”. ^[1] Le due parole che contano sono temporaneo, perché il progetto ha un inizio e una fine definiti, e unico, perché ciò che consegna non è la ripetizione di una routine. È questo che separa un progetto dall’operatività, che è continua e ripetitiva.

La gestione dei progetti, a sua volta, è “l’applicazione di conoscenze, abilità, strumenti e tecniche alle attività di progetto per soddisfarne i requisiti”. ^[1] Sopra il progetto, il PMI definisce altri due livelli:

• Programma: un gruppo di progetti correlati, gestiti in modo coordinato per ottenere benefici che non si otterrebbero gestendoli separatamente.
• Portafoglio: l’insieme di progetti, programmi e attività operative gestiti come un gruppo per raggiungere gli obiettivi strategici dell’organizzazione.

La guida di riferimento del PMI, il PMBOK Guide, è cambiata molto nelle ultime edizioni. La definizione di progetto è la stessa dal 1996, ma il modo di gestirlo è passato da un insieme di processi a un insieme di principi orientati al valore:

Questa evoluzione dice già molto sul tema di questo articolo. Lo stesso PMI riconosce che il centro della gestione non è più rispettare il piano, ma consegnare valore. ^{[1] [2]} Resta la domanda: il progetto, qualcosa di temporaneo e con una fine, è davvero l’unità migliore per gestire un software che, se ha successo, non finisce mai?

Breve storia della gestione dei progetti

Le grandi opere esistono dai tempi delle piramidi, ma la gestione dei progetti come disciplina, con tecniche, ruoli e associazioni proprie, è nata nel Novecento, nell’ingegneria e nell’industria della difesa. ^[3]

1. Anni 1910Henry Gantt diffonde il diagramma a barre per pianificare e seguire la produzione. Più di cento anni dopo, il diagramma di Gantt è ancora l’immagine più associata a un progetto. ^[3]
2. 1942–1946Il Progetto Manhattan mostra come coordinare migliaia di persone, fornitori e fronti di ricerca con una scadenza rigida, e consolida l’idea di un responsabile con autorità su uno sforzo temporaneo. ^[3]
3. 1957–1958DuPont e Remington Rand creano il metodo del percorso critico (CPM), e la Marina degli Stati Uniti, con Booz Allen Hamilton, crea il PERT per il programma missilistico Polaris. Per la prima volta il cronoprogramma diventa un modello matematico. ^{[4] [5]}
4. 1965–1969Nascono le associazioni professionali: l’IPMA in Europa, nel 1965, e il PMI negli Stati Uniti, nel 1969. ^[3]
5. 1970Winston Royce descrive lo sviluppo del software in fasi sequenziali, quello che più tardi sarebbe stato chiamato modello a cascata. Ironia della sorte, lo stesso Royce scrisse che questa versione pura “è rischiosa e invita al fallimento”, e raccomandò di iterare. ^[6]
6. 1986–1995Takeuchi e Nonaka descrivono team che sviluppano prodotti come in una mischia di rugby, lo scrum, e Ken Schwaber e Jeff Sutherland presentano lo Scrum per il software nel 1995. ^{[7] [8]}
7. 1996Il PMI pubblica la prima edizione del PMBOK Guide e il governo britannico lancia PRINCE2. La gestione dei progetti si standardizza e acquisisce certificazioni. ^[3]
8. 2001Diciassette professionisti del software firmano il Manifesto Agile. ^[9]
9. 2017–2025Il PMI pubblica l’Agile Practice Guide con l’Agile Alliance, riscrive il PMBOK attorno a principi e valore nella 7ª edizione e, nell’8ª, incorpora l’IA. ^{[1] [2] [17]}

Un dettaglio di questa storia spiega buona parte delle critiche che seguono: le tecniche classiche sono nate nei cantieri, nelle fabbriche e nei programmi militari, dove l’ambito può essere definito in anticipo e il risultato è fisico. Sono state portate nel software, dove di solito nessuna delle due cose è vera.

Le critiche alla gestione dei progetti applicata all’IT

Già nel 1975 Fred Brooks avvertiva che il software è diverso: è invisibile, cambia di continuo e cresce in complessità. La sua legge più famosa dice che “aggiungere persone a un progetto software in ritardo lo ritarda ancora di più”. ^[10] Da allora, i numeri sui progetti IT non sono incoraggianti:

I numeri vanno letti con attenzione. Il rapporto CHAOS è stato criticato duramente da Eveleens e Verhoef, che hanno mostrato come la sua definizione di successo misuri solo se la stima iniziale è stata rispettata, e non se il progetto ha generato valore. ^[12] Ma gli studi accademici successivi hanno confermato l’essenziale: il rischio dei progetti IT sta nelle code, nei pochi progetti che vanno molto male, e la perdita maggiore non è di tempo, è di valore.

Le critiche più frequenti alla gestione dei progetti applicata all’IT si possono raggruppare così:

• Il presupposto della prevedibilità. La pianificazione dettagliata presuppone che i requisiti siano noti. Nel software l’incertezza iniziale è enorme: Barry Boehm ha mostrato che le stime iniziali possono sbagliare fino a un fattore quattro, in più o in meno, quello che è diventato noto come cono dell’incertezza. ^[16] Nei domini complessi, causa ed effetto diventano chiari solo a posteriori, e la cosa giusta è sperimentare, non pianificare tutto prima. ^[15]
• Il successo misurato sul piano, non sul risultato. Un progetto può finire nei tempi e nel budget e consegnare qualcosa che nessuno usa. Il triangolo di tempi, costi e ambito misura l’aderenza al piano, non il valore per il business.
• Team temporanei. Il progetto forma un team, consegna e lo scioglie. La conoscenza se ne va con le persone, e il sistema passa a un team di manutenzione che non lo ha costruito. Il progetto finisce, ma il software continua.
• Grandi lotti e rischio alla fine. Quando tutto viene consegnato in una volta, i problemi emergono tardi, quando correggerli costa già molto.
• Finanziamento per progetto. Poiché il denaro arriva una volta l’anno e per progetto, le aree imparano a chiedere in grande, ad avviare molti fronti insieme e a difendere l’intero ambito. Il risultato è troppo lavoro in corso e troppo poco consegnato.

Una precisazione doverosa: molte di queste critiche colpiscono la cattiva pratica, non il PMI in sé, che dal 2017 considera legittimi gli approcci adattivi. E Flyvbjerg, uno dei critici più severi, non propone di abbandonare la pianificazione: propone di pianificare lentamente, sulla base di progetti simili del passato, e di eseguire velocemente, in moduli piccoli e ripetibili. ^[34]

Gestione dei progetti tradizionale × metodologia agile

Il Manifesto Agile, del 2001, ha risposto direttamente alle critiche della sezione precedente con quattro valori: ^[9]

Gli individui e le interazioni più che i processi e gli strumenti.
Il software funzionante più che la documentazione esaustiva.
La collaborazione col cliente più che la negoziazione dei contratti.
Rispondere al cambiamento più che seguire un piano.

Ovvero, fermo restando il valore delle voci a destra, consideriamo più importanti le voci a sinistra.

La differenza più visibile tra i due approcci sta in ciò che è fisso e in ciò che è stimato. Nell’approccio tradizionale l’ambito viene fissato all’inizio, e tempi e costi vengono stimati a partire da esso. Nell’agile il triangolo si inverte: tempi e costi sono fissati in cicli brevi, e l’ambito si adatta a ciò che genera più valore.

Il diagramma viene dal DSDM (Dynamic Systems Development Method), uno dei primi metodi agili, creato nel 1994 nel Regno Unito da un consorzio di aziende utenti e fornitrici di tecnologia, il DSDM Consortium, oggi Agile Business Consortium. L’inversione del triangolo è uno dei suoi fondamenti: il DSDM fissa tempi, costi e anche qualità fin dall’inizio, e lascia variare solo le funzionalità, prioritizzate con la tecnica MoSCoW, che separa ciò che è obbligatorio (must), ciò che dovrebbe entrare (should), ciò che potrebbe entrare (could) e ciò che resta fuori questa volta (won’t). ^[37]

In pratica quasi nessuno sta a un estremo. L’Agile Practice Guide e il PMBOK trattano gli approcci come uno spettro, e la maggior parte delle organizzazioni lavora in modo ibrido. ^{[1] [17]} Il modello Cynefin aiuta a scegliere: nei problemi complicati, che un esperto riesce ad analizzare, la pianificazione funziona; nei problemi complessi, solo la sperimentazione rivela la strada. ^[15]

L’agile ha cambiato il modo di lavorare dentro il team, ma spesso non ha cambiato ciò che lo circonda. Forrester lo ha chiamato water-scrum-fall: requisiti e budget definiti a cascata all’inizio, Scrum nel mezzo e rilascio a cascata alla fine. ^[18] Il budget annuale per progetto, gli obiettivi di tempi e ambito e i team temporanei sono rimasti uguali. È proprio lì che agiscono gli approcci della prossima sezione.

Oltre l’attuale gestione dei progetti

Negli ultimi quindici anni è emerso un insieme di idee che non discute come gestire meglio un progetto, ma se il progetto sia l’unità giusta per gestire l’IT. Ognuna affronta un livello diverso dell’organizzazione, e si completano a vicenda:

#NoProjects (Allan Kelly)

• Origine: 2013
• Livello: mentalità
• Sostituisce: il progetto come unità di lavoro

L’hashtag #NoProjects è comparso su Twitter nel 2013, usato da Joshua Arnold, Allan Kelly e Steve Smith. Kelly è diventato il principale autore del movimento con i libri Project Myopia e Continuous Digital, entrambi del 2018. ^{[19] [20]}

L’argomento centrale è semplice: il software di successo non finisce. Finché viene usato, avrà bisogno di modifiche, correzioni e miglioramenti. Trattarlo come un progetto crea date di fine artificiali, scioglie team che hanno appena imparato il dominio e misura il successo con l’aderenza al piano anziché con il valore. Kelly chiama questa visione “miopia da progetto”. ^[19]

Al suo posto propone team stabili che lavorano in modo continuo su un prodotto o un servizio, finanziati come una capacità e non per progetto, e valutati per i risultati che generano.

Attenzione: il nome provoca, ma il movimento non dice che nessun progetto debba esistere. Vale per lo sviluppo continuo di prodotti digitali. Il trasloco di un data center o la sostituzione di un ERP, con un inizio e una fine chiari, restano progetti.

Flow Framework (Mik Kersten, Project to Product)

• Origine: 2018
• Livello: misura
• Sostituisce: le metriche di progetto e di attività

In Project to Product, Mik Kersten sostiene che le aziende stanno gestendo l’era del software con gli strumenti dell’era industriale. ^[21] La sua proposta è gestire flussi di valore, cioè tutto il percorso di una richiesta fino al cliente, e misurare quel flusso con un linguaggio che il business e l’IT capiscano.

Kersten definisce quattro tipi di elemento che attraversano il flusso e cinque metriche per seguirlo:

La distribuzione è la metrica più rivelatrice per la gestione. I quattro tipi di elemento si contendono la stessa capacità: se va tutta alle funzionalità, debito tecnico e rischi si accumulano finché difetti e incidenti iniziano a consumare il team. Kersten insiste anche sul fatto che le metriche di flusso devono essere collegate ai risultati di business, come ricavi, costi, qualità e soddisfazione di clienti e team.

Beyond Budgeting

• Origine: 1998
• Livello: denaro
• Sostituisce: il budget annuale fisso

Il Beyond Budgeting Round Table (BBRT) è nato nel 1998, e Jeremy Hope e Robin Fraser hanno pubblicato il libro che ha dato il nome al movimento nel 2003. ^[22] I casi più noti sono la banca svedese Handelsbanken, che ha abbandonato il budget tradizionale negli anni Settanta, e la norvegese Statoil, oggi Equinor, dove Bjarte Bogsnes ha guidato il cambiamento. ^[23]

L’idea centrale di Bogsnes è che il budget tradizionale mescola tre cose che dovrebbero restare separate:

• Obiettivo: ciò che vogliamo raggiungere. Deve essere ambizioso e, possibilmente, relativo, per esempio rispetto ai concorrenti o alla propria storia.
• Previsione: ciò che pensiamo accadrà. Deve essere realistica e aggiornata di continuo, in un rolling forecast.
• Allocazione delle risorse: quanto liberare e quando. Deve avvenire quando il bisogno si presenta, non una volta l’anno.

Il movimento riassume la proposta in dodici principi, sei di leadership e sei di processi di gestione. Per l’IT la conseguenza è diretta: se il denaro non è più legato a progetti approvati una volta l’anno, diventa possibile finanziare team e prodotti in modo continuo e cambiare rotta a metà anno senza un nuovo iter di approvazione.

OKR

• Origine: anni Settanta
• Livello: direzione
• Sostituisce: gli obiettivi di tempi e ambito

Gli Objectives and Key Results sono nati in Intel con Andy Grove, che li ha descritti in High Output Management, del 1983. ^[24] John Doerr ha portato il metodo in Google nel 1999 e lo ha reso popolare con il libro Measure What Matters, del 2018. ^[25] La formula di Doerr è: “Farò [obiettivo] misurato da [risultati chiave]”.

Il cambiamento per l’IT sta in ciò che si misura. Invece di “consegnare il progetto del nuovo portale entro giugno”, l’OKR descrive il risultato atteso. L’esempio seguente è puramente illustrativo: è stato creato per questo articolo, e la situazione, i numeri e gli obiettivi sono fittizi.

Esempio illustrativo

Obiettivo: rendere l’acquisto di un’assicurazione dal cellulare abbastanza semplice da non aver bisogno dell’agente.

Risultati chiave: ridurre il tempo medio di acquisto da 25 a 8 minuti; portare dal 30% al 55% gli acquisti completati senza aiuto; mantenere il voto di soddisfazione sopra 4,5.

Così il team ha libertà di scoprire cosa costruire, e l’ambito diventa un’ipotesi, non un impegno. Attenzione a: risultati chiave che sono solo attività (“lanciare il portale”), troppi OKR e l’uso degli OKR nella valutazione individuale e nei bonus, che Doerr raccomanda di separare per non incoraggiare obiettivi timidi. ^[25]

Il paradosso dell’ambito

A mio avviso, c’è un paradosso nel cercare di delimitare con precisione ciò che è intangibile. Definire nel dettaglio l’ambito di qualcosa che non si conosce ancora del tutto, come l’esperienza dell’utente, il guadagno di produttività di un team o il valore di una nuova capacità, può costare più tempo e risorse del valore che la consegna genererà nel periodo in cui verrà usata.

Il cono dell’incertezza aiuta a spiegare perché: all’inizio, ogni dettaglio specificato ha un’alta probabilità di cambiare, e lo sforzo per definirlo va perso. ^[16] In questi casi conviene fissare il risultato atteso, come fa un OKR, e lasciare che l’ambito venga scoperto in cicli brevi, misurando l’avanzamento con i risultati chiave.

È ciò che propone il monitoraggio del business: invece di specificare fin dall’inizio tutti gli indicatori e le regole, parte da pochi indicatori per i processi che contano di più, muove dalle domande del business e lascia che ogni incidente mostri cosa resta ancora da misurare.

Regola pratica: conviene dettagliare l’ambito solo quando il costo di definirlo è chiaramente inferiore al valore della consegna moltiplicato per il tempo in cui verrà sfruttata.

Lean Portfolio Management (SAFe)

• Origine: SAFe, anni 2010
• Livello: denaro
• Sostituisce: il PPM basato sui progetti

Lo Scaled Agile Framework (SAFe) definisce il Lean Portfolio Management (LPM) come la funzione che allinea strategia ed esecuzione in un portafoglio agile. Ha tre dimensioni: strategia e finanziamento degli investimenti, operazioni agili del portafoglio e governance lean. ^[26]

• Budget per flusso di valore: il denaro va ai flussi di valore e ai loro team, non ai progetti. I responsabili decidono come usarlo entro limiti concordati, i guardrail.
• Budget partecipativo: i leader del business e dell’IT ripartiscono insieme il budget tra i flussi di valore, in cicli brevi, invece di una negoziazione annuale.
• Kanban del portafoglio: le grandi iniziative, chiamate epic, attraversano un flusso visibile, con un business case snello e un prodotto minimo funzionante prima di ricevere altri investimenti.
• Governance lean: conformità e audit continui, con metriche di flusso, al posto dei cancelli di approvazione fase per fase.

Il SAFe è criticato per essere prescrittivo e pesante, ma le idee dell’LPM si possono applicare anche senza adottare il resto del framework. In pratica sono la traduzione del Beyond Budgeting per il portafoglio IT.

Team Topologies

• Origine: 2019 (2ª edizione nel 2025)
• Livello: struttura
• Sostituisce: i team formati per progetto

Matthew Skelton e Manuel Pais partono dalla legge di Conway, del 1968: le organizzazioni producono sistemi che copiano la loro struttura di comunicazione. ^{[27] [28]} Se l’architettura che vogliamo dipende da come sono organizzati i team, la struttura dei team va progettata di proposito, e non lasciata al caso di ogni progetto.

Il libro propone team stabili, con un carico cognitivo sostenibile, di soli quattro tipi, e tre modalità di interazione tra loro:

Per la gestione dei progetti, la conseguenza è l’inversione del flusso: invece di formare un team per ogni progetto, il lavoro viene portato ai team che già esistono. La domanda non è più “chi è libero per questo progetto?” ma “quale flusso di valore è titolare di questo cambiamento?”.

IA applicata direttamente ai progetti

• Origine: anni 2020
• Livello: tutti
• Sostituisce: buona parte del lavoro amministrativo

Nel 2019 Gartner ha previsto che entro il 2030 l’80% del lavoro di gestione dei progetti di allora sarebbe stato eliminato, con l’IA che si sarebbe fatta carico di raccolta dati, monitoraggio e reportistica. ^[29] L’adozione sta accelerando: nel 2024 il PMI ha rilevato che il gruppo di professionisti che usa l’IA generativa in più della metà dei progetti è cresciuto dell’86% in un anno, e rappresenta già circa due intervistati su cinque. ^[30]

I dati sull’effetto reale, però, invitano alla prudenza. Nel rapporto DORA 2024, un aumento del 25% nell’adozione dell’IA si è accompagnato a un calo stimato dell’1,5% nel throughput delle consegne e del 7,2% nella stabilità. ^[31] Nel 2025 il throughput ha cominciato a migliorare, ma l’instabilità ha continuato a crescere, e il DORA ha concluso che l’IA è un amplificatore: amplifica i punti di forza delle organizzazioni che già funzionano bene e le disfunzioni di quelle che non funzionano. ^[32] In un esperimento controllato del METR, sviluppatori esperti hanno impiegato il 19% di tempo in più con gli strumenti di IA, pur credendo di essere diventati più veloci. ^[33]

La lezione si collega alle altre idee di questa sezione: accelerare una fase non accelera l’intero flusso. Se l’IA fa uscire il codice più in fretta, ma approvazione, test e rilascio restano uguali, il collo di bottiglia si sposta soltanto. L’IA rende di più dove il flusso di valore è già visibile e misurato.

Il futuro

Nessuna di queste idee sostituisce da sola la gestione dei progetti. Quello che si vede è una convergenza: ognuna risolve una parte del problema, e insieme disegnano un modello di gestione dell’IT diverso da quello attuale. Marty Cagan chiama questo insieme modello operativo di prodotto. ^[35] Le tendenze qui sotto sono la mia lettura delle fonti citate:

Tre precisazioni rendono questo futuro più realistico:

• I progetti non scompariranno. Migrazioni, implementazioni di ERP, fusioni, obblighi normativi e lavori infrastrutturali hanno un inizio e una fine reali. Per loro le tecniche classiche, unite alle lezioni di Flyvbjerg sulla pianificazione per classi di riferimento e sulle consegne modulari, restano valide. ^[34]
• Le competenze di progetto varranno di più, non di meno. Il PMI stima che il mondo avrà bisogno di 25 milioni di nuovi professionisti di progetto entro il 2030. ^[36] Cambia il contenuto del lavoro: meno aggiornamento dei cronoprogrammi e più negoziazione, definizione delle priorità, gestione dei rischi e leadership, le competenze che l’IA non sostituisce.
• Il collo di bottiglia si sposterà. Se l’IA riduce il costo di costruire, la risorsa scarsa diventa decidere cosa costruire e verificare se ha funzionato. Questo favorisce scommesse più piccole e frequenti, cicli di finanziamento brevi e una misura onesta dei risultati, esattamente ciò che propongono gli approcci di questo articolo. È la lezione della Teoria dei Vincoli di Goldratt: un sistema produce solo al ritmo del suo collo di bottiglia e, quando un vincolo viene eliminato, un altro ne prende il posto. Accelerare la scrittura del codice senza guardare al nuovo vincolo accumula soltanto lavoro fermo davanti a esso.

Conclusioni

La gestione dei progetti è nata nei cantieri e nei programmi militari, dove l’ambito poteva essere definito prima e il risultato era fisico. Portata nell’IT, ha portato disciplina, ma anche un presupposto che il software raramente rispetta: che sia possibile sapere tutto all’inizio. Gli studi di Flyvbjerg e di McKinsey mostrano che la perdita maggiore dei progetti IT non è il ritardo, è il valore che non viene consegnato.

L’agile ha corretto il modo di lavorare dentro i team, ma ha lasciato intatti il budget annuale, gli obiettivi di ambito e i team temporanei. Gli approcci che vanno oltre i progetti agiscono proprio su questi livelli: il #NoProjects cambia l’unità di lavoro, gli OKR cambiano la direzione, il Beyond Budgeting e il Lean Portfolio Management cambiano il denaro, il Team Topologies cambia la struttura e il Flow Framework cambia la misura.

L’IA assorbirà buona parte del lavoro amministrativo della gestione, ma da sola non sistema un flusso progettato male; amplifica ciò che già esiste. Il futuro dei progetti IT, quindi, non è la fine della gestione. È il passaggio da una gestione centrata sul piano a una gestione centrata sul flusso di valore, con team stabili, denaro che segue i risultati e responsabili che dedicano il tempo liberato dall’IA alle decisioni che contano.

Riferimenti

1. Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Seventh Edition and The Standard for Project Management, PMI, 2021.
2. Project Management Institute, PMBOK Guide – Eighth Edition, PMI, 2025, pmi.org/pmbok-guide.
3. Garel, Gilles, “A history of project management models: From pre-models to the standard models”, International Journal of Project Management, vol. 31, n. 5, pp. 663–669, 2013.
4. Kelley, James E.; Walker, Morgan R., “Critical-Path Planning and Scheduling”, Proceedings of the Eastern Joint Computer Conference, 1959.
5. Malcolm, D. G.; Roseboom, J. H.; Clark, C. E.; Fazar, W., “Application of a Technique for Research and Development Program Evaluation”, Operations Research, vol. 7, n. 5, 1959.
6. Royce, Winston W., “Managing the Development of Large Software Systems”, Proceedings of IEEE WESCON, 1970.
7. Takeuchi, Hirotaka; Nonaka, Ikujiro, “The New New Product Development Game”, Harvard Business Review, gennaio 1986.
8. Schwaber, Ken, “SCRUM Development Process”, OOPSLA Business Object Design and Implementation Workshop, 1995.
9. Beck, Kent et al., Manifesto per lo Sviluppo Agile di Software, 2001, agilemanifesto.org.
10. Brooks, Frederick P., The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, 1975.
11. The Standish Group, The CHAOS Report, 1994.
12. Eveleens, J. Laurenz; Verhoef, Chris, “The Rise and Fall of the Chaos Report Figures”, IEEE Software, vol. 27, n. 1, pp. 30–36, 2010, ieeexplore.ieee.org/document/5232804.
13. Flyvbjerg, Bent; Budzier, Alexander, “Why Your IT Project May Be Riskier Than You Think”, Harvard Business Review, settembre 2011, arxiv.org/abs/1304.0265.
14. Bloch, Michael; Blumberg, Sven; Laartz, Jürgen, “Delivering large-scale IT projects on time, on budget, and on value”, McKinsey & Company, 2012, mckinsey.com.
15. Snowden, David J.; Boone, Mary E., “A Leader’s Framework for Decision Making”, Harvard Business Review, novembre 2007.
16. Boehm, Barry W., Software Engineering Economics, Prentice Hall, 1981.
17. Project Management Institute; Agile Alliance, Agile Practice Guide, PMI, 2017.
18. West, Dave, “Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today”, Forrester Research, 2011.
19. Kelly, Allan, Project Myopia: Why projects damage software, Software Strategy, 2018, leanpub.com/noprojects.
20. Kelly, Allan, Continuous Digital: An agile alternative to projects for digital business, Software Strategy, 2018, leanpub.com/cdigital.
21. Kersten, Mik, Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework, IT Revolution, 2018, flowframework.org.
22. Hope, Jeremy; Fraser, Robin, Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap, Harvard Business School Press, 2003.
23. Bogsnes, Bjarte, Implementing Beyond Budgeting: Unlocking the Performance Potential, 2ª ed., Wiley, 2016; Beyond Budgeting Round Table, bbrt.org.
24. Grove, Andrew S., High Output Management, Random House, 1983.
25. Doerr, John, Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs, Portfolio/Penguin, 2018.
26. Scaled Agile, Inc., “Lean Portfolio Management”, SAFe Framework, consultato il 02/10/2026, framework.scaledagile.com/lean-portfolio-management.
27. Skelton, Matthew; Pais, Manuel, Team Topologies: Organizing Business and Technology Teams for Fast Flow, IT Revolution, 2019; 2ª ed., 2025, teamtopologies.com.
28. Conway, Melvin E., “How Do Committees Invent?”, Datamation, aprile 1968.
29. Gartner, “Gartner Says 80 Percent of Today’s Project Management Tasks Will Be Eliminated by 2030 as Artificial Intelligence Takes Over”, comunicato stampa, 20/03/2019, gartner.com.
30. Project Management Institute, Pushing the Limits: Transforming Project Management with GenAI Innovation, 2024, pmi.org.
31. DORA (Google Cloud), Accelerate State of DevOps Report 2024, 2024, dora.dev.
32. DORA (Google Cloud), State of AI-assisted Software Development, 2025, dora.dev/research/ai.
33. Becker, Joel; Rush, Nate; Barnes, Elizabeth; Rein, David (METR), “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, luglio 2025, metr.org.
34. Flyvbjerg, Bent; Gardner, Dan, How Big Things Get Done, Currency, 2023.
35. Cagan, Marty, Transformed: Moving to the Product Operating Model, Wiley, 2024.
36. Project Management Institute, Talent Gap: Ten-Year Employment Trends, Costs, and Global Implications, 2021, pmi.org.
37. Agile Business Consortium, The DSDM Agile Project Framework, 2014, agilebusiness.org.

El concepto de gestión de proyectos

Para el Project Management Institute (PMI), un proyecto es “un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único”. ^[1] Las dos palabras que importan son temporal, porque el proyecto tiene un inicio y un fin definidos, y único, porque lo que entrega no es la repetición de una rutina. Eso es lo que separa un proyecto de la operación, que es continua y repetitiva.

La gestión de proyectos, a su vez, es “la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para cumplir con sus requisitos”. ^[1] Por encima del proyecto, el PMI define dos niveles más:

• Programa: un grupo de proyectos relacionados, gestionados de forma coordinada para obtener beneficios que no se obtendrían gestionándolos por separado.
• Portafolio: el conjunto de proyectos, programas y operaciones gestionados como un grupo para alcanzar los objetivos estratégicos de la organización.

La guía de referencia del PMI, la PMBOK Guide, cambió mucho en sus últimas ediciones. La definición de proyecto es la misma desde 1996, pero la forma de gestionarlo pasó de ser un conjunto de procesos a ser un conjunto de principios orientados al valor:

Esta evolución ya dice mucho sobre el tema de este artículo. El propio PMI reconoce que el centro de la gestión ya no es cumplir el plan, sino entregar valor. ^{[1] [2]} La pregunta que queda es si el proyecto, algo temporal y con fin, es la mejor unidad para gestionar un software que, si tiene éxito, nunca termina.

Breve historia de la gestión de proyectos

Las grandes obras existen desde las pirámides, pero la gestión de proyectos como disciplina, con técnicas, roles y asociaciones propias, nació en el siglo XX, en la ingeniería y en la industria de defensa. ^[3]

1. Década de 1910Henry Gantt populariza el diagrama de barras para planificar y seguir la producción. Más de cien años después, el diagrama de Gantt sigue siendo la imagen más asociada a un proyecto. ^[3]
2. 1942–1946El Proyecto Manhattan muestra cómo coordinar a miles de personas, proveedores y frentes de investigación con un plazo rígido, y consolida la idea de un gerente con autoridad sobre un esfuerzo temporal. ^[3]
3. 1957–1958DuPont y Remington Rand crean el método de la ruta crítica (CPM), y la Marina de los Estados Unidos, con Booz Allen Hamilton, crea el PERT para el programa de misiles Polaris. Por primera vez, el cronograma se convierte en un modelo matemático. ^{[4] [5]}
4. 1965–1969Nacen las asociaciones profesionales: el IPMA en Europa, en 1965, y el PMI en los Estados Unidos, en 1969. ^[3]
5. 1970Winston Royce describe el desarrollo de software en fases secuenciales, lo que más tarde se llamaría cascada. Irónicamente, el propio Royce escribió que esa versión pura “es arriesgada e invita al fracaso”, y recomendó iterar. ^[6]
6. 1986–1995Takeuchi y Nonaka describen equipos que desarrollan productos como en un scrum de rugby, y Ken Schwaber y Jeff Sutherland presentan Scrum para software en 1995. ^{[7] [8]}
7. 1996El PMI publica la primera edición de la PMBOK Guide y el gobierno británico lanza PRINCE2. La gestión de proyectos se estandariza y gana certificaciones. ^[3]
8. 2001Diecisiete profesionales del software firman el Manifiesto Ágil. ^[9]
9. 2017–2025El PMI publica la Agile Practice Guide con la Agile Alliance, reescribe el PMBOK en torno a principios y valor en la 7.ª edición y, en la 8.ª, incorpora la IA. ^{[1] [2] [17]}

Un detalle de esta historia explica buena parte de las críticas que siguen: las técnicas clásicas nacieron en obras, fábricas y programas militares, donde el alcance puede definirse de antemano y el resultado es físico. Se llevaron al software, donde normalmente ninguna de las dos cosas es cierta.

Las críticas a la gestión de proyectos aplicada a TI

Ya en 1975, Fred Brooks advertía que el software es distinto: es invisible, cambia todo el tiempo y crece en complejidad. Su ley más famosa dice que “añadir personas a un proyecto de software retrasado lo retrasa todavía más”. ^[10] Desde entonces, las cifras sobre proyectos de TI no son alentadoras:

Las cifras deben leerse con cuidado. El informe CHAOS fue duramente criticado por Eveleens y Verhoef, que mostraron que su definición de éxito solo mide si se cumplió la estimación inicial, y no si el proyecto generó valor. ^[12] Pero los estudios académicos posteriores confirmaron lo esencial: el riesgo de los proyectos de TI está en las colas, en los pocos proyectos que salen muy mal, y la mayor pérdida no es de plazo, es de valor.

Las críticas más frecuentes a la gestión de proyectos aplicada a TI pueden agruparse así:

• La premisa de la previsibilidad. La planificación detallada supone que los requisitos son conocidos. En software, la incertidumbre al inicio es enorme: Barry Boehm mostró que las estimaciones iniciales pueden equivocarse hasta por un factor de cuatro, hacia arriba o hacia abajo, lo que se conoce como cono de incertidumbre. ^[16] En dominios complejos, causa y efecto solo se aclaran a posteriori, y lo correcto es experimentar, no planificarlo todo antes. ^[15]
• El éxito medido por el plan, no por el resultado. Un proyecto puede terminar en plazo y presupuesto y entregar algo que nadie usa. El triángulo de plazo, costo y alcance mide la obediencia al plan, no el valor para el negocio.
• Equipos temporales. El proyecto forma un equipo, entrega y lo disuelve. El conocimiento se va con las personas, y el sistema pasa a un equipo de mantenimiento que no lo construyó. El proyecto termina, pero el software sigue.
• Lotes grandes y riesgo al final. Cuando todo se entrega de una vez, los problemas aparecen tarde, cuando ya es caro corregirlos.
• Financiación por proyecto. Como el dinero llega una vez al año y por proyecto, las áreas aprenden a pedir en grande, abrir muchos frentes a la vez y defender todo el alcance. El resultado es demasiado trabajo en curso y muy poco entregado.

Una salvedad justa: muchas de estas críticas apuntan a la mala práctica, no al PMI en sí, que desde 2017 trata los enfoques adaptativos como legítimos. Y Flyvbjerg, uno de los críticos más duros, no propone abandonar la planificación: propone planificar despacio, con base en proyectos similares del pasado, y ejecutar rápido, en módulos pequeños y repetibles. ^[34]

Gestión de proyectos tradicional × metodología ágil

El Manifiesto Ágil, de 2001, respondió directamente a las críticas de la sección anterior con cuatro valores: ^[9]

Individuos e interacciones sobre procesos y herramientas.
Software funcionando sobre documentación extensiva.
Colaboración con el cliente sobre negociación contractual.
Respuesta ante el cambio sobre seguir un plan.

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

La diferencia más visible entre los dos enfoques está en qué es fijo y qué se estima. En el enfoque tradicional, el alcance se fija al inicio, y el plazo y el costo se estiman a partir de él. En el ágil, el triángulo se invierte: plazo y costo se fijan en ciclos cortos, y el alcance se ajusta a lo que genera más valor.

El diagrama viene del DSDM (Dynamic Systems Development Method), uno de los primeros métodos ágiles, creado en 1994 en el Reino Unido por un consorcio de empresas usuarias y proveedoras de tecnología, el DSDM Consortium, hoy Agile Business Consortium. La inversión del triángulo es uno de sus fundamentos: el DSDM fija plazo, costo y también calidad desde el inicio, y deja variar solo las funcionalidades, priorizadas con la técnica MoSCoW, que separa lo obligatorio (must), lo que debería entrar (should), lo que podría entrar (could) y lo que queda fuera esta vez (won’t). ^[37]

En la práctica, casi nadie está en un extremo. La Agile Practice Guide y el PMBOK tratan los enfoques como un espectro, y la mayoría de las organizaciones trabaja de forma híbrida. ^{[1] [17]} El modelo Cynefin ayuda a elegir: en problemas complicados, que un experto puede analizar, la planificación funciona; en problemas complejos, solo la experimentación revela el camino. ^[15]

El ágil cambió la forma de trabajar dentro del equipo, pero muchas veces no cambió lo que lo rodea. Forrester lo llamó water-scrum-fall: requisitos y presupuesto definidos en cascada al inicio, Scrum en el medio y despliegue en cascada al final. ^[18] El presupuesto anual por proyecto, las metas de plazo y alcance y los equipos temporales siguieron iguales. Justamente ahí actúan los enfoques de la siguiente sección.

Más allá de la gestión actual de proyectos

En los últimos quince años surgió un conjunto de ideas que no discute cómo gestionar mejor un proyecto, sino si el proyecto es la unidad correcta para gestionar TI. Cada una ataca una capa distinta de la organización, y se complementan entre sí:

#NoProjects (Allan Kelly)

• Origen: 2013
• Capa: mentalidad
• Sustituye: el proyecto como unidad de trabajo

El hashtag #NoProjects surgió en Twitter en 2013, usado por Joshua Arnold, Allan Kelly y Steve Smith. Kelly se convirtió en el principal autor del movimiento con los libros Project Myopia y Continuous Digital, ambos de 2018. ^{[19] [20]}

El argumento central es simple: el software exitoso no termina. Mientras se use, necesitará cambios, correcciones y mejoras. Tratarlo como proyecto crea fechas de fin artificiales, disuelve equipos que acaban de aprender el dominio y mide el éxito por el cumplimiento del plan, no por el valor. Kelly llama a esta visión “miopía de proyecto”. ^[19]

En su lugar, propone equipos estables que trabajan de forma continua sobre un producto o servicio, financiados como una capacidad y no por proyecto, y evaluados por los resultados que generan.

Cuidado: el nombre provoca, pero el movimiento no dice que no deba existir ningún proyecto. Vale para el desarrollo continuo de productos digitales. La mudanza de un centro de datos o el cambio de un ERP, con inicio y fin claros, siguen siendo proyectos.

Flow Framework (Mik Kersten, Project to Product)

• Origen: 2018
• Capa: medición
• Sustituye: las métricas de proyecto y de actividad

En Project to Product, Mik Kersten sostiene que las empresas están gestionando la era del software con herramientas de la era industrial. ^[21] Su propuesta es gestionar flujos de valor, todo el camino desde una demanda hasta el cliente, y medir ese flujo con un lenguaje que el negocio y TI entiendan.

Kersten define cuatro tipos de ítem que pasan por el flujo y cinco métricas para seguirlo:

La distribución es la métrica más reveladora para la gestión. Los cuatro tipos de ítem compiten por la misma capacidad: si toda va a funcionalidades, la deuda técnica y los riesgos se acumulan hasta que los defectos y los incidentes empiezan a consumir al equipo. Kersten también insiste en que las métricas de flujo deben vincularse a resultados de negocio, como ingresos, costos, calidad y satisfacción de clientes y equipos.

Beyond Budgeting

• Origen: 1998
• Capa: dinero
• Sustituye: el presupuesto anual fijo

El Beyond Budgeting Round Table (BBRT) nació en 1998, y Jeremy Hope y Robin Fraser publicaron el libro que dio nombre al movimiento en 2003. ^[22] Los casos más conocidos son el banco sueco Handelsbanken, que abandonó el presupuesto tradicional en los años setenta, y la noruega Statoil, hoy Equinor, donde Bjarte Bogsnes lideró el cambio. ^[23]

La idea central de Bogsnes es que el presupuesto tradicional mezcla tres cosas que deberían estar separadas:

• Meta: lo que queremos lograr. Debe ser ambiciosa y, de preferencia, relativa, por ejemplo en comparación con la competencia o con el propio histórico.
• Previsión: lo que creemos que va a pasar. Debe ser realista y revisarse siempre, en un rolling forecast.
• Asignación de recursos: cuánto liberar y cuándo. Debe ocurrir cuando aparece la necesidad, no una vez al año.

El movimiento resume la propuesta en doce principios, seis de liderazgo y seis de procesos de gestión. Para TI la consecuencia es directa: si el dinero deja de estar atado a proyectos aprobados una vez al año, se puede financiar equipos y productos de forma continua y cambiar el rumbo a mitad de año sin un nuevo proceso de aprobación.

OKR

• Origen: años setenta
• Capa: dirección
• Sustituye: las metas de plazo y alcance

Los Objectives and Key Results nacieron en Intel con Andy Grove, que los describió en High Output Management, de 1983. ^[24] John Doerr llevó el método a Google en 1999 y lo popularizó con el libro Measure What Matters, de 2018. ^[25] La fórmula de Doerr es: “Voy a [objetivo] medido por [resultados clave]”.

El cambio para TI está en lo que se mide. En lugar de “entregar el proyecto del nuevo portal antes de junio”, el OKR describe el resultado esperado. El ejemplo siguiente es solo ilustrativo: fue creado para este artículo, y la situación, las cifras y las metas son ficticias.

Ejemplo ilustrativo

Objetivo: hacer que contratar un seguro desde el móvil sea tan simple que no haga falta el corredor.

Resultados clave: reducir el tiempo medio de contratación de 25 a 8 minutos; aumentar del 30% al 55% las contrataciones completadas sin ayuda; mantener la nota de satisfacción por encima de 4,5.

Así el equipo gana libertad para descubrir qué construir, y el alcance pasa a ser una hipótesis, no un compromiso. Cuidados: resultados clave que son solo tareas (“lanzar el portal”), demasiados OKR y el uso de los OKR en la evaluación individual y en el bono, que Doerr recomienda separar para no estimular metas tímidas. ^[25]

La paradoja del alcance

En mi opinión, existe una paradoja en intentar delimitar con precisión lo que es intangible. Definir en detalle el alcance de algo que todavía no se conoce del todo, como la experiencia del usuario, la ganancia de productividad de un equipo o el valor de una nueva capacidad, puede consumir más tiempo y recursos que el valor que la entrega generará durante el tiempo en que se use.

El cono de incertidumbre ayuda a explicar por qué: al inicio, cada detalle especificado tiene una alta probabilidad de cambiar, y el esfuerzo de definirlo se pierde. ^[16] En esos casos, resulta más barato fijar el resultado esperado, como hace un OKR, y dejar que el alcance se descubra en ciclos cortos, midiendo el avance con los resultados clave.

Esto es lo que propone el monitoreo de negocio: en lugar de especificar desde el inicio todos los indicadores y reglas, empieza con pocos indicadores para los procesos que más importan, parte de las preguntas del negocio y deja que cada incidente muestre lo que todavía falta medir.

Regla práctica: solo vale la pena detallar el alcance cuando el costo de definirlo es claramente menor que el valor de la entrega multiplicado por el tiempo durante el cual se aprovechará.

Lean Portfolio Management (SAFe)

• Origen: SAFe, años 2010
• Capa: dinero
• Sustituye: el PPM basado en proyectos

El Scaled Agile Framework (SAFe) define el Lean Portfolio Management (LPM) como la función que alinea estrategia y ejecución en un portafolio ágil. Tiene tres dimensiones: estrategia y financiación de inversiones, operaciones ágiles del portafolio y gobierno lean. ^[26]

• Presupuesto por flujo de valor: el dinero va a los flujos de valor y sus equipos, no a proyectos. Los responsables deciden cómo usarlo dentro de límites acordados, los guardrails.
• Presupuesto participativo: los líderes del negocio y de TI reparten juntos el presupuesto entre los flujos de valor, en ciclos cortos, en lugar de una negociación anual.
• Kanban del portafolio: las grandes iniciativas, llamadas épicas, pasan por un flujo visible, con un caso de negocio ligero y un producto mínimo viable antes de recibir más inversión.
• Gobierno lean: cumplimiento y auditoría continuos, con métricas de flujo, en lugar de puertas de aprobación fase por fase.

SAFe recibe críticas por ser prescriptivo y pesado, pero las ideas del LPM pueden aplicarse sin adoptar el resto del framework. En la práctica, son la traducción del Beyond Budgeting al portafolio de TI.

Team Topologies

• Origen: 2019 (2.ª edición en 2025)
• Capa: estructura
• Sustituye: los equipos formados por proyecto

Matthew Skelton y Manuel Pais parten de la ley de Conway, de 1968: las organizaciones producen sistemas que copian su estructura de comunicación. ^{[27] [28]} Si la arquitectura que queremos depende de cómo están organizados los equipos, la estructura de los equipos debe diseñarse a propósito, y no quedar a merced de cada proyecto.

El libro propone equipos estables, con una carga cognitiva que puedan asumir, de solo cuatro tipos, y tres modos de interacción entre ellos:

Para la gestión de proyectos, la consecuencia es la inversión del flujo: en lugar de formar un equipo para cada proyecto, el trabajo se lleva a los equipos que ya existen. La pregunta deja de ser “¿quién está libre para este proyecto?” y pasa a ser “¿qué flujo de valor es dueño de este cambio?”.

IA aplicada directamente a los proyectos

• Origen: años 2020
• Capa: todas
• Sustituye: buena parte del trabajo administrativo

En 2019, Gartner previó que, para 2030, el 80% del trabajo de gestión de proyectos de entonces sería eliminado, con la IA asumiendo la recopilación de datos, el seguimiento y los informes. ^[29] La adopción se está acelerando: en 2024, el PMI registró que el grupo de profesionales que usa IA generativa en más de la mitad de sus proyectos creció un 86% en un año, y ya son cerca de dos de cada cinco encuestados. ^[30]

Los datos sobre el efecto real, sin embargo, piden cautela. En el informe DORA de 2024, un aumento del 25% en la adopción de IA vino acompañado de una caída estimada del 1,5% en el rendimiento de entregas y del 7,2% en la estabilidad. ^[31] En 2025, el rendimiento empezó a mejorar, pero la inestabilidad siguió creciendo, y DORA concluyó que la IA es un amplificador: aumenta las fortalezas de las organizaciones que ya funcionan bien y las disfunciones de las que no. ^[32] En un experimento controlado de METR, desarrolladores experimentados tardaron un 19% más con herramientas de IA, aunque creían que se habían vuelto más rápidos. ^[33]

La lección se conecta con las demás ideas de esta sección: acelerar una etapa no acelera el flujo completo. Si la IA hace que el código salga más rápido, pero la aprobación, las pruebas y el despliegue siguen igual, el cuello de botella solo cambia de lugar. La IA rinde más donde el flujo de valor ya es visible y está medido.

El futuro

Ninguna de estas ideas sustituye por sí sola la gestión de proyectos. Lo que se ve es una convergencia: cada una resuelve una parte del problema, y juntas dibujan un modelo de gestión de TI distinto del actual. Marty Cagan llama a este conjunto modelo operativo de producto. ^[35] Las tendencias siguientes son mi lectura de las fuentes citadas:

Tres salvedades hacen este futuro más realista:

• Los proyectos no van a desaparecer. Migraciones, implantaciones de ERP, fusiones, exigencias regulatorias y obras de infraestructura tienen un inicio y un fin reales. Para ellos, las técnicas clásicas, sumadas a las lecciones de Flyvbjerg sobre planificación por clase de referencia y entregas modulares, siguen siendo válidas. ^[34]
• Las competencias de proyecto valdrán más, no menos. El PMI estima que el mundo necesitará 25 millones de nuevos profesionales de proyectos para 2030. ^[36] Lo que cambia es el contenido del trabajo: menos actualización de cronogramas y más negociación, priorización, gestión de riesgos y liderazgo, las competencias que la IA no sustituye.
• El cuello de botella va a migrar. Si la IA reduce el costo de construir, el recurso escaso pasa a ser decidir qué construir y validar si funcionó. Eso favorece apuestas más pequeñas y frecuentes, ciclos cortos de financiación y una medición honesta de los resultados, exactamente lo que proponen los enfoques de este artículo. Es la lección de la Teoría de las Restricciones de Goldratt: un sistema solo entrega al ritmo de su cuello de botella y, cuando se elimina una restricción, otra ocupa su lugar. Acelerar la codificación sin mirar la nueva restricción solo acumula trabajo detenido frente a ella.

Conclusiones

La gestión de proyectos nació en obras y programas militares, donde el alcance podía definirse antes y el resultado era físico. Llevada a TI, aportó disciplina, pero también una premisa que el software rara vez cumple: la de que es posible saberlo todo al inicio. Los estudios de Flyvbjerg y de McKinsey muestran que la mayor pérdida de los proyectos de TI no es el retraso, es el valor que deja de entregarse.

El ágil corrigió la forma de trabajar dentro de los equipos, pero dejó intactos el presupuesto anual, las metas de alcance y los equipos temporales. Los enfoques que van más allá de los proyectos atacan justamente esas capas: #NoProjects cambia la unidad de trabajo, los OKR cambian la dirección, Beyond Budgeting y Lean Portfolio Management cambian el dinero, Team Topologies cambia la estructura y el Flow Framework cambia la medición.

La IA absorberá buena parte del trabajo administrativo de la gestión, pero no arregla por sí sola un flujo mal diseñado; amplifica lo que ya existe. El futuro de los proyectos de TI, por lo tanto, no es el fin de la gestión. Es el paso de una gestión centrada en el plan a una gestión centrada en el flujo de valor, con equipos estables, dinero que acompaña los resultados y gerentes que dedican el tiempo liberado por la IA a las decisiones que importan.

Referencias

1. Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Seventh Edition and The Standard for Project Management, PMI, 2021.
2. Project Management Institute, PMBOK Guide – Eighth Edition, PMI, 2025, pmi.org/pmbok-guide.
3. Garel, Gilles, “A history of project management models: From pre-models to the standard models”, International Journal of Project Management, vol. 31, n.º 5, pp. 663–669, 2013.
4. Kelley, James E.; Walker, Morgan R., “Critical-Path Planning and Scheduling”, Proceedings of the Eastern Joint Computer Conference, 1959.
5. Malcolm, D. G.; Roseboom, J. H.; Clark, C. E.; Fazar, W., “Application of a Technique for Research and Development Program Evaluation”, Operations Research, vol. 7, n.º 5, 1959.
6. Royce, Winston W., “Managing the Development of Large Software Systems”, Proceedings of IEEE WESCON, 1970.
7. Takeuchi, Hirotaka; Nonaka, Ikujiro, “The New New Product Development Game”, Harvard Business Review, enero de 1986.
8. Schwaber, Ken, “SCRUM Development Process”, OOPSLA Business Object Design and Implementation Workshop, 1995.
9. Beck, Kent et al., Manifiesto por el Desarrollo Ágil de Software, 2001, agilemanifesto.org.
10. Brooks, Frederick P., The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, 1975.
11. The Standish Group, The CHAOS Report, 1994.
12. Eveleens, J. Laurenz; Verhoef, Chris, “The Rise and Fall of the Chaos Report Figures”, IEEE Software, vol. 27, n.º 1, pp. 30–36, 2010, ieeexplore.ieee.org/document/5232804.
13. Flyvbjerg, Bent; Budzier, Alexander, “Why Your IT Project May Be Riskier Than You Think”, Harvard Business Review, septiembre de 2011, arxiv.org/abs/1304.0265.
14. Bloch, Michael; Blumberg, Sven; Laartz, Jürgen, “Delivering large-scale IT projects on time, on budget, and on value”, McKinsey & Company, 2012, mckinsey.com.
15. Snowden, David J.; Boone, Mary E., “A Leader’s Framework for Decision Making”, Harvard Business Review, noviembre de 2007.
16. Boehm, Barry W., Software Engineering Economics, Prentice Hall, 1981.
17. Project Management Institute; Agile Alliance, Agile Practice Guide, PMI, 2017.
18. West, Dave, “Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today”, Forrester Research, 2011.
19. Kelly, Allan, Project Myopia: Why projects damage software, Software Strategy, 2018, leanpub.com/noprojects.
20. Kelly, Allan, Continuous Digital: An agile alternative to projects for digital business, Software Strategy, 2018, leanpub.com/cdigital.
21. Kersten, Mik, Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework, IT Revolution, 2018, flowframework.org.
22. Hope, Jeremy; Fraser, Robin, Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap, Harvard Business School Press, 2003.
23. Bogsnes, Bjarte, Implementing Beyond Budgeting: Unlocking the Performance Potential, 2.ª ed., Wiley, 2016; Beyond Budgeting Round Table, bbrt.org.
24. Grove, Andrew S., High Output Management, Random House, 1983.
25. Doerr, John, Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs, Portfolio/Penguin, 2018.
26. Scaled Agile, Inc., “Lean Portfolio Management”, SAFe Framework, consultado el 02/10/2026, framework.scaledagile.com/lean-portfolio-management.
27. Skelton, Matthew; Pais, Manuel, Team Topologies: Organizing Business and Technology Teams for Fast Flow, IT Revolution, 2019; 2.ª ed., 2025, teamtopologies.com.
28. Conway, Melvin E., “How Do Committees Invent?”, Datamation, abril de 1968.
29. Gartner, “Gartner Says 80 Percent of Today’s Project Management Tasks Will Be Eliminated by 2030 as Artificial Intelligence Takes Over”, comunicado de prensa, 20/03/2019, gartner.com.
30. Project Management Institute, Pushing the Limits: Transforming Project Management with GenAI Innovation, 2024, pmi.org.
31. DORA (Google Cloud), Accelerate State of DevOps Report 2024, 2024, dora.dev.
32. DORA (Google Cloud), State of AI-assisted Software Development, 2025, dora.dev/research/ai.
33. Becker, Joel; Rush, Nate; Barnes, Elizabeth; Rein, David (METR), “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, julio de 2025, metr.org.
34. Flyvbjerg, Bent; Gardner, Dan, How Big Things Get Done, Currency, 2023.
35. Cagan, Marty, Transformed: Moving to the Product Operating Model, Wiley, 2024.
36. Project Management Institute, Talent Gap: Ten-Year Employment Trends, Costs, and Global Implications, 2021, pmi.org.
37. Agile Business Consortium, The DSDM Agile Project Framework, 2014, agilebusiness.org.