Projetos como agentes de mudanças

Projetos são empreendimentos temporários que criam resultados únicos, que podem ser iniciados por diversas razões, tais como uma demanda de mercado, uma oportunidade estratégica, um inovação tecnológica, um requisito legal, etc... Em resumo, um projeto é iniciado por necessidade de uma mudança.

Não existe organização que não esteja sujeita a mudança, pelo contrário, toda organização navega um ambiente dinâmico, fluido e em constante mudança, e o seu sucesso depende da capacidade para usar seus projetos para aproveitar e gerir as necessidades de mudança.

Embora o PMBOK não considere a Gestão da Mudança como uma área de conhecimento, ela deve ser um componente essencial na implementação do projeto. Para as organizações, a Gestão da Mudança servirá como suporte para adaptação à incerteza e complexidade, bem como melhor alinhamento estratégico e sucesso do negócio, enquanto que para os Gerentes de Projetos será uma competência fundamental da liderança, que complementa suas habilidades técnicas.

Por isso é preciso entender como os projetos irão afetar as pessoas e as organizações. Os Gerentes de Projeto devem liderar e gerir pessoas, equipes e organizações através da transição entre o velho e o novo. Em última análise, os Gerentes de Projeto devem ser gestores e facilitadores de mudanças, uma vez que a mudança é, como dizem, a única coisa certeza.







O Gerente de Projetos precisa olhar para as mudanças provocadas pela implementação do projeto com os olhos daqueles que são impactados e entender que as pessoas resistem à forma como as mudanças mexem na sua zona de conforto e perturbam suas vidas.

Escopo e a síndrome do francês

Basicamente escopo define os grandes objetivos de um projeto. É de fato o conjunto de todos os produtos, serviços e resultados que devem ser fornecidos para que um projeto seja considerado bem sucedido. Não por acaso o gerenciamento de escopo concentra-se em definir o que está e o que não está incluído em um projeto.

Na prática, o escopo é a primeira atividade do planejamento realizado para um projeto. Essa definição servirá como espinha dorsal do projeto. Sem conhecer claramente quais são os objetivos a serem alcançados no projeto, não se pode estimar em quanto tempo o trabalho será executado e nem quanto esse trabalho irá custar.

Uma das grandes habilidades que um gerente de projetos precisa desenvolver é a capacidade de proteger o escopo. Projetos que freqüentemente mudam o escopo durante a sua execução têm serias dificuldades em cumprir o cronograma e os custos estabelecidos inicialmente. Esta ocorrência é chamada de “scope creep”, termo em inglês para o efeito de mudança lenta,  gradual e desordenada do escopo de um projeto, além dos objetivos planejados inicialmente.

Scope Creep é a síndrome do francês Jaque (e não é o professor Jacques Cousteau). É o Já que você está fazendo isso e já que você está fazendo aquilo e já que faremos isto.. e quando vemos a infinidade de Já Ques que aparecem o projeto já não tem mais salvação.

Toda vez que aceitamos essas pequenas melhorias não previstas, aceitamos passivamente a Lei de Porter: "O Gerente de Projetos sempre será solicitado a fazer cada vez mais, com cada vez menos , até que um dia seja necessário fazer tudo sem consumir nada".

Felizmente com um pouco de esforço e sete dicas é possível prevenir que o "mal do já que" mantenha-se longe dos projetos.
1) Defina o Escopo - É importante definir o que será entregue e o que não será entregue antes de iniciar qualquer trabalho em um projeto, bem como é necessário manter tais entregas intocáveis. É importante definir e defender a linha de base do escopo do projeto. A linha de base do escopo é o "slack line" do Gerente de Projeto. Escopo bem definido é a fortaleza do Gerente de Projeto.

2) Registre as mudanças e os seus impactos  - Embora o escopo bem definido seja nossa fortaleza, a única certeza da vida é que haverão mudanças. Pois bem faz-se necessário registrar tais mudanças e os impactos que tais mudanças irão acarretar no andamento do projeto. Essas mudanças devem ser validadas e aprovadas por um processo sistemático do Comitê de Controle de Mudanças.

3) Redefinir a Linha de Base - Uma vez que as alterações de escopo foram aprovadas, a condição de equilíbrio do projeto foi alterada. Portanto é hora de redefinir a linha de base do escopo.

4) Solicite Recursos Adicionais - Alterações de escopo sempre irão alterar a necessidade de algum tipo de recurso, sejam mais horas de implementação, sejam mais recursos humanos, sejam mais equipamentos ou sejam mais fundos. Escopo alterado requer alteração de recursos. Você não é mágico e nem santo para operar o milagre da multiplicação dos recursos.

