Ser ou não ser Ágil? Eis a questão! - Parte II

Posso usar os métodos de Gerenciamento Ágil de Projetos em qualquer projeto? Essa é uma pergunta que se respondida através do PMBOK, teríamos a seguinte linha de pensamento:

PMBOK fornece diretrizes e conceitos para o gerenciamento de projeto. Ele também descreve o ciclo de vida do projeto, seus processos relacionados, bem como o Ciclo de Vida do projeto.

O PMBOK mostra um conjunto de conhecimentos, ferramentas e técnicas reconhecidas pela comunidade de Gerentes de Projeto como Boas Práticas. Dessa forma, o conhecimento e as práticas descritas são aplicáveis ​​à maioria dos projetos na maior parte do tempo, e há um consenso sobre o seu valor e utilidade. A aplicação destas Boas Práticas podem aumentar as chances de sucesso dos projetos.

Porém existe um alerta: Uma “Boa Prática” não deve ser sempre aplicada de forma uniforme em todos os projetos.  As organizações bem como as equipes de gerenciamento do projeto são quem devem ser responsáveis por determinar o que é apropriado para um determinado projeto.

No PMBOK os métodos ágeis são chamados de Ciclo de Vida Adaptativo destinam-se a responder a alterações de alto nível e envolvimento contínuo partes interessadas. Métodos adaptativos são recomendados quando o projeto está sendo desenvolvido em um ambiente de rápida mudança, quando os requisitos e escopo são difíceis de definir com antecedência, e quando é possível definir pequenas melhorias incrementais que agregam valor às partes interessadas.

Assim, chegamos a nossa conclusão nº 1, baseado nas afirmações do PMBOK: É possível a aplicação de Métodos Ágeis em qualquer tipo de projeto.

Porém essa conclusão precisa fazer sentido de alguma forma.

Um projeto que tem por objetivo a entrega de um produto que só faz sentido quando este está 100% completo, só podemos considera-lo bem sucedido no final. Pode haver alterações de escopo? Sim poderão, mas estas devem estar documentadas, aprovadas.

Em métodos ágeis, parte-se do princípio que um conjunto mínimo das funcionalidades já irá atender algumas das expectativas do cliente, e, portanto, será de algum valor para ele. Caso o projeto seja descontinuado depois de um tempo, o cliente já recebeu um valor efetivo.  Veja que não se trata de planejamento por ondas sucessivas ou de entregas intermediárias, mas de repetições intencionais de planejamento, execução e controle possibilitando um sucesso progressivo do projeto.

Assim, chegamos a nossa conclusão nº 2: Existem situações que a aplicação de Métodos Ágeis não são convenientes. 

Assim, vou encerrar este post como comecei: Posso usar os métodos de Gerenciamento Ágil de Projetos em qualquer projeto? Acredito que estamos evoluindo para isso e será possível a aplicação de Métodos Ágeis em qualquer tipo de projeto. Porém, existem situações em que isso não será conveniente.

Ser ou não ser Ágil, eis a questão!

Vamos ao campo das discussões puramente filosóficas: O que é melhor, Gerenciamento de Projetos Tradicional ou Gerenciamento Ágil de Projetos (GAP)?

A verdade é que não existe fórmula mágica para o gerenciamento de projetos, e então, não existe resposta precisa sobre o assunto.  Cada empresa é única, cada cliente é único, cada necessidade é única e, cada projeto é único e, portanto, a resposta depende de cada situação. Assim, o que é ferramenta aplicável em um projeto, para outro projeto, já não terá o mesmo resultado.

Como foi publicado em um post anterior, os métodos ágeis estão contemplados no PMBOK 5ª edição através de projetos com ciclo de vida adaptativos. Conceitos como escopo evolutivo, ciclos iterativos incrementais, gerenciamento de mudanças e riscos, gestão de pessoas, comunicação, ética, entregar algo de valor, qualidade, que são basicamente pilares do Gerenciamento Ágil, não são novos no PMBOK. Porém o enfoque que vem sendo dado é de fato diferente.

