Baixe o app para aproveitar ainda mais
Prévia do material em texto
Como citar este material: FREITAS, Carlos Augusto. Gestão de Projetos. Rio de Janeiro: FGV, 2023. Todos os direitos reservados. Textos, vídeos, sons, imagens, gráficos e demais componentes deste material são protegidos por direitos autorais e outros direitos de propriedade intelectual, de forma que é proibida a reprodução no todo ou em parte, sem a devida autorização. 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 1820/1840) 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® - 6ª e 7ª edição e consolidar um plano de projeto. Seja bem-vindo ao mundo dos projetos! SUMÁRIO MÓDULO I – VALOR DE GERENCIAMENTO DE PROJETOS .................................................................. 7 PRINCÍPIOS E DOMÍNIOS DO GERENCIAMENTO DE PROJETOS ................................................... 8 O que são princípios do gerenciamento de projetos? .......................................................... 8 O que são domínios do gerenciamento de projetos?........................................................... 9 CONCEITOS E DEFINIÇÕES .............................................................................................................. 10 Projeto .................................................................................................................................. 11 Programa ............................................................................................................................. 11 Portfólio ............................................................................................................................... 12 Projeto versus operações ................................................................................................... 14 Gerenciamento de projetos organizacional ................................................................... 15 Tailoring ..................................................................................................................................... 17 Documentos de negócio ......................................................................................................... 17 MÓDULO II – AMBIENTES DE OPERAÇÃO DOS PROJETOS ............................................................... 19 ESTRUTURA DO GERENCIAMENTO DE PROJETOS ....................................................................... 19 INFLUÊNCIAS ORGANIZACIONAIS .................................................................................................. 20 Sistemas organizacionais ........................................................................................................ 20 Estruturas organizacionais ..................................................................................................... 20 Criação de valor ....................................................................................................................... 23 Fluxo de informações .............................................................................................................. 24 Escritório de gerenciamento de projetos ............................................................................. 24 PAPEL DO GERENTE DE PROJETOS ................................................................................................ 26 Responsabilidades do gerente de projetos.......................................................................... 27 Habilidades comportamentais ............................................................................................... 27 Partes interessadas (ou stakeholders) ................................................................................... 29 Gerenciamento de projetos ................................................................................................... 29 MÓDULO III – ESTRUTURA DO GERENCIAMENTO DE PROJETOS .................................................... 31 CICLO DE VIDA DO PRODUTO VERSUS CICLO DE VIDA DO PROJETO ........................................ 31 TIPOS DE CICLO DE VIDA DE PROJETO .......................................................................................... 33 Ciclo de vida preditivo ............................................................................................................. 33 Ciclo de vida iterativo .............................................................................................................. 37 Ciclo de vida incremental ........................................................................................................ 37 Ciclo de vida adaptativo .......................................................................................................... 38 Ciclo de vida híbrido ................................................................................................................ 39 MÓDULO IV – PRÁTICAS DE PROJETOS E OUTROS PADRÕES .......................................................... 41 PRÁTICAS DE GERENCIAMENTO DE PROJETOS ............................................................................ 41 Plano de projeto ....................................................................................................................... 41 Declaração de escopo ............................................................................................................. 42 Estrutura Analítica do Projeto (EAP) ...................................................................................... 43 Cronograma de projeto .......................................................................................................... 46 Determinação do sequenciamento das atividades ............................................................. 47 Orçamento ................................................................................................................................ 48 Planejamento decustos .......................................................................................................... 49 Ferramentas da qualidade ..................................................................................................... 49 Matriz da comunicação e análise de partes interessadas (stakeholders) ......................... 51 Matriz de recursos ................................................................................................................... 53 Análise de riscos....................................................................................................................... 54 Respostas aos riscos identificados ........................................................................................ 55 Processo de contratação ........................................................................................................ 57 Administração de contrato ..................................................................................................... 58 Execução, controle e encerramento ..................................................................................... 58 PRÁTICAS DE GERENCIAMENTO DE PROJETOS – CICLO ADAPTATIVO ...................................... 59 Visão de Produto ...................................................................................................................... 59 ITERAÇÕES OU SPRINT ..................................................................................................................... 59 Quadro de Atividades .............................................................................................................. 60 Papéis & Responsabilidades .................................................................................................. 62 Gestão de Mudanças ............................................................................................................... 62 INSTITUIÇÕES E PADRÕES DE GERENCIAMENTO DE PROJETOS ............................................... 62 O que é o PMI? ......................................................................................................................... 62 O que é o guia PMBOK®? ....................................................................................................... 63 ISO 21.500 ................................................................................................................................. 64 PRINCE2® ................................................................................................................................. 65 IPMA ........................................................................................................................................... 67 Scrum Alliance® ....................................................................................................................... 67 Scrum.org .................................................................................................................................. 68 Aplicação dos dias de hoje ..................................................................................................... 68 CONSIDERAÇÕES FINAIS ..................................................................................................................... 69 REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................................................... 70 SÍTIOS ELETRÔNICOS ....................................................................................................................... 71 PROFESSOR-AUTOR ............................................................................................................................. 72 CARLOS AUGUSTO FREITAS ............................................................................................................ 72 Formação acadêmica .............................................................................................................. 72 Experiência profissional .......................................................................................................... 72 Premiações ............................................................................................................................... 73 Neste módulo, vamos refletir sobre o valor do gerenciamento de projetos para as organizações e destacaremos a apresentação de princípios, domínios, conceitos, definições e terminologia de gestão de projetos na visão do Guia PMBOK® (Project Management Body of Knowledge) sustentado pelo Project Management Institute (PMI®), a maior associação profissional do mundo dedicada ao gerenciamento de projetos, que trata de um conjunto de melhores práticas aplicadas na maior parte do tempo, na maioria dos projetos de qualquer natureza, além de outras referências. 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. 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. MÓDULO I – VALOR DE GERENCIAMENTO DE PROJETOS 8 Princípios e domínios do gerenciamento de projetos Os princípios e os domínios (re)definirã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 tornam-se 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. 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; envolva-se de fato com as partes interessadas; concentre-se no valor; reconheça, avalie e reaja às interaçõ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. 9 Os princípios representam uma base filosófica para aplicação de práticas. Os princípios acima abordam conceitos, práticas e habilidades que iremos estudar ao longo da disciplina de gestão de projeto, além de direcionar um comportamento esperado por indivíduos de uma organização. 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 (ou stakeholders); equipe; abordagem de desenvolvimento e ciclo de vida; planejamento; trabalho do projeto; entrega; medição e incerteza. Os domínios representamvariáveis de alto impacto para a gestão de projetos como um todo. Além, disso, fornece campos de conhecimento e fatores a serem trabalhados com cuidado e atenção na aplicação das práticas 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 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. 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. 12 Figura 3 – Gestão de programas Fonte: AUTOR 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. 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). 13 Figura 4 – Gestão de portfólio Fonte: shutterstock. 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 14 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. Por exemplo: 1. as atividades de desenvolvimento ou construção de um sistema são consideradas projeto e 2. a manutenção pós-implantaçã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á. Lembre-se 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. voltar aqui 15 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: AUTOR 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. 16 Figura 8 – Processo de decisão organizacional Fonte: AUTOR O Guia PMBOK® determina cinco conceitos-chave importantes para compreender as práticas (a serem estudadas mais à frente): Tabela 1 – Conceitos-chave 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, doiní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). 17 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. 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. 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ós-projeto e medir o resultado. 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 torna-se 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. Além disso, é importante compreendermos o contexto da entrega de valor, governança, funções de projeto, ambiente do projeto e gerenciamento do produto. 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. MÓDULO II – AMBIENTES DE OPERAÇÃO DOS PROJETOS 20 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. 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) – referem-se às condições fora do controle da equipe que influenciam, restringem ou direcionam o projeto, ou seja, originam-se 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; 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. 21 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. Com o passar do tempo, o avanço e o aprimoramento de práticas, ferramentas e técnicas, observou-se 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. 22 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 acontecendoem uma ou diversos tipos de estrutura organizacional. Tudo está relacionado em tamanho, porte, complexidade e maturidade da organização em gerenciamento de projetos. Tabela 3 - Influências das estruturas organizacionais nos projetos 23 Fonte: PMBOK® Tabela 2-1. Criação de valor A entrega / produto final de um projeto criar uma capacidade de geração de valor pela transformação proporcionada pelo resultado. Como exemplos: (i) Criação de um novo produto, serviços ou resultados, (ii) criação de contribuições sociais e ambientais, (iii) Aprimoramento de processos críticos, (iv) resposta à necessidades impostas pelo mercado e (v) sustentação de benefícios criados por programas ou outros projetos anteriores. Além disso, é importante compreendermos o contexto da entrega de valor, governança, funções de projeto, ambiente do projeto e gerenciamento do produto. 24 Figura 9 - Componentes de um exemplo de sistema de entrega de valor Fonte: Figura 2.2 - PMBOK 7ª edição Fluxo de informações Um sistema de entrega de valor funcionar a partir de alinhamento entre as informações e feedback compartilhados entre todos os componentes, mantendo o sistema alinhado com a estratégia e sintonizado com o ambiente. 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. 25 Tabela 4 – Funções previstas para um PMO Fonte: (HILL, 2014). Organizações que contem com um escritório de projetos podem desempenhar um papel de revisão e aprovação (periodicamente) após o processo de tailoring. A adaptação de práticas de projetos requer conhecimento especializado. Quando uma organização define determinar um método de trabalho padronizado, temos algumas opções: 1. Adquirir um método de mercado, como por exemplo o Prince2®. Neste caso, se faz necessário capacitação e desenvolvimento dos profissionais com o objetivo de implementar os processos de executar projetos de maneira padronizada. É importante ressaltar que o método definido pode necessitar de adequações, uma vez cada organização tem sua cultura. 2. Desenvolver um método próprio (híbrido). O conhecimento especializado, a partir de referências de melhores práticas (por exemplo PMBOK®) e outros métodos, estrutura um padrão a ser seguido em processos, abordagem de entrega, ciclo de vida, ferramentas e técnicas totalmente adaptados à realidade da organização. A partir de um padrão definido, o PMO deve prover a sustentação destas práticas, por meio de capacitação, uso de um software de gerenciamento de projetos, revisão e atualizações periódicas, auditorias em projetos executados pelo método, suporte a tomada de decisão, dentre outras. 26 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. 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: 27 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 – refere-se 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 – refere-se à capacidade de aplicar conhecimento em gerenciamento de projetos e está relacionado à experiência em gerenciamento de projetos. Pessoal – refere-se 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 (re)certificaçã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). 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; 28 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 gerenciamentoe 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 apoiar-se em controle inspirar confiança foco em metas de curto prazo foco em visão de longo alcance 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 3-1. 29 Partes interessadas (ou stakeholders) 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 bem-sucedido 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. 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. 30 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”. A compreensão destes conceitos adaptados no contexto de uma organização, modelam a definição do que é sucesso na implementação de projetos. O sucesso se constrói deste o entendimento do ambiente da organização executora, a construção (adaptada) de uma solução de gestão baseadas em princípios, domínios, processos, artefatos e ferramentas & técnicas e o comportamento dos envolvidos (pessoas) em direção ao resultado. Neste módulo, apresentaremos a estrutura de gerenciamento de projetos. O guia de melhores práticas é 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. 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: MÓDULO III – ESTRUTURA DO GERENCIAMENTO DE PROJETOS 32 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. Observe a figura 10 a seguir: Figura 10 – Ciclo de vida projeto Fonte: shutterstock. 33 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 apresenta 5 (cinco) tipos de ciclo de vida, a saber: PREDITIVO, INCREMENTAL, ITERATIVO, ADAPTATIVO e HÍBRIDO. 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, além de representar um meio, uma forma de tratar o projeto em direção ao resultado. A forma como será feito o tailoring (adaptação das práticas) no projeto é influenciada pelo tipo de ciclo de vida definido para o projeto. Cada tipo de ciclo de vida representa uma combinação de práticas, processos, ferramentas e técnicas que iremos apresentar a seguir. Ciclo de vida preditivo Escopo, prazo e custo determinados nas fases iniciais do ciclo de vida Como exemplo, projetos com ESCOPO em alto nível de compreensão, como por exemplo uma obra (construção de um prédio ou ponte). Uma ferramenta que suporte o tipo de ciclo de vida PREDITIVO é o modelo GRUPO DE PROCESSOS, que responde bem a projetos com características de clareza do ESCOPO e o trabalho a ser feito e, que necessita de nível detalhados de controle de elementos do projeto como atividades, custos, riscos, dentre outros. 34 Figura 11 – ferramenta: modelo grupo de processos Fonte: Autor. O modelo – Grupo de Processos é composto por: (i) Grupo de Processos, (ii) Áreas de Conhecimento e (iii) Processos de Gerenciamento de Projetos. (i) Os GRUPOS DE PROCESSOS são formados por: 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; 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. (ii) As ÁREAS DE CONHECIMENTO são formadas por: integração, escopo, cronograma, custos, qualidade, recursos, comunicações, riscos, aquisições e partes interessadas. 35 Tabela 06 – áreas de conhecimento (modelo grupo de processos) ÁREA DE CONHECIMENTO DESCRIÇÃO INTEGRAÇÃO 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 ESCOPO 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. CRONOGRAMA 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. CUSTOS O objetivo dos processos dessa área de conhecimento é estimar, determinar, egerenciar os custos de todo o trabalho a ser feito. QUALIDADE O objetivo dos processos dessa área de conhecimento é determinar e garantir a conformidade dos processos de gerenciamento de projetos e produto final do projeto, RECURSOS O objetivo dos processos dessa área de conhecimento é determinar, mobilizar, desenvolver e gerenciar todos os recursos necessários 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. COMUNICAÇÃO O objetivo dos processos dessa área de conhecimento é definir, organizar, coletar, distribuir e gerenciar todas as comunicações determinadas para o projeto. RISCOS O objetivo dos processos dessa área de conhecimento é identificar, organizar, analisar, implementar as respostas e monitorar os riscos conhecidos do projeto. AQUISIÇÕES O objetivo dos processos dessa área de conhecimento é determinar, conduzir e gerenciaras aquisições necessárias para a realização do trabalho a ser feito pelo projeto. PARTES INTERESSADAS O objetivo dos processos dessa área de conhecimento é identificar, engajar e gerenciar as partes interessadas do projeto Fonte: autor. 36 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). (iii) As PROCESSOS DE GERENCIAMENTO DE PROJETOS, representam métodos, procedimentos, ferramentas, técnicas, artefatos – específicos por cada área de conhecimento e, a serem aplicados no projeto, em acordo com a necessidade e cultura organizacional. O detalhamento destas práticas serão apresentadas no próximo módulo. Visão consolidada da Ferramenta – Modelo de Grupo de Processos A seguir, observe a figura que mostra a relação entre grupos de processos, áreas de conhecimento e processos de gerenciamento de projetos: Figura 14 – Visão consolidada Modelo Grupo de Processo – guia PMBOK®. 37 Ciclo de vida iterativo Escopo do projeto geralmente é determinado no início do ciclo de vida do projeto, mas as estimativas de prazo e custos são normalmente modificadas à medida que a equipe do projeto compreende melhor o produto Como exemplo, projetos com ESCOPO em médio nível de compreensão, como por exemplo um projeto de mapeamento de processos em que uma fase inicial de entrevistas pode revelar novas necessidades. Fonte: PMBOK – 7ª edição. Página 37 FIGURA 2-8 Ciclo de vida incremental A entrega é produzida por meio de uma série de iterações que sucessivamente adicionam funcionalidade em prazo determinado. Como exemplo, projetos com ESCOPO em médio / baixo nível de compreensão, como por exemplo a criação de um APP (aplicativo para celular) para suporte a um determinado segmento de negócio, 38 Fonte: PMBOK – 7ª edição. Página 44 FIGURA 2-10 Ciclo de vida adaptativo São ágeis, iterativos ou incrementais. O escopo detalhado é definido e aprovado antes do início de uma iteração. Como exemplo, projetos de desenvolvimento de software, usando abordagens ágeis. Fonte: PMBOK – 7ª edição. Página 45 FIGURA 2-11 Planejamento ágil de projetos Para exemplificar um modelo adaptativo, 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. 39 Figura 26 – Método SCRUM (exemplo) Fonte: Autor. 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 (iteração), 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 stand-up 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”. Trata- se de uma aplicação prática que traz ganhos e agilidade nos processos de gestão. 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. Observe que as atividades propostas pelo método tratam de planejamento, execução e controle em uma visão simplificada, integrada e ágil. Ciclo de vida híbrido É uma combinação de um ciclo de vida adaptativo e um preditivo (observe as características de cada tipo destes ciclos de vida nos itens acima). Como exemplo, projetos que usar o modelo adaptativo em parte do escopo e o modelo adaptativo em outra parte do escopo, ou seja, um ciclo na parte em que o escopo está bem compreendido e outro ciclo na parte em que o escopo se encontra incerto. ATENÇÃO: Compreender e definir o (s) tipo (s) de ciclo de vida, de acordo com a natureza e tipo de projeto, representa a escolha de um caminho até o resultado desejado! Cada tipo de ciclo de vida tem uma forma diferente de interação e aplicação dos processos, práticas, artefatos, ferramentas & técnicas que estudaremos a seguir. 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 e artefatos que organizam e apresentam dados e informações em um formato visual, como tabelas, gráficos, matrizes e diagramas. São artefatos que podem ajudar na tomada de decisões e na priorização. É 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 42 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; documentação técnica (por exemplo: em um projeto de obra ou desenvolvimento de um sistema de informação, podem ser utilizadosmanuais técnicos relacionados ao escopo do projeto); 43 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 inter-relacionadas 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 chama-se pacote de trabalho. 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ém-se somente com um único nível. 44 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 8/80h, é recomendada pelo PMBOK®. No entanto, pode ser adaptada para 8/120h ou 8/200h, ou seja, de acordo com a sua necessidade; se o menor nível, por exemplo, estiver usando a regra 8/80h 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 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). 45 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 escopo-macro 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) 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). 46 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 3.000 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 1.1 FASE 1 1.1.1 ENTREGA 1 1.1.1.1 PACOTE DE TRABALHO 1.1.1 ATIVIDADE 01 1.1.2 ATIVIDADE 02 1.1.3 ATIVIDADE 03 1.1.4 ATIVIDADE 04 1.1.5 ATIVIDADE 05 1.1.6 ATIVIDADE 06 (…) 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$ 900,00. 47 ATIVIDADE 02: realizar validação da fundação da obra. RECURSOS – ATIVIDADE 02: tempo: 01 dia; recursos: 01 engenheiro e custo: R$ 1.200,00. ATIVIDADE 03: submeter documento final para aprovação do cliente. RECURSOS – ATIVIDADE 03: tempo: 04 horas; recursos: 01 gerente de área e custo: R$ 1.500,00 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. 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 18 – Sequenciamento de atividades 48 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 simplespara 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: Passo 1 – determinar o custo dos componentes menores Figura 19 – 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. 49 Figura 20 – Elaboração orçamento 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$ 1.000.000,00 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$ 1.000.000,00 mês 1 mês 2 mês 3 mês 4 mês 5 R$ 200.000 R$ 250.000 R$ 150.000 R$ 200.00 R$ 200.00 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. 50 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 check-list, 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. 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 21 – Fluxo de qualidade do projeto 51 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. Matriz da comunicação e análise de partes interessadas (stakeholders) 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 22 – 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. 52 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. É importante ressaltar que, comunicação em excesso prejudica da mesma forma que pouca informação. Tabela 7 – Exemplo de matriz de comunicação periodicidade ou evento 53 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, deve-se 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 23 – Mapa de recursos 54 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. 55 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 24 – 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. 56 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 8 – 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 9 – 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 57 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 10 – 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) alto/médio/baixo 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) entrega(s) 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: carta-convite; memorando de entendimento; RFP – Request For Proposal e edital técnico. 58 Deve-se 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: Fase 2 – Projeto cotação/10 dias; contratação/15 dias; aquisição/5 dias e desenvolvimento produto final contratado/30 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 do(s) terceiro(s) à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. 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, inicia-se 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, com por exemplo, avaliar o PLANEJADO x REALIZADO, além de propor mudanças para os desvios identificados. Lembre-se de que o plano de projeto é o ponto de partida e ele será versionado diversas vezes até o final do projeto. É importante o entendimento dos ciclos de vida do projeto, pois serão opções diferentes para chegar ao resultado. 59 Práticas de gerenciamento de projetos – Ciclo Adaptativo Serão apresentados alguns exemplos de adaptação e aplicação de práticas de gerenciamento de projetos relevantes para a visão do ciclo adaptativo. É importante ressaltar que não se trata de uma metodologia, e sim de alguns exemplos práticos. Visão de Produto Em uma abordagem adaptativa, partimos de uma visão orientada ao Produto do Projeto. A decomposição de pequenos produtos visa o estabelecimento de algo claro e de falou mensurável para o cliente, a ser implementado em ciclos curtos de execução, conhecimento com iterações ou sprints. Iterações ou Sprint São ciclos que suportam o planejamento, execução e entrega ágil. Estes ciclos têm duração, por exemplo, de 7 ou 15 dias de trabalho. 60 Quadro de Atividades Quadro que ilustra a visão do trabalho a ser feito pelo time ágil de projeto. 61 Quadro que ilustra a visão do trabalho a ser feito na sprint (iteração) pelo time ágil de projeto. O processo de detalhamento de atividades é suportado por um artefato chamado história de usuários, ou seja, é o cliente final descrevendo informações, como REQUISITOS, que deverão ser cumpridas na entrega do time. 62 Papéis & Responsabilidades Em uma abordagem adaptativa, partimos de uma visão orientada ao Produto do Projeto. Temos 3 (três) papéis definidos para o SCRUM. Product Owner (PO) – Proprietário do Produto Scrum Master – Facilitador da aplicação da abordagem Time – Equipe de desenvolvimento. Gestão de Mudanças As iterações, os papéis e responsabilidade a organização da visão de produto, entregas tem como objetivo suportar a gestão de mudança, buscando a aprovação e priorização pelo PO antes do início de uma iteração. A Fundação Getúlio Vargas possui em seu catálogo, cursos especializados em Métodos Ágeis, objetivo
Compartilhar