5) Observe os sinais de que as coisas não estão nos trilhos - As más notícias sempre são dadas no último instante. O GP deve observar os sinais dados por sua equipe de projetos. Não se deixe enganar por reportes de que tudo está sempre indo muito bem.

6) Determine as Prioridades das mudanças solicitadas - Isto acontece quando várias partes interessadas solicitam diversas mudanças. O Comitê de Controle de Mudanças avaliar e priorizar quais as mudanças devem ou não ser implementadas.

7) Fuja das armadilhas "francesas" - Essas armadilhas se escondem em frases que se iniciam com nomes franceses. Já que, Enquanto, Assim que. Geralmente os franceses com esses nomes são lobos em pele de cordeiro. Apresentam uma solução simples para um problema, mas os estragos que são feitos no projeto são imensos.

A evolução do conceito de sucesso de um projeto.

Sucesso de um projeto é um dos conceitos que tem sofrido maior número de alterações ao longo dos anos. Inicialmente, o sucesso era medido em termos técnicos. Não havia a preocupação das organizações em definir o sucesso de um projeto em termos empresariais. O sucesso de um projeto baseava-se em  produtos adequados ou inadequados. Projeto de sucesso era aquele que o escopo era entregue não importando os prazos e os recursos empregados durante a sua execução.

A medida que a cultura de gerenciamento de projetos passou a ser disseminada nas organizações, a definição de sucesso passou a ser entendida como a conclusão de um objetivo no prazo, no custo e com a qualidade previamente acordados.

Essa definição, já mostra uma preocupação em atender alguns indicadores empresariais, porém é uma definição ainda incompleta. Projetos que são um sucesso em seu gerenciamento, com o seu escopo entregue no prazo, no custo e com a qualidade desejada podem tornar-se um grande fracasso de negócios, enquanto outros, com problemas de prazo, custo ou outros que tornam-se um sucesso para os negócios das empresas.

Um outro ponto de vista é definir o sucesso de um projeto a questões intangíveis, como por exemplo a aceitação do produto pelos stakeholders. Quem definirá se o projeto é um sucesso ou um fracasso são os stakeholders. A definição absoluta de sucesso de um projeto será visualizada quando um cliente estiver tão satisfeito com os resultados alcançados que permitirá a utilização de seu nome como referência.

Ambos pontos de vista estão corretos e ambos têm sua deficiência. O sucesso de um projeto deve balancear questões técnicas do gerenciamento do projeto e a percepção dos stakeholders.

Do ponto de vista dos stakeholders, o sucesso de um projeto deverá ser medido, dentre outros fatores, observando:

• Cumprir os objetivos
• Atender ao orçamento
• Concretização da qualidade
• Atender a conveniência e oportunidade da assinatura do contrato

Do ponto de vista do gerenciamento do projeto, o seu sucesso deverá ser medido, dentre outros fatores, observando:

• Utilização da metodologia de gestão de projetos;
• Estabelecimento de Processos de Controle
• Uso adequado de indicadores;
• Envolvimento do cliente;

Justificando um projeto através do Business Case

O Business Case é o documento que deve justificar o investimento no projeto com base nas estimativas de custo, prazo, e esforço contra riscos associados e benefícios que podem ser alcançados com o projeto. Este documento normalmente contém uma descrição das necessidades do negócio, bem como contém uma análise de custo-benefício  para justificar e estabelecer limites para o projeto.

O Business Case precisa suportar o projeto durante todo o seu ciclo de vida. Possibilitando em diferentes momentos avaliar sobre continuidade ou não do projeto. O Business case precisa apoiar a organização, validando se os objetivos e valor propostos pelo projeto continuam sendo válidos. Se a justificativa de negócio for válida no início do projeto, mas deixar de ser durante a execução, o projeto deve ser interrompido ou modificado.

Um Business Case de qualidade deve possuir uma justificativa consistente para o investimento, estar alinhado com os planos estratégicos da organização, identificar os benefícios, bem como identificar métodos para mensuração para os benefícios identificados. Além disso ele deverá responder alguns questionamentos, antes e durante o ciclo de vida do projeto, tais como:

• Vale a pena iniciar esse projeto?
• Por que estamos fazendo esse projeto?
• Vale a pena continuarmos com o projeto?
• Quais os efeitos colaterais com esse projeto?

Não existe uma estrutura fixa para um Business Case, porém ele deve contemplar pelo menos os  seguintes aspectos:

• Resumo Executivo;
• Descrição da Oportunidade;
• Recomendações;
• Análise de Risco;
• Avaliação Econômica-Financeira;
• Avaliação Técnica e Operacional;
• Avaliação Estratégica