Gerenciar um projeto “agilmente” não significa abolir os processos e os documentos de planejamento dos projetos. Gerenciar um projeto com métodos ágeis é entender estes processos e seus documentos são mutáveis, evolutivos e estes devem refletir a realidade.

Da mesma forma, controlar um projeto através de métodos ágeis não significa abolir os relatórios de acompanhamento e as métricas. Mas, considerando que as atualizações serão sempre constantes, devem ser utilizados dispositivos mais visuais e mais simples.

Um dos grandes desafios do GAP é justamente como realizar o planejamento e o controle do projeto sem restringir a sua adaptabilidade, sem que isso represente alterações de prazo e custo para o cliente do projeto.

Vários autores convergem para a opinião de que, a utilização de técnicas simplificadas  focando na exploração e adaptação do projeto não significa renunciar as atividades de controle do progresso do projeto, assim como custo, prazo e qualidade, mas repensar o que deve ser medido e controlado, e, principalmente como e quando deve ser exercido tal controle.

Por fim, as ferramentas e técnicas dos métodos ágeis devem trazer benefícios ao cliente evitando indicadores ou  métricas que não contribuem para avaliação do projeto.

Em outro post irei abordar a aplicação dos métodos ágeis em projetos que não são da área de TI.

Informações do Projeto / Dados do Projeto / Relatórios de Projeto

Imagine-se na cabine de comando de um avião 747 ou de um A380. Imagine-se cercado por um painel com várias luzes acesas, outras apagadas e algumas piscando de forma frenética. Em condições normais de temperatura e pressão, eu não faria a menor ideia do que isto significa, mas mãos de uma tripulação bem preparada, eu me sentiria bem confortável e aproveitaria a viagem, que acredito ocorreria sem grandes sustos. Porém toda essa calma e confiança têm apenas uma razão: A tripulação transforma os dados dos diversos instrumentos em informações úteis para subsidiar as suas ações e decisões que, em última análise, mantém o avião voando.

Essa história é apenas iniciar uma reflexão sobre estes 02 confusos conceitos do PMBOK 5 - Dados de Projeto e Informações de Projeto. Conforme o PMBOK 5,  uma quantidade significativa de dados e informações são gerados, coletados, processados, analisados e distribuídos para a equipe de projeto e outras partes interessadas.

Existe uma diferença geral entre DADOS E INFORMAÇÕES de um projeto. A regra geral, que não é muito clara, mas que funciona é: Os DADOS são coletados nos diversos processos de EXECUÇÃO e são compartilhados pelos diversos membros da equipe de projeto. Estes DADOS devem ser analisados dentro de um contexto e processados para transforma-los em INFORMAÇÕES nos vários processos de CONTROLE.

O PMBOK entende que esta diferença é tênue e que as expressões DADOS DE PROJETO e INFORMAÇÕES DE PROJETO podem causar certa confusão. Para minimizar esta confusão, o PMBOK propõe as seguintes 03 diretrizes para diferenciar estes conceitos:

Work Performance Data – Dados de Desempenho do Projeto – São as medidas primárias obtidas a partir dos processos de  Execução do trabalho do projeto. Exemplos destas medidas são o percentual de avanço físico completado, as datas de início e fim das atividades, custo atual, duração total, número de solicitações de mudança realizadas, etc...

Work Performance Information – Informações de Desempenho do Projeto – São as informações obtidas a partir dos processos de Monitoramento e Controle, analisadas no contexto geral e integradas, baseada nas relações entre as áreas. São exemplos dessas informações, o Status das entregas e as estimativas previstas para conclusão do trabalho do projeto, etc...

