Gestao de Projetos-Conceitos Fundamentais e Melhores Praticas

GESTÃO DE PROJETOS Carlos Augusto Freitas FGV INTRODUÇÃO Por diversas décadas observamos a necessidade de transformação por parte das organizações de qualquer negócio ou segmento em função dos efeitos provocados por fatores externos hoje em dia associado não somente à globalização mas também à era da informação Passamos por invenções e descoberta disruptivas como o surgimento da eletricidade 1753 lâmpada 1879 aviação 1906 e penicilina 1928 e alguns movimentos importantes como a Revolução Industrial 1760 a 18201840 e a transformação digital do mundo contemporâneo que gerou mudanças e impactos e em um futuro bem próximo irá conduzir as nações de todo o mundo a outros patamares tecnológicos O que esses marcos têm em comum Podemos citar algumas características visão integrada foco no resultado inovação e transformação Além disso todos são suportados por projetos As organizações têm o desafio de cada vez mais implementar projetos para a transformação imposta pela tecnologia globalização necessidade de revisão do modelo de gestão organização e da forma de fazer negócios Nesse contexto o papel do profissional de projetos se torna ainda mais importante É preciso assumir um protagonismo de liderança sem autoridade e conduzir um time com foco na entrega de resultados que irão suportar tal transformação Sob essa ótica analisaremos a importância e o valor da gestão de projetos para as organizações além de estudarmos algumas práticas recomendadas para aplicação de forma que se elevem as chances de sucesso dos seus projetos ilustrando o desafio imposto aos profissionais da atualidade Nesse sentido esta disciplina oferece reflexões e possibilidades de aplicação de melhores práticas de gerenciamento de projetos recomendadas de para a maior parte do tempo na maioria dos projetos e de qualquer natureza Para tal a disciplina tem como objetivo identificar os conceitos fundamentais sobre o valor do gerenciamento de projetos identificar os conceitos e as definições de gerenciamento de projetos conhecer os princípios e domínios do gerenciamento de projetos relacionar as melhores práticas referenciadas por 10 áreas de conhecimento e do modelo de 5 grupos de processos do guia PMBOK 7ª edição e consolidar um plano de projeto Seja bemvindo ao mundo dos projetos SUMÁRIO MÓDULO I VALOR DE GERENCIAMENTO DE PROJETOS 9 CONCEITOS E DEFINIÇÕES 10 O que é o PMI 11 O que é o guia PMBOK 11 Estrutura do guia PMBOK 6ª edição 12 Estrutura do guia PMBOK 7ª edição e o padrão do gerenciamento de projetos 14 PRINCÍPIOS E DOMÍNIOS DO GERENCIAMENTO DE PROJETOS 14 O que são princípios do gerenciamento de projetos 14 O que são domínios do gerenciamento de projetos 15 Estrutura do gerenciamento de projetos 16 Projeto 16 Programa 17 Portfólio 17 Projeto versus operações 19 Gerenciamento de projetos organizacional 21 Ciclo de vida do produto versus ciclo de vida do projeto 23 Tipos de ciclo de vida de projeto 24 Tailoring 24 Documentos de negócio 25 MÓDULO II AMBIENTES DE OPERAÇÃO DOS PROJETOS 27 INFLUÊNCIAS ORGANIZACIONAIS 27 Sistemas organizacionais 28 Estruturas organizacionais 28 Escritório de gerenciamento de projetos 31 PAPEL DO GERENTE DE PROJETOS 32 Responsabilidades do gerente de projetos 33 Habilidades comportamentais 34 Partes interessadas 35 Gerenciamento de projetos 35 MÓDULO III ESTRUTURA DO GERENCIAMENTO DE PROJETOS 37 GRUPOS DE PROCESSOS 37 ÁREAS DE CONHECIMENTO 38 Gerenciamento da integração do projeto 38 Gerenciamento do escopo do projeto 38 Gerenciamento do cronograma do projeto 38 Gerenciamento dos custos do projeto 38 Gerenciamento da qualidade do projeto 38 Gerenciamento dos recursos do projeto 39 Gerenciamento das comunicações do projeto 39 Gerenciamento dos riscos do projeto 39 Gerenciamento das aquisições do projeto 39 Gerenciamento das partes interessadas do projeto 39 PROCESSOS DE GERENCIAMENTO DE PROJETOS 40 Processos grupo de iniciação 40 Processos grupo de planejamento 41 Processos grupo de execução 42 Processos grupo de monitoramento e controle 43 Processos grupo de encerramento 44 VISÃO CONSOLIDADA 46 MÓDULO IV PRÁTICAS DE PROJETOS E OUTROS PADRÕES 47 PRÁTICAS DE GERENCIAMENTO DE PROJETOS 47 Plano de projeto 47 Declaração de escopo 48 Estrutura Analítica do Projeto EAP 49 Cronograma de projeto 53 Determinação do sequenciamento das atividades 55 Orçamento 55 Planejamento de custos 57 Ferramentas da qualidade 57 Matriz da comunicação e análise de partes interessadas 59 Matriz de recursos 61 Análise de riscos 62 Respostas aos riscos identificados 63 Processo de contratação 65 Administração de contrato 66 Planejamento ágil de projetos 66 Execução controle e encerramento 67 OUTROS PADRÕES 67 ISO 21500 67 PRINCE2 68 IPMA 70 Certificação 70 Scrum Alliance 71 Scrumorg 71 Aplicação dos dias de hoje 74 CONSIDERAÇÕES FINAIS 75 REFERÊNCIAS BIBLIOGRÁFICAS 76 SÍTIOS ELETRÔNICOS 77 PROFESSORAUTOR 78 Neste módulo vamos refletir sobre o valor do gerenciamento de projetos para as organizações e destacaremos a apresentação de conceitos definições e terminologia de gestão de projetos na visão do Guia PMBOK O ponto de partida para o profissional de projetos é conhecer o básico do conhecimento melhores práticas referência para a disciplina de fundamentos de projetos A partir desse ponto será possível compreender outros padrões métodos abordagens ferramentas e técnicas Um dos fatores que mais influenciam de forma negativa segundo estudos do PMI é a falta de conhecimento em gerenciamento de projetos ou seja existem muitas pessoas que gerenciam projetos sem ter conhecimento mínimo para isso o que compromete o resultado desejado pela organização executora MÓDULO I VALOR DE GERENCIAMENTO DE PROJETOS 10 Conceitos e definições Projeto não é algo novo e tem sido usado por centenas de anos Vejamos alguns exemplos Figura 1 Exemplos ilustrativos de projetos 11 O que é o PMI Fundado em 1969 USA o Project Management Institue PMI agrega valor a mais de 29 milhões de profissionais que trabalham em quase todos os países do mundo por meio de advocacy colaboração educação e pesquisa globais acesse PMIorg Sobre o Instituto em 2018 podemos destacar possui representação em mais de 120 países282 capítulos dos quais 15 capítulos estão no Brasil Programa de certificação internacional1 8 credenciais as maiores são PMP e CAPM Certified Associate in Project Management CAPM Project Management Professional PMP Program Management Professional PgMP Portfolio Management Professional PfMP PMI Professional in Business Analysis PMIPBA PMI Risk Management Professional PMIRMP PMI Scheduling Professional PMISP e PMI Agile Certified Practitioner PMIACP é responsável pelo Guia PMBOK base e referência de todo o conteúdo da nossa disciplina e que estaremos estudando mais à frente e outros padrões possui mais de 1000000 de profissionais estudantes e pesquisadores filiados ou cerificados em todo o mundo possui um modelo de filiação profissional e de estudantes com uma taxa a ser paga anualmente e oferece oportunidade de trabalho voluntário em todo o mundo inclusive no Brasil localmente e internacionalmente saiba mais em VRMSpmiorg O que é o guia PMBOK O Guia de conhecimento de gerenciamento de projetos Guia PMBOK Project Management Body of Knowledge é um conjunto de melhores práticas aplicadas na maior parte do tempo na maioria dos projetos de qualquer natureza O PMBOK é atualizado de quatro em quatro anos por voluntários e praticantes de gerenciamento de projetos de todo o mundo O guia encontra se na 7ª edição lançada em agosto de 2021 Abaixo será apresentada uma análise da 6ª edição PMI2017 e da atual edição 1 Cada certificação requer uma série de requisitos determinadas pelo PMI para tornarse aspirante habilitado para realizar o exame de certificação profissional reconhecido internacionalmente e específico para cada tipo de credencial Esse processo é chamado de elegibilidade e tem um custo associado Além disso existe o processo de renovação de certificação em acordo com o período determinado pelo processo CCRS Continuos Certification RS do instituto Para saber mais sobre o programa de certificação acesse o site oficial do PMI 12 É importante destacar que o PMBOK 1 é um guia e 2 não uma metodologia de gerenciamento de projetos Nesse sentido quando falamos de melhor prática isso significa reconhecimento geral o conhecimento e as práticas descritas são aplicáveis à maioria dos projetos na maior parte das vezes e existe um consenso em relação ao seu valor e à sua utilidade e boa prática existe um acordo geral de que a aplicação de conhecimento habilidades ferramentas e técnicas podem aumentar as chances de sucesso de muitos projetos em entregar o valor de negócio e os resultados esperados O PMBOK é um padrão de gerenciamento de projetos suportado pela ANSI American National Standards Institute Instituto Nacional Americano de Padrões nos EUA Estrutura do guia PMBOK 6ª edição O Guia PMBOK é dividido em três partes Parte 1 Guia de conhecimento em gerenciamento de projetos guia PMBOK 1 Introdução 2 Ambiente em que os projetos operam 3 Papel do gerente de projetos Áreas de conhecimento capítulos de quatro a 14 Parte 2 Padrão do gerenciamento de projetos 1 Introdução 2 Grupo de processos de iniciação 3 Grupo de processos de planejamento 4 Grupo de processos de execução 5 Grupo de processos de monitoramento e controle 6 Grupo de processos de encerramento Parte 3 Apêndices glossário e índice remissivo Apêndice X1 Mudanças da 6ª edição Apêndice X 2 Colaboradores e revisores do guia PMBOK sexta edição Apêndice X 3 Ambiente de projeto ágil iterativo adaptativo e híbrido Apêndice X 4 Resumo dos conceitos essenciais para áreas de conhecimento Apêndice X 5 Resumo das considerações sobre adaptação para áreas de conhecimento Apêndice X6 Ferramentas e técnicas Glossário 13 Na nossa disciplina abordaremos o conteúdo por meio de uma visão didática e simplificada com objetivo da compreensão da estrutura do gerenciamento de projetos do ambiente em que os projetos operam e das melhores práticas de gerenciamento de projetos Figura 2 Evolução do guia PMBOK da sexta para sétima edição Revisão do Padrão de Gerenciamento de Projetos e a migração da sexta para a sétima edição do Guia PMBOK e a plataforma de conteúdo digital do PMIstandardstm Guia PMBOK sexta edição Guia do conhecimento em gerenciamentode projetos Introdução ambiente do projeto e papel do gerente de projeto Áreas de conhecimento Integração Escopo Cronograma Custo Qualidade Recursos Comunicações Risco Aquisições Partes interessadas Padrão de gerenciamento de projetos Iniciação Planejamento Execução Monitoramento e controle Encerramento Apêndices glossário e índice remissivo Guia PMBOL sétima edição Padrão de gerenciamento de projetos Introdução Sistema de entrega de valor Princípios de gerenciamento de projetos Intendência Equipe Partes interessadas Valor Visão sistêmica Liderança Tailoring Qualidade Complexidade Risco Adaptabilidade e resiliência Change Guia do conhecimento em gerenciamento de projetos Domínios de desempenho de projetos Partes interessadas Equipes Abordagem de desenvolvimento e ciclo de vida Planejamento Trabalho do projeto Entrega Medição Incerteza Tailoring Modelos métodos e artefatos Apêndices glossário e índice remissivo Plataforma de conteúdo digital PMIstandardstm A plataforma vinculase ao Guia PMBOK através da seção Modelos métodos e artefatos expandindo ainda mais esse conteúdo para a plataforma 14 Estrutura do guia PMBOK 7ª edição e o padrão do gerenciamento de projetos O Guia PMBOK 7ª edição é dividido em duas partes Parte 01 Padrão de gerenciamento de projetos 1 Introdução 2 Um sistema de entrega de valor 3 Princípios de gerenciamento de projetos Parte 02 guia do conhecimento em gerenciamento de projetos 4 Introdução 5 Domínios de desempenho de projetos 6 Tailoring 7 Modelos métodos e artefatos 8 Apêndice x1 Colaboradores e revisores do Guia PMBOK 7ª edição 9 Apêndice x 2 Patrocinador 10 Apêndice x 3 Escritório de gerenciamento de projetos 11 Apêndice x 4 Produto 12 Apêndice x 5 Pesquisa e desenvolvimento para gerenciamento de projetos 13 Glossário Princípios e domínios do gerenciamento de projetos Os princípios e os domínios redefinirão o padrão de gerenciamento de projetos O que são princípios do gerenciamento de projetos Os princípios têm as seguintes características são verdades fundamentais possuem norma regra ou valor fundamental e tornamse um guia para o comportamento ou a avaliação no projeto E são acionáveis culturalmente neutros aplicados de diferentes maneiras um meio de determinar um guardrail claro e aplicados em todo e qualquer cenário de entrega de valor 15 De acordo com o PMBOK 7ª edição os princípios podem refletir a moral Um código de ética está relacionado à moral O código de ética e conduta profissional do PMI tem em sua base os quatro valores responsabilidade respeito equidade e honestidade Os princípios são apresentados abaixo sem nenhuma ponderação de ordem seja um administrador diligente respeitoso e atencioso crie um ambiente colaborativo para a equipe do projeto envolvase de fato com as partes interessadas concentrese no valor reconheça avalie e reaja às intereações do sistema demonstre comportamentos de liderança faça a adaptação de acordo com o contexto crie qualidade nos processos e nas entregas navegue pela complexidade otimize as respostas ao risco adote a capacidade de adaptação e resiliência aceite a mudança para alcançar o futuro estado previsto O que são domínios do gerenciamento de projetos Os domínios são um agrupamento de conceitos e de práticas com o objetivo de formar uma combinação de ferramentas e de técnicas elevando as chances de sucesso do projeto Exitem oito domínios de desempenho de projetos partes interessadas equipe abordagem de desenvolvimento e ciclo de vida planejamento trabalho do projeto entrega medição e incerteza 16 Estrutura do gerenciamento de projetos Nos dias atuais em estudo realizado sobre Projetos pelo Project Management Institute PMI a pesquisa The Pulse of the Profession sugere uma mudança positiva na forma como as organizações estão gerenciando projetos e programas Pela primeira vez em cinco anos mais projetos estão reunindo objetivos originais e intenção de negócios sendo concluídos dentro do orçamento Também houve um declínio significativo em dólares perdidos as organizações estão desperdiçando uma média de US 97 milhões para cada US 1 bilhão investido devido ao baixo desempenho do projeto isso representa um declínio de 20 um ano atrás As empresas empregam cada vez mais o conceito de Gerenciamento de Projetos com o objetivo de organizar e estruturar o cumprimento de demandas para o negócio seja inovação tecnológica desenvolvimento de um novo produto ou serviço responsabilidade social ou sustentabilidade construção de um prédio ou veículo aquisição de carteira entre outras Projeto Qual seria o conceito de projetos nessa história Um projeto é um esforço temporário empreendido para criar um produto serviço ou resultado exclusivo PMBOK 2017 Temporário significa que todos os projetos possuem um início e um final definidos Nesse sentido um projeto constrói entregas exclusivas mas uma característica importante é que todos os projetos serão únicos Desse modo podemos construir dois prédios iguais com mesmo escopo mas cada terá as suas respectivas caraterísticas Vejamos possui início e fim é único necessita de práticas adaptadas a partir do guia PMBOK é elaborado progressivamente e é feito por pessoas Todo projeto é elaborado progressivamente Á medida que o projeto avança adquirimos mais conhecimento sobre ele Por exemplo o escopo do projeto pode ser definido de maneira geral no início do projeto e é detalhado conforme aumentamos o entendimento sobre ele ou seja é uma característica que integra os conceitos de temporário e exclusivo Os resultados de um projeto alteram as naturezas das operações impulsionam mudanças geram benefícios e permitem a criação de valor de negócio 17 Há também o conceito de subprojetos considerados uma divisão de projetos visando facilitar o gerenciamento e o controle Esse conceito é normalmente usado quando há serviços contratados por uma empresa externa ou outra unidade funcional na organização Subprojetos divisão de projetos visando facilitar o gerenciamento e normalmente contratados por uma empresa externa ou outra unidade funcional na organização Programa Um programa é um conjunto de múltiplos projetos coordenados que podem possuir ou não uma relação entre si Já os projetos constituintes de um programa são necessariamente relacionados e dessa forma conseguem obter sinergia Como são geridos de forma coordenada os projetos que compõem o programa alcançam mais facilmente os seus objetivos Atendendo aos objetivos individuais eles conseguirão atender eventualmente aos objetivos do programa maior que são os próprios objetivos e benefícios estratégicos da organização Figura 3 Gestão de programas Portfólio Podemos definir portfólio como coleção de projetos ou programas e outros trabalhos que sejam agrupados de forma a facilitar o gerenciamento efetivo daquele trabalho para atender objetivos empresariais estratégicos 18 Para exemplificar a gestão de portfólio vamos definir um cenário clássico de uma grande organização que deseja determinar o orçamento para o próximo ano A diretoria financeira ou a área responsável solicita a todas as áreas que apresentem as suas necessidades para o próximo ciclo de execução A lista com as necessidades de todas as áreas da empresa que são candidatas a receberem ou não o recurso necessário para a sua execução O que a gestão de portfólio faz Com os recursos disponíveis aprovados para o próximo ciclo de execução pela alta administração e uma avaliação com base em critérios alinhados com a estratégica da organização com pesos definidos é definida uma lista priorizada por grau de relevância e impacto no negócio A gestão de portfólio responde a seguinte pergunta Se pudéssemos fazer somente um projeto por vez qual seria a ordem Ao longo do clico de execução no nosso exemplo de um ano a lista precisa ser revisada e atualizada por conta das tendências de mercado do grau de viabilidade das iniciativas e da velocidade constante da mudança Figura 4 Gestão de portfólio Fonte shutterstock 19 Para refletirmos sobre a integração de projetos programas e portfólio vamos analisar a figura a seguir do Guia PMBOK Figura 5 PMBOK Interação entre projetos programas e portfólio Sintetizando o portfólio responde à pergunta Se eu pudesse fazer um projeto por você qual seria a ordem Tal ordem seria definida com base em critério e objetivos estratégicos de maior impacto para o negócio e considera os recursos disponíveis Uma das principais diferenças entre programas e projetos que pode causar confusão em como e quando aplicar um ou outro é bem simples Vejamos Programa libera benefícios durante a sua execução A visão de programas ou seja gestão de múltiplos projetos é mais ampla e extensa do que a visão do projeto Projeto libera benefícios somente após o seu término Projeto versus operações Podemos dividir o trabalho das organizações em dois tipos projetos e operações A principal diferença entre elas é que projetos são temporários e únicos enquanto operações são contínuas e repetitivas 20 Por exemplo 1 as atividades de desenvolvimento ou construção de um sistema são consideradas projeto e 2 a manutenção pósimplantação do sistema é considerada operação contínua Atenção A visão de gestão das operações de uma organização não é contemplada pelo Guia PMBOK É importante apenas compreendermos a diferença entre atividades de um projeto algo temporário e das operações contínuas e repetitivas Quando falamos da criação de cultura do gerenciamento de projetos de uma organização existem diversos fatores que influenciam a aplicação dessas práticas além do fator humano estudaremos isso mais a frente No entanto as operações têm alta influência considerando mas não se limitando atenção da organização foco do executivo prioridade no momento de crise e impacto na cultura de projetos Por que isso acontece É bem simples porque o dinheiro vem de lá Lembrese disso É importante compreendermos que os profissionais de projetos precisam ter habilidades para lidar com essas características no momento de aplicação de práticas de gerenciamento de projetos Figura 6 Portfólio programas projetos e operações Fonte PMBOK 6ª edição Figura 13 21 Gerenciamento de projetos organizacional Podemos considerar ciclos desde a tomada de decisão até a implementação dos projetos estratégicos Observe que quanto maior a empresa maior a complexidade e os atores envolvidos Na figura a seguir o PMBOK apresenta a estrutura do gerenciamento de projetos organizacional Figura 7 Gerenciamento de projetos organizacionais Fonte PMBOK 6ª edição Figura 14 Usando a visão de uma grande empresa por exemplo podemos considerar um grupo de partes interessadas de alto poder versus influência que tomam da decisão do caminho a ser seguido pela organização no que diz respeito à estratégia Essa estrutura necessita ser desdobrada até o nível de execução ou seja é um desafio imposto às organizações para manter a real essência da sua estratégica na execução e com práticas que visam priorizar portfólio organizar múltiplas demandas programa executar projetos e atingir o sucesso pleno da transformação Observe a figura a seguir que ilustra o fluxo do processo decisões uma organização Nesse caso temos uma grande empresa lembrando que quanto menor for a empresa a quantidade de atores envolvidos do processo também se reduz Por exemplo em uma startup os sócios poderiam fazer o papel de decidir e executar projetos devido à limitação de recursos 22 Figura 8 Processo de decisão organizacional Fonte autor O Guia PMBOK 6ª edição determina cinco conceitoschave importantes para compreender as práticas a serem estudadas mais à frente Tabela 1 Conceitoschave do PMBOK ciclo de vida do projeto Série de etapas que um projeto passa do início até o término fases de um projeto Série de fases que um projeto passa do início até o término revisão de fase Análise no final de uma fase em que uma decisão é tomada em relação a passar para a fase seguinte ou iniciar uma nova fase continuar com modificações ou finalizar um programa do projeto processos de gerenciamento de projetos Série de atividades sistemáticas direcionadas para alcançar um resultado final de forma que se aja em relação a uma ou mais entradas a fim de criar uma ou mais saídas grupos de processos de gerenciamento de projetos Área de conhecimento de gerenciamento de projetos definida pelos seus requisitos e descrita em termos dos processos que a compõem práticas entradas saídas ferramentas e técnicas Atenção As fases de um projeto estão associadas diretamente à natureza do produto final previsto pelo projeto e não são os cinco grupos de processo iniciação planejamento execução monitoramento controle e encerramento 23 Exemplo 1 em um projeto de desenvolvimento de um sistema de informação poderíamos ter as seguintes fases requisitos desenvolvimento homologação e implantação Exemplo 2 em um projeto de construção de um prédio poderíamos ter as seguintes fases desenho básico desenho executivo obra e entrega das chaves Ciclo de vida do produto versus ciclo de vida do projeto Conforme estudamos anteriormente o ciclo de vida do projeto constitui as etapas que o processo passa desde a sua concepção até o seu encerramento Quando falamos de ciclo de vida do produto podemos considerar desde o dia em que nasce a ideia até o dia que o produto é descontinuado do mercado para sempre Observe a imagem a seguir Figura 9 Ciclo de vida produto Fonte shutterstock Ao longo do ciclo de vida de um produto existirão diversos N projetos que irão suportar as principais etapas de período da ideia à descontinuidade Para cada projeto haverá as respectivas fases e entrega Observa a figura 9 a seguir 24 Figura 10 Ciclo de vida projeto Fonte shutterstock Tipos de ciclo de vida de projeto As melhores práticas de gerenciamento de projetos devem ser adaptadas em acordo com a cultura organizacional ou seja cada organização determinará a forma como irá gerenciar os seus projetos No entanto o PMBOK em sua 6ª edição 2017 afirma que há dois tipos de ciclo de vida de projeto o preditivo e o adaptativo O primeiro é também chamado de ciclo de vida clássico pois os esforços seguem uma ordem prédefinida até a conclusão do projeto O ciclo de vida adaptativo de forma diversa é mais desenvolvido à medida que se desenrola o dia a dia do projeto ou seja as iterações sucessivas é que dão o ritmo do projeto e das suas entregas Dentro do ciclo de vida de cada projeto há geralmente uma ou mais fases associadas com o desenvolvimento do produto serviço ou resultado planejado pelo projeto Elas são chamadas de ciclo de vida de desenvolvimento Os ciclos de vida de desenvolvimento podem ser preditivos iterativos incrementais adaptativos ou um modelo híbrido Tailoring Normalmente os profissionais de projetos aplicam metodologias de gerenciamento de projetos nas organizações De acordo com o PMBOK uma metodologia é um sistema de práticas técnicas procedimentos e regras usadas por aqueles que trabalham em uma disciplina Reiterando o guia PMBOK não é uma metodologia Nesse sentido o guia PMBOK determina o que fazer e a metodologia determina como fazer As metodologias de gerenciamento de projetos podem ser desenvolvidas por especialistas de gerenciamento de projetos da organização ou adquiridas de fornecedores associações profissionais ou governamentais 25 A adaptação das melhores práticas é necessária porque cada projeto é único Não é uma verdade que todos os processos recomendados pela guia PMBOK são necessários para cada projeto Ao adaptar as práticas o profissional de projetos deve considerar diversos fatores que irão influenciar no modo como a prática será aplicada dentro de uma organização Documentos de negócio O gerente de projetos deve assegurar que o gerenciamento de projetos esteja alinhando com a estratégia da organização Existem documentos recomendados para essa ação Vejamos Business case documento de viabilidade técnica e econômica que visa definir e sustentar benefícios avaliar a contribuição do resultado final para o negócio e suportar a tomada de decisão ao longo da execução do projeto Plano de gerenciamento de benefícios plano que determina como medir os benefícios ou seja avaliar o pósprojeto e medir o resultado no text detected Neste módulo faremos uma reflexão sobre o ambiente no qual os projetos estão inseridos Devemos considerar a cultura os fatores ambientais e ativos que influenciam diretamente as organizações na aplicação de melhores práticas de gestão de projetos Conhecer o ambiente que um projeto está inserido tornase crítico para a aplicação adaptação das práticas de gerenciamento de projetos uma vez que elementos que fazem parte de um sistema organizacional algo muito maior do que o projeto influenciam diretamente o seu desempenho É importante compreender os tipos de estrutura as suas características e limitações para determinação de como serão usadas e aplicadas as práticas de gerenciamento de projetos que melhor se ajustam considerando a necessidade e a cultura organizacional Influências organizacionais Podemos considerar duas importantes categorias de influência que são 1 Ativos de processos organizacionais APOs são planos processos políticas procedimentos e bases de conhecimento específicos da organização e por ela usados São internos à organização 2 Fatores ambientais da empresa FAES referemse às condições fora do controle da equipe que influenciam restringem ou direcionam o projeto ou seja originamse do ambiente externo do projeto Nesse contexto podemos considerar cultura estrutura e governança organizacional distribuição geográfica de instalações e recursos normas governamentais ou do setor MÓDULO II AMBIENTES DE OPERAÇÃO DOS PROJETOS 28 infraestrutura por exemplo equipamentos e instalações administração de pessoal sistema de autorização da empresa condições de mercado e canais de comunicação Sistemas organizacionais Projetos operam dentro das restrições impostas pela organização por meio da sua estrutura e governança Tal estrutura irá influenciar diretamente em como uma prática de gerenciamento de projetos deve ser aplicada considerando a FAEs e após Estruturas organizacionais Inicialmente a visão considera três tipos de estruturas organizacionais funcional matricial e projetizada Para estudarmos os conceitos de cada estrutura vamos considerar duas características que um projeto possui em cada uma destas a saber grau de autonomia do gerente de projetos e membros de equipe do projeto Tabela 2 Tipos de estrutura de projetos visão inicial característica ou tipo de estrutura funcional matricial projetizada autonomia do gerente de projetos baixa ou quase nenhuma baixa a moderada alta ou quase total membro de equipe Após o término do projeto retorna para a sua atividade funcional por exemplo analista de sistemas engenheiro advogado entre outros Tempo divido em atividades de projeto ou de operações Recurso dedicado ao projeto Após o seu término não tem um lar garantido ficando na dependência de outros novos projetos observação Estrutura clássica orientada a hierarquia presidente vice presidente diretores gerentes coordenadores analistas e técnicos Estrutura clássica mas com atividades de gerenciamento de projetos permeando as áreas funcionais com profissionais desempenhando a função de gerente de projetos Estrutura orientada a projetos 29 Com o passar do tempo o avanço e o aprimoramento de práticas ferramentas e técnicas observouse novos tipos de estrutura A evolução da visão inicial passa para os seguintes tipos de estrutura orgânico ou simples funcional centralizado multidividsional matriz forte matriz fraca matriz equilibrada orientado a projetos virtual híbrido e EGP Para analisar melhor cada uma das estruturas observe a imagem a seguir com a respectiva características e configuração para o gerenciamento de projetos É importante ressaltar que qualquer empresa tem projetos acontecendo em uma ou diversos tipos de estrutura organizacional Tudo está relacionado em tamanho porte complexidade e maturidade da organização em gerenciamento de projetos 30 Tabela 3 Influências das estruturas organizacionais nos projetos 31 Fonte PMBOK Tabela 21 Escritório de gerenciamento de projetos A sigla PMO significa Project Management Office PMO em língua portuguesa Escritório de Gerenciamento de projetos EGP Podemos considerar que o PMO é uma célula ou núcleo com um ou N profissionais cujo principal objetivo é apoiar área setor departamento ou organização na gestão de projetos programas e portfólio por meio de práticas consolidadas no mercado Desse modo Os gerentes de projetos não devem OBRIGATORIAMENTE ficar subordinados ao PMO Os gerentes de projetos não devem OBRIGATORIAMENTE ser especialistas técnicos O PMO não CONTROLA e AVALIA pessoas e sim MONITORA e AVALIA os processos de gerenciamento de projetos para melhoria contínua O PMO não deve OBRIGATORIAMENTE gerenciar projetos operacionais versus estratégicos ou simples versus complexos 32 Tabela 4 Funções previstas para um PMO Fonte HILL 2014 Papel do gerente de projetos Atualmente o papel e a importância do gerente de projetos são reconhecidos em todo o lugar segundo pesquisa do PMI e outras associações É importante ressaltar que cada organização define em acordo com a sua cultura e maturidade como será a formalização ou não do gerente de projetos Esse papel pode ser uma função comprovada em carteira em acordo com a CLT por exemplo ou uma função acumulada por exemplo um engenheiro analista de sistemas ou advogado que assume o papel de gerente de projetos A nomenclatura também varia Vejamos a alguns exemplos de tipos de funções e nomenclaturas que definem o profissional responsável pelo gerenciamento de projetos gerente de projetos coordenador de projetos líder de projetos diretor de projetos analista de projetos coordenador técnico de projetos etc O papel do gerente de projetos é diferente de um gerente funcional ou de um gerente de operações Atenção O profissional especialista em gerenciamento de projetos está apto a gerenciar qualquer tipo de projeto em qualquer área segmento porte ou complexidade O fator experiência na função gerente de projetos impacta diretamente o desempenho de tal profissional 33 Uma característica importante a se avaliar ao definir a contratação ou a promoção de um profissional para desempenhar o papel do gerente de projetos é O profissional deve ser generalista ou especialista Generalista profissional de projetos que irá gerenciar projetos cujo produto final do mesmo seja de uma área diferente de sua formação Exemplo Um engenheiro gerenciamento projetos de Tecnologia da Informação Especialista profissional de projetos que irá gerenciar projetos cujo produto final do mesmo seja da área de sua formação Exemplo Um engenheiro gerenciamento projetos de OBRA Vamos avaliar quais são as vantagens e desvantagens de cada um Vejamos a tabela a seguir Tabela 5 Profissional de projetos especialista versus generalista perfil características habilidades importantes generalista não influenciado pelos vícios da experiência capacidade de delegar usar opinião especializada e desenvolver técnica de validação de entrega por evidência especialista influenciado pelos vícios da experiência apoio a tomada de decisão técnica e apoio a validação do produto do projeto Responsabilidades do gerente de projetos Podemos considerar três elementos essenciais para o profissional que gerencia projetos Conhecimento referese ao que o gerente de projetos sabe sobre o gerenciamento de projetos ou seja compreender o PMBOK metodologias e ferramentas e técnicas de gerenciamento de projetos Desempenho referese à capacidade de aplicar conhecimento em gerenciamento de projetos e está relacionado à experiência em gerenciamento de projetos Pessoal referese ao comportamento do gerente de projetos na execução do projeto ou atividade relacionada Desenvolvimento de habilidades comportamentais soft skills É recomendado pelo guia PMBOK e pelo processo de recertificação profissional do PMI o desenvolvimento em três tópicos gerenciamento técnico de projetos práticas ferramentas e técnicas liderança comportamental e gerenciamento estratégico e de negócios visão do negócio 34 O desafio do profissional de projetos é integrar ou seja a capacidade de entender o que realmente deve ser feito organizar a visão colocar todos os envolvidos na mesma página desenvolver pessoas e seguir a estrutura prevista para as melhores práticas de gerenciamento de projetos De fato é um profissional integrador Habilidades comportamentais A seguir observe algumas habilidades comportamentais importantes para o desempenho do profissional de projetos liderança construção de equipes motivação comunicação influência tomada de decisões consciência política e cultural negociação ganho de confiança gerenciamento de conflitos coaching etc É importante compreender que um profissional como qualquer pessoa possui pontos fortes e pontos de melhoria que requerem desenvolvimento A capacidade de delegar e usar o potencial de membros de equipe se torna um diferencial para o sucesso do projeto Observe a figura do PMBOK com as características de gerenciamento versus liderança Figura 11 Comparação entre gerenciamento e liderança da equipe gerenciamento liderança direta usando poder posicional guiar influenciar e colaborar usando poder relacional manter desenvolver administrar inovar foco em sistemas e estrutura foco em relacionamentos com pessoas apoiarse em controle inspirar confiança foco em metas de curto prazo foco em visão de longo alcance 35 gerenciamento liderança perguntar como e quando perguntar o que e por quê foco nos resultados foco no horizonte aceita o status quo questiona o status quo age corretamente faz o que é necessário fazer foco em questões operacionais e solução de problemas foco em visão alinhamento motivação e inspiração Fonte PMBOK Tabela 31 Partes interessadas São pessoas e organizações ativamente envolvidas no projeto ou cujos interesses podem ser afetados como resultado da execução ou do término do projeto As partes interessadas podem ter uma influência positiva ou negativa em um projeto Enquanto os interessados que exercem influência positiva veem um resultado bemsucedido dos projetos os que exercem influência negativa consideram que o projeto produzirá resultados negativos As principais partes interessadas em todos os projetos incluem mas não se limitam a gerente de projetos cliente ou usuário organização executora membros da equipe do projeto equipe de gerenciamento de projetos patrocinador e PMO Gerenciamento de projetos Quando falamos da definição do que é o gerenciamento de projetos consideramos que é a aplicação de conhecimentos habilidades ferramentas e técnicas às atividades do projeto de forma a garantir que os seus objetivos sejam atingidos O gerente de projetos é o responsável pelo sucesso ou fracasso do projeto Além disso existe uma responsabilidade do time do projeto pelo seu desempenho Entre algumas tarefas do gerente de projetos podemos citar identificar necessidades estabelecer objetivos claros e alcançáveis aplicar as práticas de gerenciamento de projetos comunicar de maneira objetivo com as principais partes interessadas desenvolver o time e integrar 36 O gerente de projetos contemporâneo possui desafios relacionados a aplicabilidade e adaptação das melhores práticas de forma simples habilidades comportamentais para lidar com pessoas de forma clara e efetiva conhecimento de tecnologia e visão e conhecimento do negócio A integração ou seja estabelecer uma visão integrada e alinhada entre todos os envolvidos se torna um dos maiores desafios ou seja é preciso colocar todos os envolvidos seja do nível técnico ou do nível executivo na mesma página Neste módulo apresentaremos a estrutura de gerenciamento de projetos na visão do Guia PMBOK do Project Management Institute PMI O guia PMBOK é o ponto de partida de para aplicação prática do gerenciamento de projetos É importante conhecermos sua estrutura baseada em melhores práticas para sermos capazes de adaptar na prática ou seja criar métodos sistemáticas ou mesmo uma solução de gestão de projetos para uma organização considerando todas as características estudadas no módulo anterior É importante ressaltar que a sequência das práticas que serão apresentadas neste módulo não representa um passo a passo método a ser seguido íntegra e sim um conjunto de processos ferramentas e técnicas que devem ser avaliados para adaptação e aplicação no dia a dia Grupos de processos Na visão do Guia PMBOK temos a seguinte estrutura 05 grupos de processos 10 áreas de conhecimento e 49 processos de gerenciamento de projetos Aqui iremos começar apresentando os grupos de processo O PMBOK determina cinco 05 grupos de processos iniciação planejamento execução monitoramento e controle e encerramento Vejamos cada um deles 1 iniciação formaliza o início de um novo projeto ou fase junto com as principais partes interessadas 2 planejamento estrutura o plano do projeto e os seus componentes auxiliares MÓDULO III ESTRUTURA DO GERENCIAMENTO DE PROJETOS 38 3 execução executa o plano com objetivo de concluir o trabalho definido para construção das entregas do projeto 4 monitoramento e controle acompanha as ações em execução e avalia o desempenho com base no plano avaliar o planejado versus realizado e 5 encerramento formaliza o término do projeto fase ou contrato junto com as principais partes interessadas Áreas de conhecimento O PMBOK possui na sua estrutura dez 10 áreas de conhecimentos integração escopo cronograma custos qualidade recursos comunicações riscos aquisições e partes interessadas Gerenciamento da integração do projeto O objetivo dos processos dessa área de conhecimento é definir unificar agrupar bem como coordenar vários processos e atividades de gerenciamento de projetos A integração é o maior desafio do gerente de projetos Gerenciamento do escopo do projeto O objetivo dos processos dessa área de conhecimento é assegurar que o projeto inclua todo o trabalho do projeto e somente o necessário para que termine com sucesso Gerenciamento do cronograma do projeto O objetivo dos processos dessa área de conhecimento é estruturar organizar e gerenciar as atividades de todo o trabalho a ser feito para que o projeto seja concluído com sucesso Gerenciamento dos custos do projeto O objetivo dos processos dessa área de conhecimento é estimar determinar e gerenciar os custos de todo o trabalho a ser feito Gerenciamento da qualidade do projeto O objetivo dos processos dessa área de conhecimento é determinar e garantir a conformidade dos processos de gerenciamento de projetos e produto final do projeto 39 Gerenciamento dos recursos do projeto O objetivo dos processos dessa área de conhecimento é determinar mobilizar desenvolver e gerenciar todos os recursos necessário para todo o trabalho a ser feito pelo projeto Podemos considerar recursos como pessoas equipamento material dinheiro tempo e tudo aquilo que for necessário para realizar o trabalho a ser feito Gerenciamento das comunicações do projeto O objetivo dos processos dessa área de conhecimento é definir organizar coletar distribuir e gerenciar todas as comunicações determinadas para o projeto Gerenciamento dos riscos do projeto O objetivo dos processos dessa área de conhecimento é identificar organizar analisar implementar as respostas e monitorar os riscos conhecidos do projeto Gerenciamento das aquisições do projeto O objetivo dos processos dessa área de conhecimento é determinar conduzir e gerenciar as aquisições necessário para realização do trabalho a ser feito pelo projeto Gerenciamento das partes interessadas do projeto O objetivo dos processos desta área de conhecimento é identificar engajar e gerenciar as partes interessadas do projeto Na figura a seguir podemos observar a visão integrada das dez áreas de conhecimentos Figura 12 Visão das dez áreas de conhecimento Fonte Freitas 2017 40 Processos de gerenciamento de projetos Agora iremos apresentar os 49 processos previstos pelo Guia PMBOK 6ª edição em duas visões por área de conhecimento e por grupo de processos A apresentação dessas visões é importante para compreender como o PMBOK 6ª edição está estruturado e como os processos estão conectados entre si Os processos serão apresentados com um código identificador no início que representa duas informações capítulo do PMBOK 6ª edição e número do processo da área de conhecimento Por exemplo 41 Desenvolver o Termo de Abertura do Projeto 4 Capítulo 04 do PMBOK 6ª edição Gerenciamento da Integração 1 Primeiro processo ou processo 01 da área de conhecimento de Integração Cada processo possui as respectivas entradas ferramentas e técnicas e saídas O detalhamento desses processos não será apresentado nesta apostila Conforme estrutura apresentada no item 121 Estrutura do guia PMBOK 6ª edição desta apostila temos os seguintes capítulos capítulo 04 gerenciamento da integração do projeto capítulo 05 gerenciamento de escopo do projeto capítulo 06 gerenciamento do cronograma do projeto capítulo 07 gerenciamento dos custos do projeto capítulo 08 gerenciamento da qualidade do projeto capítulo 09 gerenciamento de recursos do projeto capítulo 10 gerenciamento das comunicações do projeto capítulo 11 gerenciamento de riscos do projeto capítulo 12 gerenciamento das aquisições do projeto e capítulo 13 gerenciamento das partes interessadas do projeto Processos grupo de iniciação 41 Desenvolver o Termo de Abertura do Projeto área Integração 131 Identificar as partes interessadas área Partes Interessadas O principal objetivo desses dois processos é produzir o termo de abertura do projeto com as principais informações em alto nível para o patrocinador aprovar ou não o projeto Além desse documento a lista das partes interessadas também será elaborada 41 A título de adaptação das práticas no próprio documento TAP pode existir um tópico específico sobre partes interessadas Observe que fizemos a otimização de dois processos em um único documento As informações de um TAP estão em alto nível simplesmente porque o projeto ainda não foi aprovado e com isso não existem informações detalhadas Após a aprovação passamos para o grupo de processos de planejamento no qual a partir das informações do termo de abertura iremos detalhar os itens para definir o plano de projeto e os seus componentes auxiliares Vejamos exemplos de tópicos que podem constar em um termo de abertura do projeto TAP2 descrição objetivo ou justificativa do projeto principais entregas tempo estimado ou lista de marcos custo estimado benefícios numérico premissas restrições riscos geral do projeto3 critérios de aceitação gerente de projetos considerações e aprovação do patrocinador campo para assinatura Processos grupo de planejamento A seguir vejamos os processos do grupo de planejamento 42 Desenvolver o plano de gerenciamento do projeto área Integração 51 Planejar o gerenciamento do escopo área Escopo 52 Coletar os requisitos área Escopo 53 Definir escopo área Escopo 54 Criar EAP área Escopo 61 Planejar o gerenciamento do cronograma área Cronograma 62 Definir atividades área Cronograma 63 Sequenciar atividades área Cronograma 64 Estimar as durações das atividades área Cronograma 2 Esses tópicos são apenas exemplos de uma adaptação Não se limite a essa estrutura Cada organização pode trabalhar de acordo com a sua necessidade de informação para a decisão de aprovação de um projeto 3 Observe que estamos falando de riscos de maneira geral uma vez que o detalhamento e as práticas de gerenciamento de riscos somente iniciarão no grupo de processos de planejamento 42 65 Desenvolver cronograma área Cronograma 71 Planejar o gerenciamento de custos área Custos 72 Estimar custos área Custos 73 Determinar orçamento área Custos 81 Planejar o gerenciamento da qualidade área Qualidade 91 Planejar o gerenciamento dos recursos área Recursos 92 Estimar os recursos das atividades área Recursos 101 Planejar o gerenciamento das comunicações área Comunicações 111 Planejar gerenciamento de riscos área Riscos 112 Identificar riscos área Riscos 113 Realizar análise qualitativa de riscos área Riscos 114 Realizar análise quantitativa de riscos área Riscos 115 Planejar respostas para riscos área Riscos 121 Planejar o gerenciamento das aquisições área Aquisições 132 Planejar o engajamento das partes interessadas área Partes Interessadas O principal objetivo desses processos é estrutura o plano do projeto e os seus respectivos componentes auxiliares para formar as regras do jogo ou o como fazer o projeto É importante ressaltar que precisamos avaliar bem o ambiente no qual o projeto está inserido para a adaptação desses processos recomendados como melhores práticas Sendo assim podemos considerar mas não nos limitarmos somente No caso de a organização possuir uma metodologia de gerenciamento de projetos própria ou de alguma associação profissional muitos desses processos estarão definidos pelo método em si No caso de desenvolver o processo é preciso avaliar os APOs e FAEs para adaptação dos processos Como o PMBOK não é metodologia tais processos não devem ser seguidos como passo a passo e sim com referência para adaptação Ao estruturar o plano do projeto as linhas de base serão definidas para o projeto e utilizadas como referência para medição ao longo da execução do projeto ou seja avaliar o planejado versus realizado Processos grupo de execução A seguir vejamos os processos do grupo de execução 43 Orientar e gerenciar o trabalho do projeto área Integração 44 Gerenciar o conhecimento do projeto área Integração 82 Gerenciar a qualidade área Qualidade 43 93 Adquirir recursos área Recursos 94 Desenvolver a equipe área Recursos 95 Gerenciar a equipe área Recursos 102 Gerenciar as comunicações área Comunicação 116 Implementar respostas aos riscos área Riscos 122 Conduzir aquisições área Aquisições 133 Gerenciar o engajamento das partes interessadas área partes interessadas O principal objetivo desses processos é executar o plano de forma simples e objetiva Seguem algumas observações Não são todas as áreas de conhecimento que possuem processos no grupo de execução A partes de mobilização de recursos inclusive pessoas de desenvolvimento e de gerência de pessoas ocorre nesse grupo de processos Na execução ocorre o maior envolvimento humano do projeto uma vez que as entregas serão construídas pelos membros da equipe técnica do projeto Nesse grupo também ocorre a contratação aquisições determinadas pelo plano do projeto Processos grupo de monitoramento e controle A seguir vejamos os processos do grupo de monitoramento e controle 45 Monitorar e controlar o trabalho do projeto área Integração 46 Realizar o controle integrado de mudanças área Integração 55 Validar o escopo área Escopo 56 Controlar o escopo área Escopo 66 Controlar o cronograma área Cronograma 74 Controlar os custos área Custos 83 Controlar a qualidade área Qualidade 96 Controlar os recursos área Recursos 103 Monitorar as comunicações área Comunicações 117 Monitorar os riscos área Riscos 123 Controlar as aquisições área Aquisições 134 Monitorar o engajamento das partes interessadas área Partes Interessadas O principal objetivo desses processos é realizar as medições ao longo da execução do projeto comparando planejado versus realizado analisando as suas variações e propondo ações preventivas corretivas ou mudanças que visam manter o projeto conforme as linhas de base estabelecidas Seguem algumas observações 44 Esses processos são o meio de identificar problemas antes de eles ocorrerem levando a uma abordagem proativa e não reativa Cada área de conhecimento possui a sua base para medição Vamos a alguns exemplos escopo linha de base declaração de escopo estrutura analítica do projeto EAP e dicionário da EAP cronograma linha de base cronograma versão 0 ou versão mais atualizada aprovada pelo cliente e custos linha de base orçamento versão 0 ou versão mais atualizada aprovado pelo cliente Essas linhas de bases serão a referência para o monitoramento e controle O resulta da medição leva a três possíveis cenários 1 acima do planejado 2 conforme o planejado e 3 abaixo do planejado O alinhamento do projeto é mantêlo conforme o planejado É importante ressaltar que atrasar por exemplo atraso de 3 meses no projeto ou adiantar entrega do projeto com 4 meses de antecedência com grande variação não é uma boa prática uma vez que o seu planejamento não foi feito de maneira adequada comprometendo recursos da organização que poderiam estar sendo utilizados em outras áreas ou projetos Processos grupo de encerramento A seguir vejamos os processos do grupo de encerramento 47 Encerrar o projeto ou a fase área Integração O principal objetivo desse processo é formalizar o encerramento do projeto É importante ressaltar que esse processo é importante considerando dois cenários projeto ser cancelado e projeto ser concluído com sucesso Caso um projeto seja encerrado por qualquer motivo por exemplo inviabilidade técnica financeira mudança de estratégica perda de relevância é preciso encerrálo da mesma maneira como quando ele for encerrado com sucesso É importante realizar encerramento e pendências contratuais aprovação do cliente de entregas relacionadas a uma fase ou ao projeto desmobilização de recursos e registro de informações importantes para arquivamento do projeto e uso como aprendizado para projetos futuros 45 Um documento recomendado é o Termo de Encerramento do Projeto TEP A orientação é de que um projeto faça a implementação desses cinco grupos de processos considerando que processos são grupos de ações e atividades interrelacionadas e sobrepostas Os processos pertencerão sempre a um dos cinco grupos ou naturezas porém na prática eles serão realizados de forma interativa conforme esboçado pelas duas imagens a seguir Figura 13 Grupos de Processos de gerenciamento de projetos 46 Visão consolidada A seguir observe a figura que mostra a relação entre grupos de processos áreas de conhecimento e os 49 processos do guia PMBOK 6ª edição Figura 14 Visão consolidada estrutura de projetos guia PMBOK Neste módulo faremos uma reflexão sobre algumas práticas aplicadas do dia a dia metodologias de gerenciamento de projetos de outras instituições dedicadas à disseminação do gerenciamento de projetos no mundo bem como outros padrões que suportam a determinação e adaptação de práticas de gestão de projetos a serem aplicadas nas organizações As práticas apresentadas neste módulo representam exemplos práticos de alguns processos estudados no módulo anterior É importante ressaltar que não devem ser aplicadas como um método ou passo a passo e sim como exemplos para apoiar o dia a dia da organização Na segunda parte do módulo apresentaremos exemplos de outros padrões que ilustram visões complementares ao guia PMBOK constituindo exemplos para aplicações práticas do gerenciamento de projetos Práticas de gerenciamento de projetos Serão apresentados alguns exemplos de adaptação e aplicação de práticas de gerenciamento de projetos relevantes para a composição do plano de projeto É importante ressaltar que não se trata de uma metodologia e sim de alguns exemplos práticos Plano de projeto O plano do projeto determina todas as regras do jogo ou seja como o projeto deverá ser gerenciado considerando todas as áreas de conhecimento utilizadas MÓDULO IV PRÁTICAS DE PROJETOS E OUTROS PADRÕES 48 A seguir observe a figura com a visão do plano do projeto Figura 15 Visão do plano de projeto Declaração de escopo A declaração de escopo do projeto DEP é o documento descritivo que a partir do termo de abertura do projeto aprovado inicia o desdobramento e detalhamento do produto final do projeto Por isso mesmo a DEP é um dos documentos tidos como chave em toda a história de um projeto e do seu gerenciamento até a conclusão A seguir vejamos alguns tópicos que podem constar do documento de declaração de escopo do projeto nome do projeto objetivo do projeto produto final do projeto escopo funcional do projeto 49 documentação técnica por exemplo em um projeto de obra ou desenvolvimento de um sistema de informação podem ser utilizados manuais técnicos relacionados ao escopo do projeto documentação de referência por exemplo em um projeto de obra ou desenvolvimento de um sistema de informação pode ser utilizada documentação de referência com normas da área para reforçar as informações do escopo do projeto exclusões do escopo do projeto fatores críticos de sucesso análise preliminar dos riscos e critérios de aprovação do produto final A DEP dever ser elaborada de maneira colaborativa com os principais envolvidos com o objetivo de levantar informações importantes para o entendimento do produto final do projeto com base em informações confiáveis e na visão técnica consolidada Ao ser completada essa declaração servirá de input para a confecção da ferramenta da EAP conforme veremos a seguir Estrutura Analítica do Projeto EAP Umas das ferramentas mais poderosas recomendadas pelo guia PMBOK é a Estrutura Analítica do Projeto EAP ou WBS Work Breakdown Structure A ferramenta ilustra de forma simples a visão de todo o trabalho a ser feito pois pormenoriza os componentes mais elementares do projeto A EAP divide o produto do projeto em partes lógicas e interrelacionadas hierarquicamente Apesar de estar na área de conhecimento de escopo a EAP também é usada como ferramenta de comunicação uma vez que qualquer pessoa ao observar uma EAP deve ser capaz de ver todo o trabalho a ser feito Caso haja algo não contemplado ou seja que falta ser entregue pelo projeto a estrutura estará malfeita o que ocasiona diversos problemas impactando inclusive o resultado final previsto para o projeto Como a EAP divide os componentes do todo discriminando os elementos de escopo ela evita que qualquer trabalho seja esquecido A primeira técnica a ser utilizada para a composição da EAP é a decomposição ou seja assumir a visão do projeto e quebrar ou estruturar em pedaços são as famosas caixinhas No entanto existem algumas dicas para se estruturar a composição da estrutura por exemplo usando as fases do ciclo de vida do projeto em questão na decomposição da ferramenta Outra opção amplamente aceita é usar as entregas do projeto na 1ª decomposição O último nível de decomposição ou desmembramento de uma EAP chamase pacote de trabalho 50 A seguir observe uma estrutura analítica de um projeto simples Nesse caso um projeto de quatro fases em que a fase 1 está decomposta em quatro entregas a fase 2 está decomposta em quatro entregas a fase 3 está decomposta em duas entregas com a entrega 10 decomposta em dois pacotes de trabalho e a fase 4 mantémse somente com um único nível Figura 16 Exemplo fictício de estrutura analítica do projeto EAP Ao elaborar uma EAP uma das principais dúvidas é qual o limite de decomposição Como dica podemos considerar que ao decompor o nível superior serão necessários pelo menos dois filhos ou seja o mínimo de duas caixinhas no menor nível cada caixinha deve ter no mínimo oito horas de atividades e no máximo 80 horas de atividade Essa prática conhecida como regra 880h é recomendada pelo PMBOK No entanto pode ser adaptada para 8120h ou 8200h ou seja de acordo com a sua necessidade se o menor nível por exemplo estiver usando a regra 880h e possuir 240 horas de atividades significa que será necessário decompor em três pacotes de trabalho de 80 horas Esse é o ponto de atenção e 51 para saber a quantidade necessária em horas dias ou a forma de medição a ser utilizada para a realização das atividades será necessário elaborar o cronograma de atividades vamos estudálo no próximo item Vamos analisar alguns exemplos de EAPs lembrando que são projetos fictícios e que a cada projeto deve ser avaliada a melhor forma de decomposição a Exemplo 1 projeto de seminário de empreendedorismo Na figura a seguir observe a forma como a EAP está estruturada O projeto possui quatro fases Definição dos autores e temas Escolha do local e data Divulgação do evento e Montagem do evento Na prática o desenho de uma EAP é iniciado pela decomposição do escopomacro do projeto em blocos cada vez menores e de entregas progressivamente diminutas Esses desmembramentos chegam a um ponto ideal ou ao nível de detalhamento desejado de fim chamados de pacotes de trabalho Portanto os pacotes de trabalho são os menores níveis de uma EAP Figura 17 Exemplo fictício EAP projeto construção prédio b Exemplo 2 projeto de mapeamento de processos de negócio Na figura a seguir observe a forma como a EAP está estruturada O projeto possui quatro 04 fases entrevistas consolidação de processos ASIS consolidação de processo TOBE e treinamento 52 Observe que na fase 1 haverá três grupos a serem entrevistados para o entendimento dos processos e na última entrega documentação será consolidado o material das entrevistas dos três grupos Na fase 2 ocorrerá o desenho do processo como está atualmente chamado de AS IS No final da entrega da integração será produzido um mapa de processos na visão da integração das áreas de negócio da organização Na fase 3 ocorrerá o redesenho dos processos de como será o futuro dos processos de negócio considerando melhorias e otimização chamado de TOBE com a entrega final do mapa de processos Por fim na fase 4 haverá o treinamento de todos os envolvidos nos processos mapeados e desenhados Observe que todo o fluxo previsto para o trabalho a ser feito foi contemplado Figura 18 Exemplo fictício EAP projeto mapeamento de processos de negócio 53 Como dica apresentamos o método proposto por Vargas 2009 DECOMPOSIÇÃO para FASES tudo em letras maiúsculas exemplo FASE I ESTRUTURAÇÃO para ENTREGAS uso de substantivo em letra maiúscula exemplo HARDWARE para pacotes de trabalho uso de substantivos com primeira letra em maiúsculo exemplo Servidor de Aplicação para atividades uso verbos no infinitivo exemplo Configurar o Servidor de Aplicação e para marcos milestones uso verbo no particípio passado exemplo Servidor de Banco de Dados Configurado Cronograma de projeto O cronograma é uma ferramenta que apoia a aplicação de algumas práticas e técnicas Como exemplo um cronograma de uma grande obra com 3000 atividades O software de cronograma apoia a estruturação e organização dessas atividades considerando relacionamento lógico entre as atividades recursos envolvidos em cada atividade orçamento e outros itens Como dica devemos considerar que o ponto de partida para estruturação do cronograma é a EAP Isso é muito importante A estrutura inicial tem como base a estrutura analítica do projeto Vamos a um exemplo 1 PROJETO 11 FASE 1 111 ENTREGA 1 1111 PACOTE DE TRABALHO 111 ATIVIDADE 01 112 ATIVIDADE 02 113 ATIVIDADE 03 114 ATIVIDADE 04 115 ATIVIDADE 05 116 ATIVIDADE 06 54 Cada atividade deve determinar a data de início e a data de término os recursos envolvidos e outras informações relevantes para o plano do projeto Observe que nesse momento é definida a quantidade de horas de um pacote de trabalho da EAP É um momento importante para a decomposição da EAP e do CRONOGRAMA Lembrando que é importante criar um equilíbrio no grau de detalhamento das atividades relacionado diretamente ao tipo porte e à complexidade do projeto Exemplo de atividades ATIVIDADE 01 realizar instalação de sistema do data center RECURSOS ATIVIDADE 01 tempo 01 dia recursos 02 analistas de sistemas e custo R 90000 ATIVIDADE 02 realizar validação da fundação da obra RECURSOS ATIVIDADE 02 tempo 01 dia recursos 01 engenheiro e custo R 120000 ATIVIDADE 03 submeter documento final para aprovação do cliente RECURSOS ATIVIDADE 03 tempo 04 horas recursos 01 gerente de área e custo R 150000 Para reflexão sobre o grau de detalhamento de um plano é importante criar equilíbrio para justificar o esforço de gerenciamento Se for pouco você ganha velocidade mas não ganha controle Se for muito você ganha controle mas não ganha velocidade 55 Determinação do sequenciamento das atividades Após a elaboração da lista de atividades é importante estabelecer o relacionamento lógico entre elas Isso significa sequenciar essas atividades Na figura a seguir observe as sete atividades e os relacionamentos lógicos entre elas Porém é importante ressaltar que atualmente os cronogramas são feitos via ferramentas softwares ou seja concebidos de forma muito mais automatizada que antes Figura 19 Sequenciamento de atividades Orçamento O orçamento do projeto deve compor o valor recurso financeiro para todo o trabalho a ser feito considerando custos de todos os recursos envolvidos pessoas equipamento material capacitação contratação etc e reservas para o tratamento de riscos Uma técnica simples para determinar o orçamento é feita a partir da EAP determinando os custos dos componentes menores para os componentes maiores até determinar o custo total do projeto Vejamos um exemplo 56 Passo 1 determinar o custo dos componentes menores Figura 20 Elaboração orçamento Passo 2 determinar o custo dos componentes maiores Observe que a partir da determinação do custo dos pacotes de trabalho temos uma visão agrupada de baixo para cima Por exemplo O custo da fase 1 será a soma de todos os pacotes de trabalho nela associados nesse caso 03 pacotes O custo do projeto será a soma de todas as fases nele definidos Figura 21 Elaboração orçamento 57 Planejamento de custos O orçamento do projeto deve compor o valor recurso financeiro para todo o trabalho a ser feito considerando mas não se limitando a elementos ligados as áreas de qualidade riscos reservas orçamentárias aquisições Após a aprovação do orçamento de um projeto é importante determinar o fluxo de caixa O fato de um orçamento de R 100000000 estar aprovado não significa que o valor estará disponível em caixa no outro dia É preciso provisionar o desembolso para os pagamentos previstos para o projeto Por exemplo orçamento aprovado R 100000000 mês 1 mês 2 mês 3 mês 4 mês 5 R 200000 R 250000 R 150000 R 20000 R 20000 Ferramentas da qualidade Quando falamos de qualidade em projetos precisamos visualizar dois elementos o produto final do projeto e os processos de gerenciamento de projetos aplicados É preciso definir ferramentas que visam atestar conformidade com os itens acima Por exemplo Ferramenta check list definir uma lista de itens técnicos a serem verificados para aprovar uma entrega No momento da avaliação os itens serão checados e validados por alguém talvez um responsável técnico ou mesmo o cliente Uma vez validado e aprovado a entrega estará concluída ou uma solicitação de mudanças será enviada para eventuais correções ajustes ou alterações necessárias para atestar a conformidade do produto Além dos checklist existem outras ferramentas recomendadas A seguir observe alguns exemplos diagramas de causa e efeito fluxogramas listas de verificação diagramas de Pareto histogramas gráficos de controle e gráficos de dispersão 58 Para alguns projetos o gerente de projetos deve utilizar a opinião especializada para inspecionar validar e aprovar uma entrega antes de enviar para o cliente realizar a validação final Esse processo requer atenção já que impacta diretamente as expectativas das partes interessadas É importante ressaltar que a qualidade se torna uma grande oportunidade para as organizações por conta de itens como desperdício retrabalho perdas e outros fatores que ocasionam perda de dinheiro nas empresas anualmente pela negligência da qualidade Na figura a seguir observamos um fluxo proposto para a qualidade do projeto desde a definição de itens críticos para aprovação passando pela inspeção e validação da equipe técnica antes de enviar para o cliente realizar a aprovação final da entrega ou produto final do projeto considerando alguma reprovação ao longo do processo que leva o item avaliado ao passo anterior do fluxo até que se obtenha conformidade com o planejado Figura 22 Fluxo de qualidade do projeto O gerenciamento de projetos é extremamente colaborativo e a melhoria contínua se torna um fator importante para o desenvolvimento da cultura e maturidade do tema na organização Buscar melhorias e itens que ajudam ainda mais a agilizar simplificar e tornar a gestão eficiente é esperado pela etapa do processo Por exemplo a organização ainda não trabalha práticas de gestão de riscos Uma vez que os processos básicos relacionados a escopo tempo e custo estão em condições mínimas necessárias ou seja fazendo bem o básico é possível trabalhar os itens premissas e restrições como riscos identificados e com isso evoluir a aplicação da gestão dos riscos ao longo do tempo 59 Matriz da comunicação e análise de partes interessadas As partes interessadas determinam o caminho a seguir do projeto Principalmente as partes interessadas de alto poder e influência Como exemplo apresentamos o gráfico de poder versus influência que pode auxiliar a identificar as partes interessadas mais crítica e que devem ser gerenciadas já que para um projeto o número de partes interessadas pode ser tão grande a ponto de se tornar inviável gerenciar todas No entanto para aquelas de maior criticidade é importante serem gerenciadas Figura 23 Gráfico de poder versus influência Após a identificação e categorização das principais partes interessadas a matriz de comunicação é elaborada A matriz de comunicação determina uma série de eventos sobre como comunicação do projeto deve ser gerada coletada armazenada distribuída e rastreada durante o projeto Podemos considerar que a informação a ser contemplada neste processo deve gerar valor ao projeto A base para esta matriz são as principais partes interessadas do projeto Muitas vezes o gerente de projeto fala a mesma coisa porém de forma diferente Informação para o nível técnico do projeto e informação para o nível executivo ou seja cada um tem sua linguagem específica 60 É importante ressaltar que comunicação em excesso prejudica da mesma forma que pouca informação Tabela 6 Exemplo de matriz de comunicação 61 Matriz de recursos Os recursos de um projeto devem ser determinados para atender todo o trabalho a ser feito pelo projeto Nem mais nem menos Durante a elaboração do cronograma e orçamento os recursos devem ser determinados Observe a integração dessa área de conhecimento como as áreas de tempo e custos Nesse processo é importante considerar Quantidade de recursos já que quanto mais recursos grande é a probabilidade de redução de tempo e aumento de custos Sob a ótica de recursos humanos devese considerar experiência do profissional para dimensionar o tempo estimado para realização de atividades técnicas Em uma visão integração organização os projetos acabam concorrendo entre si pelos mesmos recursos Uma visão de mapa de recursos que prevê alocação ao longo de um ano nos diversos projetos deve apoiar o planejamento Observe o mapa de recursos a seguir Para cada recurso pode existir uma quantidade unidade número de pessoas madeira aço e custos associado a cada um para apoiar a composição de orçamento do projeto Figura 24 Mapa de recursos 62 Análise de riscos Riscos são incerteza que podem gerar impacto de forma positiva oportunidade ou negativa ameaça no projeto Temos riscos conhecidos ou seja aqueles que são identificados ao longo de todo o projeto e os riscos desconhecidos ou seja aqueles que não são mapeados por falta de conhecimento Tipos de riscos a Conhecidos que podem ser antecipados ser avaliados com relação à probabilidade e ao impacto e ter contramedidas b Desconhecidos não planejados e até então não conhecidos É importante reservar contingências esforço e custo para posteriormente auxiliar no tratamento do mesmo e aumentar a probabilidade e o impacto dos eventos positivos e diminuir a probabilidade e o impacto de eventos negativos no projeto A partir da EAP os riscos devem ser identificados pela equipe do projeto Após a lista de risco é necessário realizar análise que pode ser do tipo qualitativa ou quantitativa Técnicas de identificação de riscos brainstorming técnica utilizada para geração de ideias sobre o risco do projeto sob a liderança de um facilitador na qual participam além da equipe do projeto especialistas externos ao projeto técnica Delphi especialistas participam anonimamente buscando um consenso imparcial sobre os riscos do projeto sem influência da equipe interna entrevistas Realizadas com participantes experientes do projeto stakeholders e especialistas no assunto para identificação de riscos identificação da causa raiz investigação das causas essenciais dos riscos do projeto possibilitando o agrupamento de riscos por causas e design thinking conjunto de técnicas de incentivo à criação análise e ao levantamento de informações como apoio visual com objetivo de solucionar um problema 63 Para a etapa 1 identificação de riscos pode usar a ferramenta Estrutura Analítica de Riscos muito parecida com a EAP O objetivo é organizar a visão dos riscos conhecidos Observe a figura a seguir Figura 25 Exemplo de estrutura analítica de riscos Respostas aos riscos identificados O orçamento do projeto deve compor o valor recurso financeiro para todo o trabalho a ser feito considerando que para cada risco identificado será necessário descrição oportunidade e ameaça probabilidade impacto estratégia plano de resposta ao risco e responsável 64 A seguir observe os tipos de estratégia de resposta aos riscos positivos oportunidade e negativo ameaças a Estratégia para riscos positivos Tabela 7 Respostas para riscos positivos escalar repassar os riscos para o nível acima explorar adicionar trabalho ou mudar o projeto para garantir que as oportunidades ocorram compartilhar atribuir propriedade dos riscos a terceiros que são mais capazes de capturar a oportunidade melhorar aumentar a chance probabilidade e os impactos positivos de um evento de risco aceitar aceitar a ocorrência do risco positivo b Estratégia para riscos negativos Tabela 8 Respostas para riscos negativos escalar repassar os riscos para o nível acima prevenir ação para a eliminação da causa do risco transferir ação para transferência total ou parcial a terceiros das consequências do risco mitigar ação para reduzir a probabilidade ou as consequências de um risco negativo aceitar aceitar a ocorrência do risco negativo 65 Priorização dos riscos o objetivo dessa matriz além de detalhar a lista de riscos identificados é realizar uma priorização ou seja avaliar quais os riscos devem ser tratados por conta da probabilidade versus impacto nos objetivos do projeto e de acordo com a reservas financeiras para o tratamento de riscos Observe o modelo para tratamento e priorização de riscos a seguir Tabela 9 Exemplo de matriz de riscos código descrição do risco oportunidade ou ameaça probabilidade impacto estratégia plano de resposta ao risco responsável R1 descrever risco altomédiobaixo e descrever impacto descrever tratamento de risco descrever nome do responsável R2 descrever risco R3 descrever risco Cada Risco deve ter sua resposta que estará relacionado diretamente a atividades de cronograma e um custo que deve ser avaliado junto ao orçamento Processo de contratação A partir da EAP é identificado para qual ou quais entregas do projeto serão necessárias aquisições ou seja terceiros para proverem serviços ou produtos que irão contribuir para o produto final do projeto É importante ressaltar que muitas organizações possuem processo formalizado para compras ou contratação Nesses casos é preciso seguir o processo de acordo com o procedimento ou política interna O tempo do processo deve ser considerado no cronograma como atividades previstas ou seja o ciclo de contratação deve ser considerado no tempo do projeto Existem alguns tipos documentos que podem apoiar o processo de contratação do projeto por exemplo cartaconvite memorando de entendimento RFP Request For Proposal e edital técnico Devese ressaltar que o que um determinado fornecedor suprirá para o projeto é apenas uma parte de um todo O gestor do projeto terá que estabelecer inúmeras contratações com os diversos fornecedores necessários para os insumos do projeto Ademais observe que o ciclo de contratação está previsto para a entrega desde a cotação até a aquisição e entrega do produto contratado Vejamos 66 Fase 2 Projeto cotação10 dias contratação15 dias aquisição5 dias e desenvolvimento produto final contratado30 dias Administração de contrato Quando um projeto conta com aquisições ou seja o uso de serviços e produtos de terceiros é importante alinhar as atividades dos terceiros às atividades de projeto ou seja no cronograma Administrar um contrato é seguir e assegurar que o que está sendo entregue é exatamente o previsto pelo contrato assinado de forma que relacionamento entre ambas as partes será próspero e reiterando a visão projeto na visão do comprador e o projeto na visão do fornecedor Planejamento ágil de projetos Para exemplificar podemos citar o SCRUM que trata inicialmente de uma abordagem ágil originalmente criada para suportar projetos de desenvolvimento de software Atualmente é fato que outras áreas o aplicam integralmente ou parcialmente os seus processos Figura 26 Método SCRUM exemplo A SCRUM trata de a partir do produto desejado particionar pequenas entregas que serão priorizadas por ordem de valor e importância pelo cliente A equipe técnica constrói testa e entrega dentro de um ciclo iterativo previsto chamado de SPRINT que pode durar de 2 a 4 semanas A evolução da construção dessas pequenas entregas é acompanhada diariamente em reuniões de 10 minutos em que todos ficam em pé o nome em inglês seria standup meeting Além disso ocorrem as reuniões de planejamento do próximo ciclo e lições levantadas do último ciclo como a proposta de aumentar a eficiência do time Com papéis e responsabilidades bem definidas e o envolvimento das pessoas certas o método apoia a comunicação entre equipe e cliente reduzindo possíveis ruídos Tratase de uma aplicação prática que traz ganhos e agilidade nos processos de gestão 67 O método poderia ser aplicado a um pacote de trabalho da EAP em que a visão seria por sprints em nosso exemplo de 15 dias Ao de final desse ciclo algo seria entrega ao cliente com a percepção de valor Execução controle e encerramento Ao compor o plano do projeto estabelecemos a linha de base que será a referência para a medição ao longo da execução do projeto Observe que foram levantadas informações importantes sobre cada área de conhecimento relevante para o projeto para alinhar o entendimento sobre os objetivos e o produto final do projeto entre todos os envolvidos e o principal ter condições de tomar decisão de forma ágil ao ser observado desvios Após aprovação do plano junto às principais partes interessadas iniciase a execução de todo o trabalho a ser feito com base no planejado Periodicamente medições serão necessárias para decisão e reavaliação do projeto além de propor mudanças para os desvios identificados Lembrese de que o plano de projeto é o ponto de partida e ele será versionado diversas vezes até o final do projeto Outros padrões ISO 21500 De acordo com Krause 2014 a norma ABNT ISSO 21500 foi criada para ajudar as organizações no desenvolvimento das melhores práticas em gerenciamento de projetos As normas ISO são desenvolvidas nos seus comitês técnicos ISOTC que são organizados em uma base temática com representantes dos seus membros No Brasil a Associação Brasileira de Normas Técnicas ABNT é uma entidade privada sem fins lucrativos considerada de utilidade pública fundada em 1940 e reconhecida pelo governo federal como Fórum Nacional de Normalização A ABNT é a representante no Brasil da Organização Internacional de Normalização ISO A Estrutura da Norma ABNT NBR ISO 21500 é Capítulo 1 Escopo cobre a abrangência da norma e a sua aplicação nas organizações Capítulo 2 Termos e definições contém dezesseis termos e definições relacionados a gerenciamento de projetos São termos que não estão claramente apresentados na norma e não têm definição no dicionário Oxford English Dictionary Capítulo 3 Conceitos do gerenciamento de projetos descreve conceitos que representam uma importância relevante durante a execução dos projetos projeto gerenciamento de projeto estratégia organizacional e projetos ambiente dos projetos 68 governança de projetos projetos e operações partes interessadas e a organização do projeto competências da equipe do projeto ciclo de vida do projeto restrições dos projetos relacionamento entre os conceitos do gerenciamento de projetos e os processos e os conceitos estão centrados na geração de valor para as organizações Capítulo 4 Processos do gerenciamento de projetos identifica os processos recomendados que devem ser aplicados em todo o projeto ou fases do projeto Os processos são genéricos e podem ser utilizados por qualquer projeto ou organização O gerente de projeto ou patrocinador podem escolher como aplicar os processos e em que sequência de acordo com a cultura os recursos e as necessidades do projeto e da organização Os processos de gerenciamento de projeto podem ser vistos por duas perspectivas por grupo de processos no ponto de vista do gerenciamento de projetos por grupo de assuntos no ponto de vista de temas específicos PRINCE2 De acordo com a AXELOS o PRINCE2 é um dos métodos de gerenciamento de projetos mais amplamente adotado no mundo É usado por pessoas e organizações em vários setores diferentes PRINCE2 é composto por manual do PRINCE2 programa de certificação níveis de Foundation and Practitioner serviço de assinatura de suporte e outros manuais como o PRINCE2 Agile que combina as melhores práticas comprovadas do PRINCE2 com conceitos ágeis permitindo a entrega perfeita de produtos e projetos Os princípios temas e processos existentes do PRINCE2 permanecem consistentes mas enfatizamos alguns elementos em todas as orientações e exames A atualização coloca uma ênfase maior na adaptação do PRINCE2 às necessidades de organizações e ambientes de projeto permitindo que qualquer pessoa que esteja gerenciando um projeto obtenha o melhor da metodologia PRINCE2 Esses são os requisitos orientadores e as boas práticas que determinam se o projeto está sendo gerenciado genuinamente usando o PRINCE2 Existem sete princípios e a menos que todos sejam aplicados não é um projeto PRINCE2 Os princípios do PRINCE2 são Justificativa continuada de negócios também deve haver uma razão justificável para estar executando e gerenciando o projeto Caso contrário o projeto deve ser fechado 69 Aprenda com a experiência as equipes de projeto do PRINCE2 devem procurar e aproveitar continuamente as lições aprendidas em trabalhos anteriores Papéis e responsabilidades definidos a equipe do projeto PRINCE2 deve ter uma estrutura organizacional clara e envolver as pessoas certas nas tarefas certas Gerenciar por etapas os projetos do PRINCE2 devem ser planejados monitorados e controlados passo a passo Gerenciar por exceção as pessoas que trabalham no projeto devem receber a quantidade certa de autoridade para trabalhar efetivamente no ambiente Foco nos produtos os projetos do PRINCE2 se concentram nos requisitos de definição entrega e qualidade do produto Adaptar para se adequar ao ambiente do projeto O PRINCE2 deve ser adaptado para se adequar ao ambiente tamanho complexidade importância capacidade e risco do projeto Esses princípios descrevem aspectos do gerenciamento de projetos que devem ser abordados em paralelo ao longo do projeto Os sete temas explicam o tratamento específico exigido pelo PRINCE2 para várias disciplinas de gerenciamento de projetos e porque eles são necessários O PRINCE2 ajuda as pessoas a aplicarem os temas mas informando o requisito mínimo necessário para cada tema e fornece orientações específicas sobre como adaptar a determinados ambientes Os temas do PRINCE2 são os seguintes business case criação e manutenção de um registro da justificativa comercial do projeto organização definição dos papéis e das responsabilidades individuais de toda a equipe do projeto qualidade requisitos e medidas de qualidade e como o projeto os entregará planos etapas necessárias para o desenvolvimento dos planos e as técnicas do PRINCE2 que devem ser usadas risco efetiva identificação dos riscos e das oportunidades que possam impactar o projeto mudança como o gerente de projeto avaliará e agirá em mudanças no projeto e progresso viabilidade e desempenho contínuos dos planos e como e se o projeto deve prosseguir Esses temas descrevem as etapas do ciclo de vida do projeto desde a ideia inicial até o fechamento do projeto e a medição dos benefícios Cada processo fornece listas de verificação de atividades recomendadas responsabilidades relacionadas e orientação sobre como adaptar a um ambiente específico Os benefícios do PRINCE2 são um prático guia passo a passo para gerenciar com sucesso qualquer projeto um método flexível que pode ser adaptado a qualquer organização ou função envolvida no gerenciamento de projetos e uma certificação acessível e globalmente reconhecida que agrega valor ao seu currículo 70 As certificações PRINCE2 foram criadas para qualquer pessoa que gerencia projetos Isso varia do gerente de projeto dedicado aos profissionais que gerenciam projetos como parte do seu trabalho diário Eles também são relevantes para os envolvidos no projeto desenvolvimento e entrega de projetos As certificações são PRINCE2 Foundation PRINCE2 Praticioner e PRINCE2 Agile IPMA A IPMA International Project Management Association é uma associação internacional que congrega mais de 60 países Sediada na Holanda a IPMA foi criada em 1965 em Viena na Áustria Atualmente a sua fica na Holanda Representa associações de membros no nível global desempenhando um papel de liderança no desenvolvimento e promoção da profissão de gerenciamento de projetos fornecendo padrões e diretrizes para o trabalho de uma gama de talentos de gerenciamento de projetos por meio do IPMA Competence Baseline Possui um sistema de certificação de quatro níveis baseado em competências para gerentes de programas e projetos que é único no mundo e amplamente reconhecido pela sua qualidade A visão do IPMA é Promover competência em toda a sociedade para possibilitar um mundo em que todos os projetos sejam bemsucedidos Desse modo o IPMA definiu um padrão mundial para competências nas áreas de gerenciamento de projetos programas e portfólios Para os indivíduos definimos o IPMA Individual Competence Baseline ICB versão 4 definimos o padrão para projetos excelentes o IPMA Project Excellence Baseline ou o PEB e definimos o padrão para organizações o IPMA Competência Organizacional Baseline ou OCB Com base no ICB4 também definimos a linha de base de competências do IPMA para coaches treinadores e consultores no campo de projetos programas e portfólios o ICB4CCT Certificação Enquanto o IPMA gerencia o esquema de certificação de 4 níveis 4LC para indivíduos os organismos de certificação das associaçõesmembro do IPMA são responsáveis pelas avaliações individuais e pela certificação O processo de certificação envolve várias etapas para a avaliação de um candidato e é descrito em detalhes no International Certification Regulations ICR que você pode baixar na parte inferior da página Aqui apresentamos uma visão geral As etapas de avaliação para indivíduos são aplicadas a cada nível de competência A nível B nível C e nível D do IPMA Quando os candidatos atendem aos requisitos de competência eles podem se inscrever diretamente para o nível desejado Você não precisa começar no nível D e avançar para C e B e A 71 Os fluxos de processos descrevem os caminhos oficiais que são seguidos em todo o mundo Certified Projects Director Level A Certified Senior Project Manager Level B Certified Project Manager Level C e Certified Project Management Associate Level D Scrum Alliance Fundada em 2001 a Scrum Alliance é a maior e mais estabelecida e influente organização profissional de associação e certificação da comunidade Ágil Essa associação sem fins lucrativos certificou mais de 750000 profissionais em todo o mundo e a sua visão da associação resumese no lema Transforme o mundo do trabalho com a missão de orientar e inspirar indivíduos líderes e organizações com práticas princípios e valores que criem locais de trabalho que sejam alegres prósperos e sustentáveis Desse modo buscase Inspirar buscam inspirar indivíduos líderes e organizações a adotarem mentalidades Ágeis apoiando as suas transformações com treinamento e compartilhando histórias de mudança e inovação em empresas em todo o mundo Habilitar procuram habilitar o trabalho dos profissionais certificados e membros por meio de uma rede global de parceiros ágeis treinadores e treinadores desenvolvendo oportunidades de conteúdo e aprendizado incluindo webinars eventos globais e regionais grupos de usuários locais etc Guiar objetivam orientar a aplicação de práticas princípios e valores ágeis por meio de caminho de certificação de longa duração por meio de uma comunidade de treinadores e treinados focada em fornecer conhecimento habilidades e experiência que suportam transformações ágeis para indivíduos e organizações Scrumorg Baseado nos princípios do SCRUM e do Manifesto Ágil o Scrumorg fornece treinamento abrangente avaliações e certificações para melhorar a profissão de entrega de software Em todo o mundo as suas soluções e a comunidade de instrutores profissionais do SCRUM capacitam pessoas e organizações a obter agilidade por meio do SCRUM Ken Schwaber o cocriador do SCRUM fundou a Scrumorg em 2009 como uma organização global dedicandose a melhorar a profissão de entrega de software reduzindo as lacunas para que os produtos de trabalho e trabalho sejam confiáveis Inicialmente Ken Schwaber tentou desenvolver os programas do Scrumorg em outros lugares No entanto no final descobriu que para atingir o seu objetivo de melhorar o conhecimento o treinamento e as implementações do Scrum ele precisaria se separar e começar o Scrumorg 72 A seguir você pode encontrar um trecho de uma carta de Ken Schwaber para os treinadores e parceiros do Scrumorg que descreve por que ele começou o Scrumorg A carta foi escrita em 30 de março de 2010 e publicada em 15 de junho de 2010 Por quê Por que você encontrou o Scrumorg Eu tenho feito essas perguntas inúmeras vezes desde que criei o Scrumorg no outono passado Essa é a história da minha jornada com o SCRUM começando com a sua criação passando pelo estabelecimento e evolução e terminando com o meu trabalho com Scrumorg Essa jornada foi moldada por duas forças opostas o desejo de fazer a coisa certa e o desejo de ganhar dinheiro Eu formei o Scrumorg para reorientar os meus esforços em fazer a coisa certa Criando SCRUM A história do começo do SCRUM é bastante conhecida de forma que não vou gastar muito tempo aqui Jeff Sutherland e eu usamos o SCRUM há dez anos antes da reunião no Snowbird onde nós e outros assinamos o Manifesto Ágil Esse manifesto junto com o meu primeiro livro sobre SCRUM Desenvolvimento Ágil de software com SCRUM e o surgimento de ambientes modernos de desenvolvimento integrado IDEs ajudou o SCRUM a se espalhar como um incêndio no início dos anos 2000 Alguns anos depois Martin Fowler e eu estávamos voando de volta para Boston em uma conferência sobre o dimensionamento de projetos ágeis na Universidade de Calgary Ficamos desanimados porque muitos de nossos clientes não entenderam o que eram o Agile e o SCRUM Martin e eu decidimos que algum tipo de instrução e até mesmo certificação seriam necessárias para remediar a situação Eu desenvolvi um curso ScrumMaster de dois dias o primeiro dos quais foi conduzido no ObjectMentor em Chicago em 2002 Eu atestei os participantes como apenas isso os participantes e listei os seus nomes no meu site controlchaoscom Conduzi muitas dessas sessões de treinamento em 2002 e 2003 O curso se tornou mais refinado e baseado em experiência Começou a distinguir entre o que é SCRUM e como o SCRUM deve ser usado Eu considerei a aula um sucesso porque no meu trabalho de consultoria pude ver o quanto os melhores alunos da classe eram capazes de usar o SCRUM Recebi um ótimo feedback dos participantes do curso e quando a notícia se espalhou os cursos se tornaram extremamente populares 73 No início de 2009 mais organizações estavam usando processos ágeis do que processos em cascata e aqueles que empregavam Agile 84 estavam usando o SCRUM No entanto menos de 50 dos que usam o SCRUM estavam desenvolvendo iterações incrementais que são a pulsação do SCRUM Martin Fowler escreveu em seu blog que ele estava encontrando muitos exemplos de flaccid scrum As equipes estavam usando o vocabulário do SCRUM mas não conseguiram criar um incremento de funcionalidade potencialmente disponível em um único Sprint Eu lancei três iniciativas para remediar estes problemas criando o programa Scrum Developer Um dos maiores desafios de usar o SCRUM sempre foi a curva de aprendizado para os desenvolvedores da equipe No entanto como o SCRUM é uma prática de gerenciamento a maioria das pessoas que ensinaram o SCRUM não eram desenvolvedores atuais e estavam mal qualificadas para ensinar práticas de engenharia como desenvolvimento orientado a testes ou arquitetura emergente Eu queria criar um curso específico para abordar os desenvolvedores do SCRUM então entrei em contato com três organizações especializadas em ensinar aos outros como arregaçar as mangas e construir software usando o SCRUM Accentient Conchango e Microsoft Nós desenvolvemos um curso para desenvolvedores SCRUM visando à pilha de tecnologia NET Trabalhar com a Microsoft nos deu acesso a uma base sólida de treinadores e treinadores Microsoft MVPs e Inner Circle Partners Começando com a Microsoft também pudemos começar com uma pilha de tecnologia totalmente integrada Depois de lançarmos esse curso na primavera de 2010 juntamente com o Visual Studio 2010 trabalharíamos com outros parceiros para desenvolver cursos semelhantes direcionados a outras pilhas de tecnologia Formalizar o corpo de conhecimento do SCRUM e medira sua compreensão Como o SCRUM se espalhou também a confusão e o malentendido do SCRUM Jeff Sutherland e eu compilamos o corpo de conhecimento do SCRUM também conhecido como o Guia do SCRUM 74 Aplicação dos dias de hoje A SCRUM se tornou uma abordagem ágil popular aplicada em todo o mundo por ser um método sofisticado orientado ao que é mais importante focado em comunicação efetiva bem como no engajamento e no comprometimento de todos os envolvidos considerando os membros da equipe técnica o cliente e o facilitador do processo conhecido como SCRUM master É importante ressaltar que o método é orientado para desenvolvimento de produto e deve ser uma ferramenta usada na gestão de projetos Atualmente outras áreas além da tecnologia da informação software segmento no qual nasceu a abordagem aplicam técnicas e ferramentas do SCRUM nos seus projetos Lembrese de que a adaptação é fator chave de sucesso O seu projeto pode não usar todo o método na íntegra mas pode usar algumas partes da abordagem mesmo não sendo da área de tecnologia É importante lembrar que apresentamos somente alguns os mais utilizados no mundo exemplos de outros padrões de gerenciamento de projetos como referência e informação Para o profissional de projetos é importante compreender que quanto mais frameworks métodos ferramentas e técnicas conhecer maior será a sua liberdade de aplicação Atualmente o desafio está relacionado diretamente com compreender e conhecer bem o ambiente ao qual o projeto está inserido e modelar o conjunto de práticas da melhor maneira possível considerando todos os fatores que influenciam o projeto e os desafios da organização de forma simples e objetiva ou seja criar soluções de gestão em projetos Se a sua organização possui por exemplo uma metodologia lembrese de que há sempre espaço para melhoria contínua dos processos que visam simplificar e agilizar os processos aumentando a eficiência e ainda mais as chances de sucesso do projeto da sua empresa Projetos são o meio para qualquer transformação organizacional Pense nisso Desejo ótimos projetos de sucesso a você CONSIDERAÇÕES FINAIS 76 REFERÊNCIAS BIBLIOGRÁFICAS AXELOS Managing successful projects with PRINCE2 2017 Edition AXELOS 2017 Associação Brasileira de Normas Técnicas ABNT Disponível em httpwwwabntorgbrcee 93 Acesso em 15 de nov 2018 BARCAUI André et all PMO Escritórios de projetos programas e portfólio na prática 1 ed Rio de Janeiro Brasport 2012 FREITAS Carlos Augusto Certificação CAPM para membros de equipes e novos gerente de projetos 2 ed Rio de Janeiro Brasport 2014 FREITAS Carlos Augusto Gestão estratégica por meio de projetos programas e portfólio 1 ed Rio de Janeiro Brasport 2016 International Organization for Standardization Disponível em httpswwwisoorgstandard 50003html Acesso em 15 de nov 2018 PMI Project Management Institute Project manager competence development framework 3 ed Pensylvannia USA Project Management Institute 2017 PMI Project Management Institute The standard for program management 4 ed Pensylvannia USA Project Management Institute 2017 PROJECT MANAGEMENT INSTITUTE PMBOK Guide guia do Conhecimento em gerenciamento de projetos 6 ed Pensylvannia USA Project Management Institute 2017 PROJECT MANAGEMENT INSTITUTE PMBOK Guide guia do Conhecimento em gerenciamento de projetos 7 ed Pensylvannia USA Project Management Institute 2021 SOURCE HILL Gerard The complete project management office handbook 3 ed sl ESI Series 2014 VARELLA Lélio ANICETO Cirléa MOURA Graciele Aprimorando competências de gerente de projetos o sucesso no desempenho gerencial V 1 Rio de Janeiro Brasport 2010 77 VARGAS Ricardo Gerenciamento de projetos estabelecendo diferenciais competitivos 9 ed Rio de Janeiro Brasport 2018 VARGAS Ricardo Viana Manual Prático do Plano de Projeto 5 ed Brasport 2014 Sítios eletrônicos Project Management Institute wwwpmiorg PMI Brasil httpbrasilpmiorg Brightline Initiative httpswwwbrightlineorg Axelos Global Best Practice httpswwwaxeloscom IPMA httpswwwipmaworld Manifesto Ágil httpwwwmanifestoagilcombr 78 PROFESSORAUTOR Carlos Augusto Freitas é mestrando em Sistemas de Gestão pela Universidade Federal Fluminense formação superior em Gerência de Redes e Tecnologia de Sistemas e especialista em Docência do Ensino Superior em Ambientes Tecnológicos Possui diversos cursos de atualização e especialização como Redes de Telecomunicações PUC Rio Gerenciamento de Projetos de Software PUC Rio Gerenciamento de Projetos e CMMI UNI Rio e Ensino Superior a Distância Fundação Getulio Vargas Possui mais de 13 anos de experiência em Gestão de Projetos Programas e Portfólio e implantação de Escritório de Projetos PMOs em diferentes segmentos Também possui mais de 10 anos de experiência em educação treinamento e desenvolvimento gerencial em Gerenciamento de Projetos Nos últimos anos implantou mais de dez Escritório de Projetos PMOs em áreas como OilGas Logística TI Telecomunicações Engenharia e Industria Química em empresas de pequeno médio e grande porte aplicando gestão estratégica e suporte à governança de organizações por meio de práticas de projetos programas e portfólio É fundador e diretor executivo da CAF Facilities Management CAFFM empresa com foco em gestão estratégica com clientes em diversos portes e segmentos como Tecnologia da Informação Engenharia Indústria Turismo Serviços e Startups Também é professor da FGV desde 2008 No PMI RIO foi vicepresidente de desenvolvimento de projetos do PMI RIO 20102011 Em 2012 foi eleito vicepresidente executivo do PMI RIO 20122014 além de integrar o Comitê Mundial de Tradução do PMBOK 5a edição PMI 2013 Foi presidente do PMI RIO de 2015 a 2017 Além disso participa junto à ABNT ISO no Comitê Brasileiro da norma ISO 21500 FGV