Isto posto, conclui-se que o objetivo primário do Business Case é garantir que não se desperdice dinheiro implementando soluções sem um foco definido. É necessário descartar soluções que não agregam valor ao negócio das organizações.

Apesar da sua reconhecida importância para o negócio, muitas organizações não o fazem. Quais seriam os motivos? Pergunta complexa de difícil resposta. Não me arrisco a respondê-la para evitar qualquer juízo de valor, mas deixo esta reflexão como ponto de atenção para o sucesso de nossos projetos.

Introdução a metodologia PRINCE2 - Final - Jornada e Processos do PRINCE2

A Jornada PRINCE2, é algo que pode ser comparado ao ciclo de vida do projeto. Corresponde aos estágios que antecedem, iniciam, desenvolvem e entregam o projeto. A Jornada PRINCE2 está dividida nos seguintes estágios:

• Pre-project - É uma etapa anterior a existência do projeto. Nessa etapa, verifica-se se o projeto é ou não viável.
• Initiation Stage - Uma vez que o projeto é viável, ele precisará ser detalhadamente planejado. Neste estágio as estratégias são definidas, o Business Case é desenvolvido, bem como são elaborados os documentos de iniciação do projeto.
• Subsequent Delivery Stages - Consiste nos estágios de entregas dos produtos do projeto. Os produtos devem ser entregues conforme as especificações e o progresso do projeto deve estar alinhado com os planos aprovados e as metas definidas.
• Final Delivery Stage - Consiste no encerramento das atividades do projeto. Neste estágio, os produtos do projeto são aceitos e transferidos para operação.

A metodologia PRINCE2 é composta por 07 processos que são aplicados ao longo de um projeto e que fornecem o conjunto de atividades necessárias para direcionar, gerenciar e entregar um projeto com êxito.

Os processos do PRINCE2 abrangem um conjunto de atividades, que podem ser executadas em série ou em paralelo. Estas atividades abrangem um conjunto de ações recomendadas, elaboradas para alcançar um fim específico.

Os 07 processos PRINCE2:

• Starting up a Project - Este processo visa assegurar se o projeto é viável para ser iniciado. basicamente esse processo acontece apenas na etapa de Pre-project.
• Initiating a Project  - Visa assegurar o entendimento dos objetivos, escopo, qualidade e quaisquer outras informações que consolidem uma base para iniciar o projeto.
• Manage a Stage Boundary - Processo que visa assegurar ao Project Board informações suficientes sobre o desempenho do projeto e, com isto, decisões sobre a continuidade, interrupção, cancelamento e/ou encerramento do projeto podem ser tomadas.
• Directing a Project - Este processo visa assegurar condições propícias para um bom direcionamento do projeto.
• Controlling a Stage - Este processo contempla as atividades de controle e monitoramento dos estágios do projeto.
• Managing a Product Delivery -  Este processo visa garantir que os produtos do projeto sejam desenvolvidos e entregues conforme planejamento dentro dos padrões de qualidade acordados.
• Closing a Project - Este processo visa garantir o encerramento controlado do projeto.

A figura abaixo mostra o relacionamento entre os Processos e a Jornada Prince2.

Espero que a série de post sobre a metodologia PRINCE2 seja útil para esclarecer alguns de seus conceitos.

Para aqueles que querem se aprofundar no assunto, indico a seguinte bibliografia:

Gerenciando Projetos de Sucesso com PRINCE2 - OGC
Gerenciando Projetos com PRINCE2 - Robériton Luis Oliveira Ribeiro

Introdução a metodologia PRINCE2 - parte 3 - Temas PRINCE2

Os temas PRINCE2 descrevem 07 aspectos do Gerenciamento de Projetos que devem ser tratados de forma contínua pelo gerente de projetos. O ponto forte da metodologia PRINCE2 é a maneira como estes aspectos se integram. Os temas PRINCE2 devem ser aplicados de forma adequada às características do projeto e.

Os Temas PRINCE2 são:
Business Case - Refere-se ao porquê do projeto. O projeto se inicia com uma idéia com potencial de valor para a organização em questão. Este tema trata como a idéia se desenvolve em uma proposta de investimento viável para a organização e como o gerenciamento do projeto mantém o foco nos objetivos da organização ao longo de todo o projeto. Por que iniciar o projeto? Quais benefícios serão realizados?

Organização - Quem faz parte do time? Quais são os seus papéis e responsabilidades? Este tema descreve os papéis e responsabilidades na equipe de gerenciamento de projetos, considerando que trata-se de uma organização temporária necessária para o gerenciamento eficaz do esforço.