Work Performance Report – Relatórios de Desempenho do Projeto - A representação física ou eletrônica das Informações de Desempenho do Projeto, compilados em documentos do projeto, pretendendo-se gerar decisões ou levantar questões, ações ou sensibilização. São exemplos Relatórios de Status, Memorandos, Justificativas, Notas de Informações, Painéis de Controle do Projeto tipo “Dashboard”, recomendações, atualizações,etc...

Estes 03 conceitos, são melhor esclarecidos quando visualizamos o que o PMBOK chamou nesta 5ª edição de Fluxo de Dados, Informações e Relatórios do Projeto

Métodos Ágeis de Gerenciamento de Projetos no PMBOK 5ª edição.

Ciclo de vida de um projeto são as etapas que um projeto percorre desde sua concepção inicial até a sua conclusão. No novo PMBOK são descritos 03 tipos de ciclo de vida para o projeto:

Ciclo de Vida preditivo – Definido como aquele que pode ser totalmente planejado de antemão.

Ciclo de Vida Iterativo e Incremental (I & I)– cujas fases, chamadas iterações, repetem intencionalmente uma ou mais atividades do projeto a medida que o entendimento  da equipe de projeto em relação ao seu objetivo final aumenta.

Ciclo de Vida de adaptativo – Que pretende dar uma resposta a um número muito elevado de mudanças e um envolvimento continuo dos stakeholders. O Ciclo de vida adaptativo no PMBOK é também chamado de orientado a mudanças e Métodos Ágeis.

Segundo o PMBOK, o escopo de um projeto conduzido neste tipo de ciclo de vida é decomposto em um conjunto de requisitos e de trabalhos a serem executados, conhecido como “product backlog”. A equipe de projeto deverá identificar na lista de backlog, as prioridades que devem ser tratadas e apresentadas sucessivamente ao cliente.

Métodos adaptativos são preferidos quando se lida com necessidades por alterações rápidas, quando escopo e requisitos são difíceis de serem totalmente determinados e quando é possível que pequenos incrementos irão agregar valor para os stakeholders.

O Ciclo Iterativo e Incremental e Ciclo Adaptativo embora se igualem pela repetição de atividades, diferem-se pelo número dessas iterações, sendo o segundo de rotatividade mais alta, de previsibilidade mais baixa e de maior velocidade de execução.

Cabe dizer aqui o PMBOK ainda menciona como o método ágil pode ser aplicado em suas outras seções e que cabe um estudo mais detalhado, que não seria o objetivo principal deste post.

Os Quatro novos processos de Planejamento do PMBOK 5ª edição.

O novo PMBOK adiciona quatro novos processos de planejamento: Plano de Gerenciamento de Escopo, Plano de Gerenciamento de Cronograma, Plano de Gerenciamento de Custos e Plano de Gerenciamento das Partes Interessadas. Estas mudanças trazem de volta o processo de Planejamento do Escopo da terceira edição e adiciona três novos processos de planejamento.

Além de garantir harmonização com outros padrões do PMI, o objetivo maior destes processos é orientar de forma clara, o planejamento e o gerenciamento dos processos relacionados de cada uma dessas áreas de conhecimento.

Estes 04 novos processos reforçam o conceito de que cada um dos planos auxiliares deverá estar integrado através do Plano de Gerenciamento de Projetos, que é o documento de planejamento mais importante para orientar a execução do trabalho do projeto.

Três dos quatro novos processos são muito semelhantes, com objetivos semelhantes, entradas iguais e saídas muito parecidas. Apenas o Plano de Gerenciamento de Partes Interessadas difere-se um pouco do contexto geral dos demais planos

Abaixo temos a definição dos 04 novos processos, suas entradas e saídas.

Plano de Gerenciamento de Escopo

O Plano de Gerenciamento do Escopo é o processo de criação do Plano de Gerenciamento do Escopo, que documenta como o escopo do projeto será definido, validado e controlado. Este processo fornece um direcionamento de como o escopo será gerenciado durante a execução do trabalho do projeto. As entradas e saídas desse processo são:

Entradas

• Plano de Gerenciamento do Projeto
• Termo de Abertura do Projeto
• Fatores Ambientais da Empresa
• Ativos de Processos Organizacionais

Saídas

• Plano de Gerenciamento do Escopo
• Plano de Gerenciamento dos Requisitos

Plano de Gerenciamento do Cronograma

Este é o processo que estabelece as políticas, procedimentos e documentação para planejar, desenvolver, gerenciar, executar, e controlar o cronograma do projeto. Este processo fornece o direcionamento de como o Cronograma do Projeto será gerenciado durante a execução do trabalho do projeto.

Entradas

• Plano de Gerenciamento do Projeto
• Termo de Abertura do Projeto
• Fatores Ambientais da Empresa
• Ativos de Processos Organizacionais

Saídas

• Plano de Gerenciamento do Cronograma

Plano de Gerenciamento dos Custos

Plano de Gerenciamento dos Custos é o processo que define as políticas, procedimentos, e documentação para planejar, gerenciar, empregar os recursos financeiros, e controlar os custos do projeto. Este é o processo que define o direcionamento de como os custos e recursos financeiros serão empregados ao longo da execução do trabalho do projeto.

Entradas

• Plano de Gerenciamento do Projeto
• Termo de Abertura do Projeto
• Fatores Ambientais da Empresa
• Ativos de Processos Organizacionais

Saídas

• Plano de Gerenciamento dos Custos

Plano do Gerenciamento das Partes Interessadas

O Plano de Gerenciamento das Partes Interessadas é o processo de desenvolver as estratégias apropriadas para efetivamente obter o compromisso das partes interessadas durante o ciclo de vida do projeto, baseando-se na análise de suas necessidades, interesses, e impacto potencial no sucesso do projeto. Este processo provê um plano para interação com as partes interessadas do projeto para sustentar os interesses do projeto

Entradas

• Plano de Gerenciamento do Projeto
• Registro de Partes Interessadas
• Fatores Ambientais da Empresa
• Ativos de Processos Organizacionais

Saídas

• Plano de Gerenciamento das Partes Interessadas
• Atualização dos Documentos do Projeto

A inevitável comparação entre os processos da Norma 21500:2012 e o PMBOK 5ª edição.

Com a recente publicação da Norma ISO 21500:2012 e do Guia PMBOK 5ª edição é inevitável que sejam feitas comparações entre estes dois documentos. De fato ambos são muito parecidos, apresentando um conjunto de processos que, organizados por Grupos de Processos e Áreas de Conhecimento, visam fornecer diretrizes para o gerenciamento de projetos.

Cabe ressaltar, no entanto, que a norma ISO é um documento relativamente pequeno (apenas 47 páginas) e por isso limita-se à introdução dos processos, as suas entradas e suas saídas. Já o Guia PMBOK 5ª edição é um documento muito mais extenso, detalhando, os processos de gerenciamento de projetos baseados em melhores práticas, seus insumos, suas saídas e também as principais ferramentas e técnicas associadas a cada um dos processos.

A norma ISO contempla 39 processos divididos em 10 áreas de conhecimento e 05 grupos de processos. Já o PMBOK 5ª edição descreve 47 processos igualmente divididos nas 10 áreas de conhecimento e nos 05 grupos de processo.

O quadro abaixo mostra os processos equivalentes em cada um dos documentos:

ISO 21.500:2012	PMBOK 5ª Edição
4.3.2 Desenvolver o Termo de Abertura do Projeto	4.1 Desenvolver o Termo de Abertura do Projeto
4.3.3 Desenvolver Planos de Projeto	4.2 Desenvolver Planos de Gerenciamento de Projetos
4.3.4 Dirigir o trabalho do projeto	4.3 Orientar e Gerenciar o trabalho do projeto
4.3.5 Controlar o trabalho do projeto	4.4 Monitorar e controlar o trabalho do projeto
4.3.6 Controlar mudanças	4.5 Realizar o controle integrado de mudanças
4.3.7 Fechar fase do projeto ou o projeto	4.6 Encerrar projeto ou fase
4.3.11 Definir o escopo	5.3 Definir o escopo
4.3.12 Criar Estrutura Analítica do Projeto (EAP)	5.4 Criar WBS
4.3.14 Controlar o escopo	5.6 Controlar escopo
4.3.13 Definir as atividades	6.2 Definir as atividades
4.3.21 Sequenciar as atividades	6.3 Sequenciar as atividades
4.3.16 Estimar os recursos	6.4 Estimar os recursos das atividades
4.3.22 Estimar a duração das atividades	6.5 Estimar a duração das atividades
4.3.23 Desenvolver o cronograma	6.6 Desenvolver o cronograma
4.3.24 Controlar o cronograma	6.7 Controlar o cronograma
4.3.25 Estimar custos	7.2 Estimar custos
4.3.26 Desenvolver o orçamento	7.3 Determinar o orçamento
4.3.27 Controlar custos	7.4 Controlar custos
4.3.32 Planejar a qualidade	8.1 Planejar o Gerenciamento da Qualidade
4.3.33 Executar a garantia da qualidade	8.2 Realizar a garantia da qualidade
4.3.34 Executar o controle da qualidade	8.3 Controlar a qualidade
4.3.17 Definir a organização do projeto	9.1 Planejar o Gerenciamento de Recursos Humanos
4.3.15 Estabelecer a equipe do projeto	9.2 Mobilizar a equipe do projeto
4.3.18 Desenvolver a equipe do projeto	9.3 Desenvolver a equipe do projeto
4.3.20 Gerenciar a equipe do projeto	9.4 Gerenciar a equipe do projeto
4.3.38 Planejar as Comunicações	10.1 Planejar o gerenciamento das comunicações
4.3.39 Distribuir as informações	10.2 Gerenciar as comunicações
4.3.40 Gerenciar a comunicação	10.3 Controlar as comunicações
4.3.28 Identificar os riscos	11.2 Identificar os riscos
4.3.29 Avaliar os riscos	11.3 Realizar a análise qualitativa dos riscos
4.3.30 Tratar os riscos	11.5 Planejar as respostas aos riscos
4.3.27 Controlar os riscos	11.6 Controlar os riscos
4.3.35 Planejar as aquisições	12.1 Planejar o gerenciamento de aquisições
4.3.36 Selecionar fornecedores	12.2 Conduzir as aquisições
4.3.37 Administrar as aquisições	12.3 Controlar as requisições
4.3.9 Identificar as partes interessadas	13.1 Identificar as partes interessadas
4.3.10 Gerenciar as partes interessadas	13.3 Gerenciar o comprometimento das partes interessadas

A tabela abaixo relaciona os processos da norma ISO 22.500:2012 que não possuem equivalência no PMBOK 5ª ed.

ISO 21.500:2012

4.3.8 Coletar lições aprendidas

4.3.19 Controlar os recursos

Já a tabela abaixo tabela abaixo relaciona os processos do PMBOK 5ª ed. que não possuem equivalência na norma ISO 22.500:2012.

PMBOK 5ª EDIÇÃO

5.1 Planejar o gerenciamento do escopo

5.2 Coletar os requisitos

5.5 Validar escopo

6.1 Planejar gerenciamento de cronograma

7.1 Planejar gerenciamento de custos

11.1 Planejar gerenciamento de riscos

11.4 Realizar a análise qualitativa de riscos

12.4 Controlar aquisições

13.2 Planejar o gerenciamento das partes interessadas

13.4 Controlar o gerenciamento de stakeholder

Em outros posts, irei detalhar as diferenças e as semelhanças de cada um dos processos do PMBOK e da ISO 21.500:2012.