Management · Process
Project
Management
Fundamentos
As duas escolas de project management (PMI/PMBOK e Agile): como cada uma funciona, quando escolher uma em vez da outra, e como as abordagens híbridas unem os dois mundos.
PMI
PMBOK
Agile
Hybrid
A Divisão
Dois pressupostos fundamentalmente diferentes
O project management tem duas escolas de pensamento dominantes, e partem de pressupostos opostos sobre a natureza do trabalho. Perceber ambas não é apenas académico: a escolha errada para um dado projeto produz derrapagens de orçamento, prazos falhados, ou produtos que ninguém usa.
Abordagem PMI / preditiva
- Assume que os requisitos podem ser definidos à partida
- Planeia todo o âmbito antes de o trabalho começar
- A mudança é controlada e gerida através de processos formais
- Sucesso = entregue a tempo, dentro do orçamento, dentro do âmbito
- Funciona melhor quando o destino é conhecido
Construir uma ponte, migrar um data center, implementar um sistema ERP.
Abordagem Agile / adaptativa
- Assume que os requisitos vão evoluir através da discovery
- Planeia em ciclos curtos, adapta-se continuamente
- A mudança é bem-vinda como sinal de aprendizagem
- Sucesso = valor entregue aos utilizadores, não aderência ao plano
- Funciona melhor quando o destino é incerto
Construir um novo produto SaaS, redesenhar uma app de cliente, correr uma experiência de marketing.
PMI / PMBOK
A abordagem PMI: cinco process groups
O Project Management Institute (PMI) publica o PMBOK Guide, o standard global da prática de project management. Organiza o trabalho do projeto em cinco process groups sequenciais, cada um com inputs, ferramentas e outputs definidos.
01
Initiating: Definir o projeto
Autorizar formalmente o projeto, identificar stakeholders, e definir o seu âmbito e objetivos de alto nível. Outputs-chave: Project Charter (o documento que concede autoridade ao PM), Stakeholder Register. Nenhum projeto deve começar sem um charter assinado. Previne o scope creep antes de o trabalho começar.
02
Planning: Definir como lá chegar
A fase mais intensiva em documentação. Os outputs incluem: Work Breakdown Structure (WBS), cronograma em Gantt, plano de recursos, risk register, plano de comunicação, e baseline de orçamento. No PMBOK, o planeamento é levado a sério. Mudanças ao plano mais tarde são caras. A baseline do projeto (âmbito + cronograma + custo) é fixada aqui.
03
Executing: Fazer o trabalho
A equipa executa o plano. O PM coordena recursos, gere a comunicação com stakeholders, e resolve impedimentos. Os processos de quality assurance correm ao longo da execução. Os change requests, quando surgem, são formalmente documentados e avaliados face à baseline do projeto antes de serem aprovados ou rejeitados.
04
Monitoring & Controlling: Acompanhar o progresso
A correr em paralelo com a execução, o M&C acompanha o desempenho face à baseline usando Earned Value Management (EVM). Métricas-chave: Cost Performance Index (CPI), Schedule Performance Index (SPI). Se CPI < 1, o projeto está acima do orçamento. Se SPI < 1, está atrasado. A deteção precoce permite ação corretiva antes de os problemas se agravarem.
05
Closing: Conclusão formal
Obter a aceitação formal do cliente ou sponsor, arquivar os documentos do projeto, libertar recursos, e documentar as lessons learned. O registo de lessons learned é o passo mais consistentemente saltado, e a omissão mais consistentemente lamentada quando o próximo projeto começa.
Conceitos Centrais
As ferramentas que todos os PMs precisam de perceber
Triple Constraint
Âmbito · Tempo · Custo: muda um, afetas os outros. Todos os projetos são limitados por âmbito (o que se constrói), tempo (quando está pronto) e custo (quanto custa). Mudar um afeta pelo menos um dos outros. Acrescentar âmbito sem acrescentar tempo ou orçamento significa que a qualidade sofre. Cortar orçamento sem cortar âmbito significa que o prazo se estende. O trabalho do PM é tornar estes trade-offs explícitos.
Work Breakdown Structure
Decompõe o trabalho até ser estimável. A WBS decompõe os entregáveis do projeto em work packages mais pequenos, partidos hierarquicamente até cada elemento ser pequeno o suficiente para estimar, atribuir e acompanhar. Uma WBS bem construída é a fundação do cronograma e do orçamento. Uma WBS em falta é a razão por que as estimativas estão sempre erradas.
Risk Register
Identifica, avalia e responde antes de os riscos virarem problemas. Um risk register captura os riscos identificados, a sua probabilidade, o impacto potencial, o risk score (probabilidade × impacto), e a resposta planeada (evitar, mitigar, transferir, aceitar). O objetivo é passar do combate reativo a incêndios para a gestão proativa. A maioria das falhas de projeto eram riscos previsíveis sobre os quais ninguém agiu.
Gestão de Stakeholders
Grelha Poder/Interesse: envolve as pessoas certas, da forma certa. Coloca os stakeholders numa grelha 2×2: alto poder / alto interesse (gerir de perto), alto poder / baixo interesse (manter satisfeitos), baixo poder / alto interesse (manter informados), baixo poder / baixo interesse (monitorizar). O esforço de comunicação deve ser proporcional a esta grelha, não igual para toda a gente.
Agile PM
Project management dentro do Agile
Em ambientes Agile, o papel do PM não desaparece. Transforma-se. O planeamento, o tracking e a gestão de stakeholders continuam a acontecer, mas com ciclos mais curtos e mais flexibilidade.
Rolling-wave planning
Planeia em detalhe apenas o que consegues ver com clareza. Os sprints imediatos são totalmente planeados; os sprints futuros são estimados a um nível mais alto (epics, story points). À medida que o projeto evolui, o detalhe é acrescentado progressivamente, não carregado à frente num plano que vai inevitavelmente mudar.
Velocity & forecasting
As equipas Agile acompanham a velocity (story points concluídos por sprint) para prever quando o backlog estará completo. Após 3–4 sprints, a velocity estabiliza e fornece um forecast de release fiável, empiricamente ancorado, não wishful thinking.
Servant leadership
No Scrum, o Scrum Master atua como servant leader, removendo impedimentos, facilitando cerimónias, e protegendo a equipa de interrupções externas. O papel do PM desloca-se de command-and-control para enablement e coaching.
Certificações
As principais certificações de PM
As certificações sinalizam fluência numa metodologia. Não são prova de bom project management. São prova de que percebes o vocabulário e os frameworks bem o suficiente para os aplicar.
PMP
Project Management Professional: a referência do PMI. A credencial de PM mais reconhecida globalmente. Exige 36 meses de experiência de liderança de projetos, 35 horas de formação em PM, e um exame de 180 perguntas que cobre abordagens preditivas, ágeis e híbridas. Os detentores do PMP comandam salários premium em várias indústrias, sobretudo construção, IT, finanças e consultoria.
PRINCE2
Projects IN Controlled Environments: dominante na Europa e no Reino Unido. Uma metodologia baseada em processos com origem no governo do Reino Unido (hoje detida pela PeopleCert). Mais prescritiva do que o PMBOK. Define papéis específicos (Project Board, Project Manager, Team Manager) e documentos de gestão (PID, Business Case, Risk Register). Comum no setor público, em contratos do governo do Reino Unido, e em empresas europeias.
PSM / CSM
Professional Scrum Master / Certified Scrum Master: via Agile. O PSM I (Scrum.org) e o CSM (Scrum Alliance) certificam o conhecimento do framework Scrum. Nível de entrada para funções Agile. O PSM I é baseado em avaliação (nota de passagem de 85%); o CSM exige um curso de 2 dias. Para profissionais de PM a passar para funções de produto ou Agile, são a credencial mais rápida para sinalizar a transição.
Híbrido
A maioria dos projetos reais é híbrida
O debate preditivo vs. Agile é largamente teórico. Na prática, a maioria das organizações combina ambos, usando a governance estruturada e os orçamentos fixos do PMBOK com a entrega iterativa e as equipas cross-functional do Agile.
Atenção a estes
Âmbito fixo, entrega iterativa: O âmbito global e o orçamento do projeto são fixos (estilo PMI), mas a entrega acontece em sprints de duas semanas com demos e retrospetivas (estilo Agile). Comum em implementações de IT enterprise onde o procurement exige um contrato fixo mas a equipa de entrega quer feedback iterativo.
Entrega Agile, governance em waterfall: As equipas de produto trabalham em sprints com daily standups e sprint reviews, enquanto reportam para cima através de estruturas de PMO com relatórios de estado trimestrais, análise de desvio de orçamento, e apresentações ao steering committee. A equipa trabalha em Agile; a organização governa em waterfall.
Entrega faseada com execução Agile: Programas grandes são divididos em fases (Fase 1: MVP, Fase 2: Escalar, Fase 3: Otimizar). Cada fase tem um orçamento e prazo fixos acordados à partida. Dentro de cada fase, a equipa corre sprints. Isto dá aos sponsors a previsibilidade de que precisam, preservando a agilidade da equipa.
Conclusão
Escolhe a abordagem que se ajusta à incerteza
Certeza → PMI
Quando os requisitos são claros, a tecnologia é conhecida, e o estado final está bem definido, o planeamento preditivo compensa. O investimento inicial na definição do âmbito e no planeamento de riscos evita rework caro mais tarde.
Incerteza → Agile
Quando os requisitos vão emergir através do feedback dos utilizadores, quando a tecnologia é nova, ou quando o mercado está a mudar, os ciclos de feedback curtos do Agile reduzem o custo de estar errado. Aprendes barato em vez de construíres caro na direção errada.
Ambos → Híbrido
A maioria das grandes organizações não escolhe. Sobrepõe a entrega Agile dentro de estruturas de governance do PMI. A fluência em ambos os frameworks torna-te valioso em qualquer ambiente, e a capacidade de traduzir entre eles é uma skill genuinamente rara.
Mais sobre projeto & produto
Escrevo sobre project management, estratégia de produto e frameworks de negócio. Segue no LinkedIn para mais.