Qualidade -  O que o projeto entregará? A idéia inicial contida no Business Case é entendida como um esboço amplo. Este tema explica como esse esboço é desenvolvido de modo que todos os participantes entendam os atributos de qualidade dos produtos que serão entregues ao longo do projeto.

Planos - Este tema complementa o tema Qualidade. Como o produto será desenvolvido e entregue? Quanto Custará? Quem fará? O principal objetivo é descrever as etapas necessárias para desenvolvimento de planos e as técnicas que devem ser aplicadas, focando no planejamento, na comunicação e nos controle que serão aplicados ao longo de todo projeto.

Risco - Este tema trata como os Gerentes e as Equipes de Projetos gerenciam as incertezas do projeto. Quais serão as respostas se determinadas questões acontecerem?

Mudança - Este tema descreve como o Gerenciamento de Projetos avalia e age em resposta a questões com possível impacto sobre qualquer aspecto da linha de base do projeto. Tais questões podem ser problemas imprevistos de caráter geral, requisições de mudança ou casos de falhas de qualidade. Qual o impacto (prazo, custo, qualidade, risco, etc...) de implementar esta mudança no projeto?

Progresso - Este tema explica o processo de tomada de decisão na aprovação dos planos, no monitoramento do desempenho efetivo e escalonamento de questões. O tema Progresso determina como o projeto deve prosseguir. Onde o projeto está agora? O projeto chegou aonde queria? Aonde o projeto quer e de chegar?

Introdução a metodologia PRINCE2 - parte 2 - Os Princípios PRINCE2

O propósito do PRINCE2 é proporcionar um método de gerenciamento de projetos que pode ser aplicado independentemente do porte, tipo, organização, região geográfica ou cultura de sua implementação. Isso é possível porque o PRINCE2 é baseado em 07 princípios, universais, autovalidáveis e capazes de dar autonomia aos praticantes do método.

Justificação de negócio contínua
Um requisito de qualquer projeto PRINCE2 é que:

• Haja uma razão justificável para iniciá-lo;
• A justificativa se mantenha válida durante toda a vida do projeto;
• A justificativa esteja documentada e aprovada;

No PRINCE2 a justificação é documentada e aprovada na forma do Business Case. A justificação orienta os processos de tomada de decisão, para garantir que o projeto se mantenha alinhado com os objetivos da organização. A justificação pode mudar com a evolução do projeto, porém ela deve manter-se válida.

Por outro lado, o projeto já não puder ser justificado, este deverá ser interrompido. O PRINCE2 considera que a interrupção de um projeto nessas circunstâncias é ma contribuição positiva para a organização, pois os recursos financeiros e humanos podem ser reinvestidos em outros projetos que valham mais a pena.

Aprender com a experiência
No PRINCE2, o aprendizado com experiências anteriores permeia o método desde seu início até o encerramento do projeto.

No início do projeto, as lições aprendidas de projetos anteriores devem ser revisadas para verificar a sua aplicabilidade no novo projeto. Durante o andamento do projeto, novas lições devem ser aprendidas, buscando oportunidades de implementar melhorias. No encerramento, o projeto deve passar suas lições buscando provocar mudanças. Caso essas mudanças não sejam provocadas, as lições serão consideradas, apenas, como lições identificadas e aprendidas.

Papéis e responsabilidades definidos
Um projeto PRINCE2 tem papéis e responsabilidades definidos na estrutura organizacional do projeto, envolvendo as partes interessadas divididas basicamente em 03 grupos: Os patrocinadores do negócio, os usuários e os fornecedores.

Os interesses dessas três partes interessadas precisam estar efetivamente representados e equilibrados na equipe de gerenciamento do projeto. A estrutura da equipe de gerenciamento do projeto une as várias partes interessadas, nas metas comuns do projeto.

Gerenciar por estágios
Um projeto PRINCE2 é  planejado, monitorado e controlado por estágios. Estes estágios proporcionam pontos de controle ao longo do projeto. Ao final de cada estágio o status do projeto deve ser avaliado e o Business Case e os planos devem ser revisados para assegurar que o projeto continua viável.

Gerenciar por exceção
Um projeto PRINCE2 tem tolerâncias definidas para cada objetivo do projeto, para estabelecer os limites da autoridade delegada.

Foco em produtos
Um projeto PRINCE2 concentra o foco na definição e entrega de produtos, particularmente no que diz respeito a requisitos de qualidade. Um projeto bem-sucedido é orientado por resultados, não por atividades. Sem foco no produto, os projetos ficam expostos a disputas em torno da aceitação do projeto, o que poderá causar retrabalho, mudanças sem controle, insatisfação do usuário entre outros riscos.

Adequar ao ambiente do projeto
O PRINCE2 é adaptado para se adequar ao ambiente do projeto, seu porte, complexidade, importância, capacidade e risco. O PRINCE2 é um método de gerenciamento de projetos universal, porém sem adequação os objetivos do projeto podem não ser atendidos.
Os propósitos da adequação são assegurar que o método de gerenciamento de projeto esteja relacionado com o ambiente do projeto, bem como garantir que os controles do projetos estejam adequados ao seu porte, complexidade, importância, etc...

A ausência de qualquer um destes princípios, o método PRINCE2 não estará sendo aplicado ao projeto.

Introdução a metodologia PRINCE2 - parte 1

O PRINCE2 (PRojects IN Controlled Environments - Projetos em Ambientes Controlados) é um método não-proprietário genérico, a ponto de poder ser aplicado a qualquer projeto, independentemente de seu porte, tipo, organização, região geográfica ou cultura.

O método PRINCE2 aborda o gerenciamento de projeto com 04 elementos integrados de princípios, temas, processos e ambiente de projeto, focando no controle de seis objetivos principais do projeto: escopo, tempo, custo, qualidade, riscos e benefícios.

Os princípios são orientações obrigatórias e boas práticas que determinam se o projeto está sendo genuinamente gerenciado de acordo com o método PRINCE2. São sete princípios:

• Justificação contínua do Business Case.
• Aprender com a experiência.
• Papéis e responsabilidades definidos.
• Gerenciamento por estágios.
• Gerenciamento por exceção.
• Foco no produto.
• Adequação ao ambiente do projeto.

Sem a aplicação de qualquer dos princípios, o projeto não estará utilizando o PRINCE2.

Os temas descrevem aspectos do gerenciamento de projeto que devem ser tratados continuamente e em paralelo ao longo de toda a duração do projeto. Também são sete temas:

• Business Case.
• Organização.
• Qualidade.
• Planos.
• Risco.
• Mudança.
• Progresso.

Estes temas explicam o tratamento do PRINCE2 para as várias áreas de gerenciamento de projetos.

Os processos são percorridos de acordo com as etapas ao longo do ciclo de vida do projeto. São sete processos:

• Starting Up a Project (SU).
• Directing a Project (DP).
• Initiating a Project (IP).
• Managing a Stage Boundary (SB).
• Controlling a Stage (CS).
• Managing Product Delivery (MP).
• Closing a Project (CP).

Cada processo fornece listas de verificação de atividades, com recomendações de produtos (de gerenciamento de projetos, ex.: business case, descrição de produtos, relatórios, registros, notas de lição, etc.) e responsabilidades relacionadas.

Planejar não é preciso!

Antes que me condenem pelo título deste post, informo que o adjetivo preciso, neste caso, refere-se a exatidão, certeza, definição. Na verdade, planejar um projeto é muito semelhante a preparar um plano de navegação para uma velejada. Conhecemos a marcação da raia, sabemos as posições das boias, sabemos quantas "pernas" haverão da regata, e conhecemos as condições iniciais do vento que permitem o melhor ajuste das velas. Mas e se o vento mudar de intensidade ou direção ao longo da regata? Nossos planos iniciais não servem mais para muita coisa e somos obrigados a adaptar.

Os processos de planejamento de um projeto levam ao estabelecimento de um conjunto coordenado de ações visando à consecução de seus objetivos. Nestes processos o escopo, os critérios de sucesso, e o trabalho a ser executado para o alcance dos objetivos são definidos e refinados, e são elaborados os planos de gerenciamento e os documentos que irão conduzir a execução desse trabalho, considerando que nossas premissas, variáveis multidimensionais minimamente conhecidas, irão ocorrer.

Em condições normais de temperatura e pressão nossos planejamentos seriam perfeitos. Porém nossas premissas não ocorrem exatamente da maneira que queremos? Estamos cercados por "e se"... Essa característica de incerteza de nossas premissas, torna o gerenciamento de projetos uma atividade igualmente incerta. À medida que as características e variáveis do projeto são entendidas é necessário revisitar os processos de planejamento e elaborar novos planos. É necessário realizar ajustes nos planejamento ao longo do projeto.

Planejar não é preciso. Não existem mágicas ou fórmulas matemáticas que transformem o planejamento em uma verdade absoluta. Nossa "velejada" está sujeita a mudanças repentinas nas condições do vento. Estamos falando de algo iterativo que deve ser progressivamente elaborado ao longo de todo ciclo de vida do projeto. A elaboração progressiva permite que a equipe de gerenciamento de projetos defina o trabalho e o gerencie com um maior nível de detalhes envolvidos no projeto.

Líder de Projeto x Gerente de Projeto

Existe diferença entre ser Líder de Projeto e Gerente de Projeto.  O Gerente de Projetos lida com a complexidade enquanto o Líder de Projeto deve lidar com a capacidade de adaptação e com as mudanças.

Normalmente, a função do Gerente de Projetos é organizar a complexidade do projeto através das diversas ferramentas e técnicas gerando os planos necessários ao controle do projeto, tentando minimizar ao máximo as incertezas e os riscos que podem afetar negativamente o seu sucesso. Sem um gerenciamento adequado qualquer projeto tende a se tornar caótico.

Quando, no entanto, as incertezas e os riscos tendem a se tornar fatos, planos, controles, orçamentos e processos são insuficientes para lidar com o novo cenário, sendo exigida uma capacidade de adaptação e habilidades não tangíveis. Entra em ação o Líder de Projeto.

Equipes sem Líder são barcos sem leme. Líderes influenciam, direcionam, facilitam, ensinam, constroem, motivam, e alguns casos, até tomam decisões também. Uma liderança forte contribui significativamente para o sucesso dos projetos. Conduzir, para um líder, significa que como gerente, às vezes, ele tomará decisões unilaterais, outras vezes, decidirá com a equipe, mas principalmente, delegará decisões à equipe.

Gerentes dependem do poder formal, e em alguns casos usam a força na forma do medo e do terrorismo, para que as pessoas façam algo do modo deles. Líderes dependem da sua capacidade de influenciar, que vem do respeito e não do medo. Por sua vez, o respeito é proveniente de outras qualidades, como integridade, habilidade, justiça, veracidade.

Líderes fazem parte da equipe, e mesmo que lhes seja delegada  autoridade organizacional, sua real autoridade é conquistada de baixo para cima.

Gerentes, eficazes ou não, odeiam mudanças. Mudanças para eles significa falta de planejamento. Para os Líderes de Projeto, a mudança é algo bom e encorajador que cria novas possibilidades de melhorar.

Assim como as organizações, projetos precisam tanto de pessoas com habilidades de gerentes (tangíveis) quanto com as habilidades de líderes (intangíveis). Entretanto, muitas vezes, diria até que na maior parte das vezes, tais habilidades não são encontradas na mesma pessoa.  

Normalmente, focamos nossa preparação nas habilidades tangíveis, pois é muito mais simples aprender os conceitos para montar planos, cronogramas, orçamentos, relatórios, etc... . Faltam Líderes de Projeto que tem a capacidade de adaptação para atender e entender as necessidades conflitantes dos clientes.

Em mundo cujas mudanças são constantes e cada vez mais rápidas, seremos cada vez mais exigidos na capacidade de Liderar Projetos, sem que os aspectos técnicos e ferramentais sejam esquecidos.

Agilidade Organizacional, como melhorar?

As organizações não podem simplesmente declarar-se mais ágil. Elas devem esforçar-se para transformar três áreas chave:

• Implementar práticas de gestão de mudança;
• Implementar práticas de gestão de risco;
• Padronizar as práticas de gestão de projetos, programas e portfólios;

Organizações eficazes no gerenciamento de mudanças são mais ágeis, não só reduzindo o impacto das mudanças externas, mas também aproveitando novas oportunidades que elas podem apresentar.

Uma Gestão de Riscos eficaz ajuda as organizações a identificar e mitigar os fatores que poderiam sabotar o seu sucesso da organização.

Basicamente para Gestão de Mudanças e Gestão de Riscos estão fundamentados em:

• Monitorar e atuar o ambiente externo, detetando e avaliando as mudanças, os riscos e as oportunidades procurando  alavancar as mais significativas;
• Estabelecer processos formais para a Gestão de Mudanças e a Gestão de Riscos, para serem utilizados dentro e fora dos projetos;
• Implantação de um PMO atuante, atribuindo gerentes específicos para a Gestão de Mudanças e a Gestão de Riscos;
  

A Padronização de práticas de gerenciamento de projetos, programas e portfólios é uma necessidade, uma vez que, em função da volatilidade dos cenários atuais as organizações devem agir rapidamente.

Melhorar a Agilidade Organizacional requer um trabalho árduo, porém os resultados são bastante expressivos. Segundo o relatório do PMI, Pulse of the Profession, organizações mais ágeis possuem um índice de sucesso 30% maior que organizações que não possuem as práticas acima, quando comparamos tempo de implantação, custos, ROI e objetivos do projeto.

Agilidade Organizacional...

Agilidade Organizacional é uma tendência identificada pelo PMI em sua pesquisa Pulse of the Profession 2012. O cenário atual de crescimento econômico lento e de mudanças  das prioridades do mercado global criaram um ambiente complexo e arriscado para os negócios, que premia as inovações, bem como inviabiliza novos projetos.

Para forjar essa agilidade, as organizações bem-sucedidas estão agressivamente remodelando a sua cultura e as práticas de negócios em três frentes:

• Rigorosa gestão de mudança para melhor se adaptar às mudanças condições de mercado
• Gestão de risco mais colaborativa e robusta
• O uso crescente de padrões para gerenciamento de Projetos, Programas e Portfólios.

O relatório revela uma recompensa clara: as organizações altamente ágeis são duas vezes mais propensas a obter sucesso  com novas iniciativas do que aquelas que possuem agilidade baixa. 

De fato, devido ao ambiente econômico volátil nos últimos anos, apenas 45% das organizações relataram o sucesso com novas iniciativas, sendo as organizações que tem maior exito aquelas com níveis mais elevados agilidade, conferindo-lhes uma poderosa vantagem competitiva.

Mesmo antes da crise econômica, o papel da agilidade organizacional como vantagem competitiva foi apoiado por uma pesquisa da McKinsey. A maior parte dos entrevistados, classificou a agilidade organizacional tanto como fundamental para o sucesso do negócio e que tomadas de decisões rápidas são essenciais para tornar as organizações mais competitivas.

Agilidade também está ligada ao crescimento rentável: Pesquisa realizada pelo Massachusetts Institute of Technology (MIT) sugere que as empresas ágeis podem aumentar a receita 37 por cento mais rápido e gerar lucros de 30 por cento mais elevados do que as empresas não-ágeis.

Implantada da maneira correta, a Agilidade Organizacional, oferece benefícios em vários níveis, tais como:

• Resposta mais rápida às condições de mercado
• Mudanças organizacionais feitas mais rapidamente ou de forma eficiente
• Melhora da eficiência organizacional
• Conclusão mais rápida de projetos
• Satisfação do cliente
• Satisfação do funcionário
• Melhores resultados empresariais
• Economia de custos
• Identificação de riscos e melhores ações de mitigação

Agilidade Organizacional, por fim, não é a próxima bala de prata, porém está provando ser uma ferramenta poderosa para garantir o sucesso agora e no futuro.

Uma brincadeira com o carnaval

Não gosto de Carnaval, nesses dias prefiro descansar à folia de Momo. Mas vendo as reportagens sobre os desfiles das escolas de samba, resolvi analisar o desfile sobre a óptica do gerenciamento de projetos.

A Definição do Enredo - é o Business Case e o Termo de Abertura do Projeto. Imagino que as Escolas de Samba sempre gastem um bom tempo em pesquisa, definindo o tema, a história a ser contada no desfile, as responsabilidades primárias, etc... É um bom exemplo de TAP.

Depois do iniciado o projeto do desfile, certamente são definidos quais serão as entregas do projeto e seus pacotes de trabalho: Samba-enredo, alas, carros alegóricos, alegorias, fantasias, adereços, etc... Dessa forma é possível construir uma EAP.

Possivelmente um cronograma deve ter sido desenvolvido, mostrando os principais marcos desse projeto. O principal deles certamente é a grande noite do desfile.

Também as Escolas de Samba não devem esquecer os seus Stakeholders, principalmente a torcida e os jurados. O desfile deve influenciar cada jurado positivamente de forma que as maiores notas possam ser dadas a cada um dos quesitos. Levantar a galera na arquibancada durante o desfile também é uma forma de influenciar a expectativa de outras partes interessadas.

Durante todo o desfile, existem pessoas que controlam todos os movimentos da Escola: É diretor de harmonia, mestre da bateria, etc... Tudo para que a Escola de Samba faça do desfile um espetáculo.

E assim, após pouco mais de 60 minutos chega ao fim o desfile. Todo um esforço temporáro e coordenado. Chega ao fim um projeto de todo um ano com a certeza que durante todo o ano seguinte um novo projeto será executado para o carnaval do ano seguinte.

Processos existem para serem.... revistos (conclusão)

A Norma ISO 21500, define que o gerenciamento de projetos exige coordenação significativa entre os processos de gerenciamento de projetos e, como tal, requer que cada processo usado esteja apropriadamente alinhado e conectado com outros processos. Alguns processos podem ser repetidos várias vezes durante o ciclo de vida do projeto para que os objetivos do projeto sejam atingidos.

De maneira geral, os processos de Gerenciamento de Projetos são tratados em vários treinamentos como elementos distintos e com as interfaces bem definidas. No dia a dia vemos que eles se sobrepõem e se interagem.

Os processos descritos no PMBOK, na Norma ISO 21500, ou nos manuais das diversas metodologias de Gerenciamento de Projetos reconhecidas, não precisam e nem devem ser aplicados uniformemente em todos os projetos ou em todas as suas fases.

A comunidade de Gerentes de Projetos reconhece que há mais de uma maneira de gerenciar um projeto, dependendo de fatores como os, o risco, o tamanho, o prazo, a experiência da equipe do projeto, a disponibilidade de recursos, a quantidade de informações históricas, a maturidade da organização em gerenciamento de projetos, bem como os requisitos da área de aplicação e da indústria.

Por este motivo, a equipe de Gerenciamento de Projetos deve perguntar-se constantemente se os processos aplicados são adequados à realidade. Executamos os processos para satisfazer nosso ego de Gerentes de Projeto ou por que a organização que nos contratou realmente precisa de que o processo seja executado dessa forma.

Portanto, convém que o gerente do projeto adapte os processos de gerenciamento para cada projeto, fase, organização ou cliente, para determinar quais processos são apropriados e o grau de rigor a ser aplicado. Os processos de gerenciamento que estão desalinhados aos propósitos a que eles servem, devem ser revistos.

Processos existem para serem ... revistos

De uma forma abrangente, processos são os instrumentos da implementação das estratégias da empresa, isto é, das ações que a empresa precisa tomar para aproveitar as oportunidades e evitar as ameaças identificadas no ambiente de negócios.

Dentre inúmeros conceitos para o termo “processo”, acredito que as melhores definições sejam:

Uma série de tarefas ou etapas que recebem insumos (materiais, informações, pessoas, máquinas, métodos) e geram produtos (produto físico, informação, serviço), usados para fins específicos, por seu receptor;

Uma introdução de insumos (entradas) num ambiente, formado por procedimentos, normas e regras, que, ao processarem os insumos, transformam-nos em resultados que serão enviados (saídas) aos clientes do processo;

Uma seqüência de tarefas e atividades utilizadas na entrada (input), que agrega determinado valor e gera uma saída (output) para um cliente específico interno ou externo, utilizando os recursos da organização para gerar resultados concretos.

ATENÇÃO: Procedimentos, Métodos de Produção e Processo são coisas diferentes! Os dois primeiros definem a técnica pela qual se produz algo, enquanto o último define a forma como esta técnica é empregada.

Um projeto é um conjunto único de processos que consiste em atividades coordenadas e controladas com datas de início e fim, empreendidas para atingir resultados únicos. Igualmente a quaisquer outros processos, os processos de Gerenciamento de Projeto devem estar alinhados aos objetivos estratégicos de cada organização.

Os processos usados em projetos são geralmente categorizados em três principais tipos:

Processos de gerenciamento de projeto, os quais são específicos para gerenciamento de projeto e para determinar como as atividades selecionadas ao projeto são gerenciadas;

Processos de entrega, os quais não são exclusivos para gerenciamento de projetos, que resultam na especificação e fornecimento de um produto, serviço ou resultado específicos e que variam dependendo da entrega específica do projeto;

Processos de apoio, os quais não são exclusivos para gerenciamento de projeto e que fornecem apoio pertinente e valioso para produtos e processos de gerenciamento de projetos em disciplinas como logística, finanças, contabilidade e segurança.

Aliás, é importante ressaltar que os processos de Gerenciamento de Projetos, possuem as mesmas características que quaisquer outros processos empresariais, ou seja:

Todos os processos têm entradas, saídas, clientes e fornecedores;

Todos os processos têm múltiplas etapas, tarefas, operações ou funções executadas em sequência ou simultaneamente;

Geram um resultado ou produto identificável, que pode ser um produto físico, um relatório, dados/informações verbais, escritos ou eletrônicos, um serviço ou qualquer produto final identificável de uma série de etapas;

O resultado / produto tem um receptor identificável, que define sua finalidade, suas características e seu valor, seja esse receptor um cliente externo ou interno;

Podem ser de natureza interna (quando têm início, são executados e terminam dentro da mesma empresa) e externa (quando têm início dentro da empresa, são executados e terminam fora da empresa);

Possuem interfuncionalidade, quero dizer, a maioria dos processos de GP atravessa os seus próprios limites, os limites do grupo de processo e de suas áreas de conhecimento em que ele se encontra, servindo de insumos para outros processos de outros processos, grupo de processos e área de conhecimento.

Dentre os fatores de sucesso de um projeto está a seleção apropriada dos processos de cada organização necessários para atingir os objetivos propostos. Dessa forma, a partir do momento em que os processos de gerenciamento de projeto assumem um papel meramente burocrático, existe a necessidade de revê-los.

Continua na próxima postagem....

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.