gerencia_de_projetos

Prévia do material em texto

<p>Gerência de Projetos</p><p>JANE TAVARES ALVAREZ DA SILVA</p><p>1ª Edição</p><p>Brasília/DF - 2023</p><p>23-153418 CDD-658.404</p><p>Dados Internacionais de Catalogação na Publicação (CIP)</p><p>(Câmara Brasileira do Livro, SP, Brasil)</p><p>Silva, Jane Tavares Alvarez</p><p>Gerência de projetos [livro eletrônico] / Jane</p><p>Tavares Alvarez Silva. -- 1. ed. -- Brasília, DF :</p><p>Unyleya, 2023.</p><p>PDF</p><p>Bibliografia.</p><p>ISBN 978-65-85643-04-7</p><p>1. Projetos - Avaliação 2. Projetos -</p><p>Desenvolvimento 3. Projetos - Metodologia I. Título.</p><p>Índices para catálogo sistemático:</p><p>1. Projetos : Administração 658.404</p><p>Eliane de Freitas Leite - Bibliotecária - CRB 8/8415</p><p>Autores</p><p>Jane Tavares Alvarez da Silva</p><p>Produção</p><p>Equipe Técnica de Avaliação, Revisão Linguística e</p><p>Editoração</p><p>Sumário</p><p>Organização do Livro Didático........................................................................................................................................4</p><p>Introdução ..............................................................................................................................................................................6</p><p>Capítulo 1</p><p>Visão Geral sobre Gerência de Projetos .................................................................................................................9</p><p>Capítulo 2</p><p>O Início do Projeto ..................................................................................................................................................... 22</p><p>Capítulo 3</p><p>O Planejamento do Projeto ..................................................................................................................................... 31</p><p>Capítulo 4</p><p>A Execução do Projeto .............................................................................................................................................. 62</p><p>Capítulo 5</p><p>O Controle do Projeto ............................................................................................................................................... 68</p><p>Capítulo 6</p><p>O Encerramento do Projeto ..................................................................................................................................... 80</p><p>Referências .......................................................................................................................................................................... 84</p><p>4</p><p>Organização do Livro Didático</p><p>Para facilitar seu estudo, os conteúdos são organizados em capítulos, de forma didática, objetiva e</p><p>coerente. Eles serão abordados por meio de textos básicos, com questões para reflexão, entre outros</p><p>recursos editoriais que visam tornar sua leitura mais agradável. Ao final, serão indicadas, também,</p><p>fontes de consulta para aprofundar seus estudos com leituras e pesquisas complementares.</p><p>A seguir, apresentamos uma breve descrição dos ícones utilizados na organização do Livro Didático.</p><p>Atenção</p><p>Chamadas para alertar detalhes/tópicos importantes que contribuam para a</p><p>síntese/conclusão do assunto abordado.</p><p>Cuidado</p><p>Importante para diferenciar ideias e/ou conceitos, assim como ressaltar para o</p><p>aluno noções que usualmente são objeto de dúvida ou entendimento equivocado.</p><p>Importante</p><p>Indicado para ressaltar trechos importantes do texto.</p><p>Observe a Lei</p><p>Conjunto de normas que dispõem sobre determinada matéria, ou seja, ela é origem,</p><p>a fonte primária sobre um determinado assunto.</p><p>Para refletir</p><p>Questões inseridas no decorrer do estudo a fim de que o aluno faça uma pausa</p><p>e reflita sobre o conteúdo estudado ou temas que o ajudem em seu raciocínio.</p><p>É importante que ele verifique seus conhecimentos, suas experiências e seus</p><p>sentimentos. As reflexões são o ponto de partida para a construção de suas</p><p>conclusões.</p><p>5</p><p>ORGAnIzAçãO DO LIVRO DIDátICO</p><p>Provocação</p><p>Textos que buscam instigar o aluno a refletir sobre determinado assunto antes</p><p>mesmo de iniciar sua leitura ou após algum trecho pertinente para o autor</p><p>conteudista.</p><p>Saiba mais</p><p>Informações complementares para elucidar a construção das sínteses/conclusões</p><p>sobre o assunto abordado.</p><p>Gotas de Conhecimento</p><p>Partes pequenas de informações, concisas e claras. Na literatura há outras</p><p>terminologias para esse termo, como: microlearning, pílulas de conhecimento,</p><p>cápsulas de conhecimento etc.</p><p>Sintetizando</p><p>Trecho que busca resumir informações relevantes do conteúdo, facilitando o</p><p>entendimento pelo aluno sobre trechos mais complexos.</p><p>Sugestão de estudo complementar</p><p>Sugestões de leituras adicionais, filmes e sites para aprofundamento do estudo,</p><p>discussões em fóruns ou encontros presenciais quando for o caso.</p><p>Posicionamento do autor</p><p>Importante para diferenciar ideias e/ou conceitos, assim como ressaltar para o</p><p>aluno noções que usualmente são objeto de dúvida ou entendimento equivocado.</p><p>6</p><p>Introdução</p><p>Este Livro Didático fornece uma diretriz sólida para o estudo de vários tópicos relacionados</p><p>à gerência ou gerenciamento de projetos, incluindo conceitos importantes, tais como</p><p>ciclo de vida de um projeto, o perfil do gerente de projeto, entre outros.</p><p>Ao longo dos seus seis capítulos, este Livro Didático tenta motivar o estudo da disciplina</p><p>Gerência de Projetos, apresentando vários conceitos, exemplos, além de métodos e</p><p>técnicas para o planejamento, implementação e controle das atividades para a construção</p><p>de um projeto de sucesso.</p><p>O primeiro capítulo trata de conceitos básicos e os demais capítulos abordam o estudo dos</p><p>processos relativos ao início, planejamento, à execução, ao controle e ao encerramento</p><p>do projeto, lidando com questões relativas ao escopo, prazo e custo, entre outros.</p><p>A grande referência para este Livro Didático é o Guia PMBOK, que contém o padrão</p><p>mundialmente reconhecido para a profissão de gerente de projetos.</p><p>Provocação</p><p>Por que gerenciar projetos?</p><p>Figura 1. Como usar a porta?</p><p>Fonte: https://www.edificaconsultoria.com.br/post/2017/11/06/os-3-erros-mais-comuns-que-geram-transtornos-em-</p><p>obras.</p><p>7</p><p>Figura 2. Como chegar ao andar superior?</p><p>Fonte: https://www.2quartos.com/erros-construcao-civil-fotos-inacreditaveis/.</p><p>De acordo com as figuras acima, é possível perceber que, sem um verdadeiro gerenciamento</p><p>que preze pelas questões que serão estudadas neste Livro Didático, os projetos tendem</p><p>ao fracasso.</p><p>Objetivos</p><p>Os objetivos deste Livro Didático são:</p><p>» Apresentar os principais conceitos de Gerência de Projetos.</p><p>» Ensinar os processos de iniciação de um projeto.</p><p>» Ensinar os processos relacionados ao planejamento de um projeto.</p><p>» Ensinar os processos voltados para a execução de um projeto.</p><p>» Ensinar os processos de controle de projeto.</p><p>» Ensinar os processos relacionados ao encerramento de um projeto.</p><p>8</p><p>9</p><p>Introdução</p><p>Neste primeiro capítulo serão estudados alguns dos principais conceitos de Gerência</p><p>de Projetos, a sua importância para a estratégia das empresas, quais os fatores para</p><p>se obter um projeto de sucesso, a importância e o papel de um Gerente de Projeto, as</p><p>estruturas organizacionais, entre outros.</p><p>Objetivos</p><p>» Compreender os principais conceitos de Gerência de Projetos.</p><p>» Refletir sobre a aplicação prática dos conceitos nas organizações.</p><p>1. 1 A estratégia da organização e os projetos</p><p>Basicamente, a estratégia de uma organização define uma visão de alto nível dos</p><p>objetivos a serem alcançados em médio e longo prazos. Entretanto, uma organização</p><p>não existe de forma isolada e está situada em um contexto no qual coexistem clientes,</p><p>fornecedores, concorrentes, entidades governamentais e parceiros etc. Nesse contexto,</p><p>surgem, a todo instante, oportunidades e ameaças que podem facilitar ou dificultar</p><p>o alcance dos objetivos estratégicos previamente estabelecidos.</p><p>A fim de explorar as oportunidades, prevenir a ocorrência das ameaças e atender às</p><p>necessidades, a organização deverá tomar um conjunto de ações, e algumas dessas</p><p>ações serão efetivamente realizadas por meio de projetos, com o objetivo de atingir</p><p>os resultados esperados. Dessa forma, as organizações se valem de projetos tanto</p><p>a ser realizado. Exemplo:</p><p>› Um projeto de reforma do layout de um site pode ter seu custo estimado multiplicando-</p><p>se o custo de reforma de uma página HTML pelo número de páginas HTML do site.</p><p>» Também é possível classificar as atividades a serem executadas e estabelecer um custo</p><p>associado a elas. Exemplo:</p><p>› Reforma de página simples: R$ 50,00</p><p>› Reforma de página média: R$ 100,00</p><p>› Reforma de página complexa: R$ 200,00</p><p>› tratamento de foto: R$ 50,00</p><p>Fonte: Elaborado pela autora.</p><p>52</p><p>CAPÍTULO 3 • O PLAnEJAMEntO DO PROJEtO</p><p>A técnica de estimativa Bottom-up é muito utilizada porque ela pode ser realizada</p><p>diretamente a partir do cronograma. Por exemplo: se uma tarefa de 16 horas é realizada</p><p>por um profissional que custa para a empresa R$ 120,00/hora com todos os encargos</p><p>trabalhistas, logo o custo da tarefa será de 16 x 120,00 = R$ 1920,00. O custo do projeto,</p><p>nesse caso, será o somatório dos custos de todas as atividades. Contudo, é importante</p><p>frisar que o orçamento do projeto engloba não só a mão de obra dos profissionais</p><p>envolvidos. Devem ser levados em consideração o custo dos equipamentos usados</p><p>pelos profissionais, o custo da infraestrutura usada pela equipe do projeto (aluguel das</p><p>salas, valor do condomínio, valor da energia elétrica, manutenção da infraestrutura</p><p>etc.), custo do material consumido pela equipe do projeto (papel, tinta para impressora</p><p>etc.), viagens e diárias de hotel, entre muitos outros. A junção de todos esses custos</p><p>é que compõe o orçamento do projeto.</p><p>Importante</p><p>Documentação da Estimativa de Custo:</p><p>» Junto com as estimativas de custo propriamente ditas, é muito importante documentar os detalhes adicionais que foram</p><p>usados como apoio à estimativa.</p><p>» Esse documento é de extrema importância para demonstrar a preocupação com a exatidão das estimativas e é um forte</p><p>argumento para mostrar a qualidade com que foi executado esse processo.</p><p>» Essa documentação deve incluir:</p><p>› Qual o procedimento adotado para elaboração da estimativa;</p><p>› Quais técnicas foram usadas;</p><p>› Qual a origem dos dados usados como base para elaboração da estimativa;</p><p>› Premissas assumidas;</p><p>› Restrições;</p><p>› Indicação do intervalo de variação da estimativa. Por exemplo: o custo real poder ser de -10% a +15% da estimativa de</p><p>custo.</p><p>A partir da definição do orçamento, é preciso definir o cronograma de desembolso.</p><p>O cronograma de desembolso é o cronograma de pagamentos do projeto, ou seja, é o</p><p>cronograma que define como o cliente vai pagar pelo projeto, ou seja, é ele que define</p><p>em quantas parcelas o projeto será pago, em que momento esse pagamento será feito</p><p>e qual será o valor de cada parcela.</p><p>Para gerar o cronograma de desembolso é possível adotar, basicamente, duas estratégias:</p><p>» Pagamento em parcelas periódicas: as parcelas são calculadas seguindo algum</p><p>intervalo de tempo (pagamento mensal, trimestral, quadrimestral etc.).</p><p>53</p><p>O PLAnEJAMEntO DO PROJEtO • CAPÍTULO 3</p><p>» Pagamento contraentrega: as parcelas são pagas conforme algum subproduto</p><p>do projeto vai sendo entregue.</p><p>Obviamente, o cronograma de desembolso deverá ser negociado com o cliente, pois</p><p>sempre existe a tendência de o fornecedor do projeto tentar receber o quanto antes</p><p>(receber o mais cedo possível) e do cliente de pagar somente depois do projeto</p><p>terminado (pagar o mais tarde possível).</p><p>Atenção</p><p>Pontos de atenção na elaboração do Plano de Gerenciamento do Custo:</p><p>» Não minta para você mesmo. Não minta para os outros.</p><p>» Resista à tentação de planejar os custos do projeto com base na verba disponível. Você vai conseguir, mas lembre-se de que</p><p>o papel é o melhor amigo do gerente, ele aceita tudo.</p><p>» Aprenda com o passado da empresa. Analise os dados de custo de projetos anteriores.</p><p>» Crie e invista para manter uma base de conhecimento de custos dos projetos da empresa.</p><p>» Atenção para os riscos do projeto: desenvolva e estime custos das ações gerenciais para lidar com os riscos. Se alguém da</p><p>equipe disser que isso é burocracia, mande-o fazer um treinamento.</p><p>» Não planeje os custos se os outros planos (especialmente os de prazo e escopo) não estiverem bem definidos. E lembre-se</p><p>do primeiro item.</p><p>3.4 Plano de gerenciamento da qualidade</p><p>O plano de gerenciamento da qualidade busca definir critérios objetivos para avaliar se</p><p>as entregas do projeto possuem a qualidade planejada. Do ponto de vista do produto,</p><p>qualidade pode ser traduzida como a adequação das entregas ao propósito para o qual</p><p>elas foram projetadas. Assim, pode-se notar que um projeto que entrega um produto</p><p>que não atende aos requisitos de qualidade não foi bem-sucedido, por mais que as</p><p>demais variáveis, como tempo e custo, tenham sido bem avaliadas.</p><p>Na moderna gestão de qualidade existem fatores essenciais que devem ser levados</p><p>em consideração:</p><p>» Satisfação do cliente: entender e gerenciar as expectativas dos clientes, de forma</p><p>a atender às suas necessidades.</p><p>» Prevenção: a prevenção deve ser sempre preferida ao invés da correção. Estudos</p><p>mostram que os custos de prevenção são muito inferiores aos custos de correção.</p><p>54</p><p>CAPÍTULO 3 • O PLAnEJAMEntO DO PROJEtO</p><p>» Responsabilidade da gerência: qualidade deve ser uma preocupação de todos,</p><p>mas a gerência deve estar comprometida em torná-la uma realidade.</p><p>» Melhoria contínua: o ciclo PDCA, já visto anteriormente no Capítulo 1, é a base</p><p>da melhoria da qualidade.</p><p>No contexto do gerenciamento de projetos existem alguns termos que são importantes</p><p>de serem compreendidos para que se possa entender como a qualidade é planejada</p><p>e monitorada:</p><p>» Garantia da qualidade: está relacionada ao processo usado para atingir os critérios</p><p>de qualidade e em passar confiança aos stakeholders de que esses critérios serão</p><p>atingidos. A garantia de qualidade responde à pergunta: O que será feito para</p><p>que a qualidade desejada seja obtida?</p><p>» Controle da qualidade: está relacionado às técnicas empregadas para avaliar</p><p>se os produtos possuem a qualidade planejada. Também está relacionado ao</p><p>entendimento das causas das ocorrências das não conformidades e definição</p><p>de ações para eliminá-las. O controle de qualidade responde à pergunta: Como</p><p>o produto será avaliado para verificar se ele atende à qualidade desejada?</p><p>» Critérios de qualidade: são definições relacionadas aos limites que serão aceitos</p><p>para determinada característica do produto ou serviço. Por exemplo: o cadastro</p><p>de clientes só será liberado para uso do cliente quando a execução dos testes</p><p>funcionais reportar no máximo três falhas simples.</p><p>A partir dessas definições, é possível entender os três pilares do gerenciamento da</p><p>avaliação da qualidade em um projeto:</p><p>Figura 36. Pilares da avaliação da qualidade em um projeto.</p><p>Fonte: Elaborado pela autora.</p><p>55</p><p>O PLAnEJAMEntO DO PROJEtO • CAPÍTULO 3</p><p>Assim, o planejamento da qualidade é responsável pela identificação dos padrões</p><p>de qualidade para o projeto e pela definição e documentação de como satisfazê-los.</p><p>Também é responsável por definir os critérios ou indicadores usados na avaliação da</p><p>qualidade do produto ou do serviço. O controle da qualidade e a garantia da qualidade</p><p>serão vistos nos capítulos posteriores.</p><p>De forma resumida, é possível afirmar que planejar a qualidade é importante para que</p><p>se defina uma abordagem para executar a avaliação dos produtos ou serviços criados</p><p>no projeto. Assim, o plano de gerenciamento da qualidade pode e deve ser detalhado</p><p>juntamente com o detalhamento do produto ou serviço a ser avaliado. Exemplos:</p><p>» Se o projeto prevê uma atividade de treinamento dos usuários, ao final do</p><p>treinamento é possível aplicar um questionário de satisfação para avaliar se o</p><p>treinamento foi proveitoso, adequado etc.</p><p>» Se o designer vai realizar atividades para criação de um protótipo da interface</p><p>do sistema, podem ser introduzidas atividades de qualidade com o objetivo de</p><p>avaliar o design proposto.</p><p>Por fim, vale a pena ressaltar que todo critério de qualidade possui um custo, ou seja,</p><p>ao se definir um critério de qualidade,</p><p>é importante avaliar o quanto custa atingir esse</p><p>critério. Por exemplo, se um cliente demanda que seja fabricado um pneu de carro que</p><p>não fure nunca, provavelmente será muito caro criar esse pneu, e depois avaliar se</p><p>ele realmente atinge esse critério de qualidade. Por isso, é sempre importante avaliar</p><p>o custo/benefício dos critérios de qualidade, a fim de definir se vale a pena ou não</p><p>atendê-lo. Nessa análise, algumas alternativas podem ser identificadas. No exemplo</p><p>dado anteriormente do pneu, uma alternativa seria criar um pneu que, ao furar, seja</p><p>capaz de rodar 100km sem afetar a segurança.</p><p>Importante</p><p>Fazem parte do plano de gerenciamento da qualidade:</p><p>» Plano de revisão/inspeção das entregas.</p><p>» Plano de testes do produto.</p><p>» Plano de homologação ou aceitação do produto pelo cliente.</p><p>» Plano de garantia do produto após a entrega.</p><p>» Definição de quem ou que grupos serão responsáveis pelo planejamento e execução das atividades de qualidade.</p><p>» Definição de quais ferramentas serão usadas nas atividades de qualidade.</p><p>» Definição de quais resultados devem ser gerados por cada atividade do processo de qualidade.</p><p>Ou seja, tudo que envolve a demonstração de que o produto ou serviço tem a qualidade planejada.</p><p>56</p><p>CAPÍTULO 3 • O PLAnEJAMEntO DO PROJEtO</p><p>3.5 Plano de gerenciamento de riscos</p><p>Figura 37. figura de humor – Como gerenciar esse risco?</p><p>Fonte: http://www.muitohumor.com.br/titanic-x-tubaroes/#axzz6tGwA1LnX.</p><p>O gerenciamento de riscos é responsável por identificar e avaliar os riscos, elaborar</p><p>planos de ação e assegurar que esses planos vão ser executados caso os riscos se</p><p>materializem. Entretanto, antes de discutir o plano de gerenciamento de riscos é</p><p>preciso responder a algumas perguntas: O que é um risco? Qual a sua natureza? Risco</p><p>é sempre algo ruim?</p><p>» Um risco é uma circunstância ou evento que pode afetar positiva ou negativamente</p><p>o projeto sob diversas perspectivas, tais como tempo, custo, escopo e qualidade.</p><p>» Riscos que afetam positivamente são chamados de oportunidades e riscos que</p><p>afetam negativamente são chamados de ameaças.</p><p>» Riscos podem ter uma ou mais causas e impactos (consequências).</p><p>» Riscos podem ser de diferentes naturezas, como tecnológicos, organizacionais,</p><p>projeto, estimativa, negócio, gerencial, recursos, entre outros.</p><p>Sobre os riscos, existem algumas frases célebres. Vale a pena lembrá-las:</p><p>“Se alguma coisa pode dar errado, vai dar errado.” (Murphy)</p><p>“Se você não atacar os riscos de forma sistemática, eles irão atacá-lo”</p><p>(TOM GILB).</p><p>57</p><p>O PLAnEJAMEntO DO PROJEtO • CAPÍTULO 3</p><p>tabela 11. Exemplos de riscos.</p><p>Risco Tipo Descrição</p><p>Desconhecimento do</p><p>framework tecnológico Não há conhecimento técnico na equipe para trabalhar com</p><p>o framework exigido pelo cliente.</p><p>Desempenho do BD tecnológico O BD exigido pelo cliente pode não ser adequado frente</p><p>aos requisitos de desempenho estabelecidos.</p><p>Atraso na disponibilização</p><p>do servidor Recurso O servidor especificado pode ser entregue pelo fornecedor</p><p>com atraso.</p><p>Atraso na especificação Requisito</p><p>Os stakeholders identificados estão envolvidos em outro</p><p>projeto e podem não ter tempo disponível para a elicitação</p><p>de requisitos conforme definido no cronograma.</p><p>tamanho subestimado Projeto</p><p>Os profissionais usados na estimativa de tempo não</p><p>possuem a experiência necessária para uma estimativa</p><p>precisa de acordo com a tecnologia adotada.</p><p>Prejuízo financeiro negócio A implantação do software poderá ocorrer após a data-</p><p>limite e gerar uma multa para a empresa.</p><p>Saída do gerente técnico Recursos</p><p>humanos</p><p>O responsável técnico pelo projeto está insatisfeito e pode</p><p>deixar a empresa durante o projeto.</p><p>Falta de recurso</p><p>especializado</p><p>Recursos</p><p>humanos</p><p>Não encontrar no mercado um profissional com as</p><p>habilidades requeridas pelo custo que foi orçado.</p><p>Fonte: Elaborado pela autora.</p><p>Para realizar o gerenciamento dos riscos, alguns membros da equipe do projeto e</p><p>stakeholders são destacados para formar a equipe de gerenciamento de riscos. Essa</p><p>equipe é responsável por criar o plano de gerenciamento de riscos, que define como</p><p>os riscos serão identificados, priorizados e gerenciados ao longo do projeto. O plano</p><p>de gerenciamento de riscos normalmente contém:</p><p>» Metodologia: define as abordagens, ferramentas e fontes de dados que podem</p><p>ser usadas para realizar o gerenciamento dos riscos do projeto. Exemplos:</p><p>› Serão realizadas reuniões de brainstorm para identificação dos riscos.</p><p>› Além da equipe fixa de gerenciamento de riscos, também participarão dessas</p><p>reuniões especialistas em áreas específicas, conforme o risco identificado.</p><p>› Serão convidados para as reuniões de brainstorm: gerentes de outros projetos da</p><p>mesma área, que poderão contribuir com lições aprendidas.</p><p>» Papéis e Responsabilidades: define o líder e os membros da equipe de</p><p>gerenciamento dos riscos e descreve suas responsabilidades.</p><p>» Prazos: define com que frequência serão realizados os procedimentos de</p><p>gerenciamento de riscos. Exemplo:</p><p>› Serão realizadas reuniões quinzenais para revisão da tabela de ameaças e</p><p>oportunidades ou a qualquer momento em que uma ameaça ficar eminente.</p><p>58</p><p>CAPÍTULO 3 • O PLAnEJAMEntO DO PROJEtO</p><p>» Definição de Probabilidade e Impacto dos Riscos: tabela ou matriz com os</p><p>impactos específicos relacionados ao projeto, de acordo com a probabilidade</p><p>de ocorrência do risco (será discutido adiante).</p><p>» Tabela de Ameaças e Oportunidades: descreve os riscos e sua priorização de</p><p>acordo com o impacto de cada risco nos objetivos do projeto. Também é definida</p><p>a probabilidade de ocorrência do risco, seu impacto no projeto e o plano de</p><p>respostas.</p><p>Entre os procedimentos que fazem parte do gerenciamento de riscos, três se destacam:</p><p>» Identificação dos riscos.</p><p>» Análise e priorização dos riscos.</p><p>» Planejamento das respostas aos riscos.</p><p>3.5.1 Identificação dos riscos</p><p>A identificação dos riscos é uma das tarefas mais importantes do gerenciamento de</p><p>riscos e deve ser realizada com certa frequência, uma vez que novos riscos podem</p><p>surgir conforme o projeto se desenvolve. Várias técnicas podem ser empregadas para</p><p>identificação dos riscos:</p><p>» Revisão da documentação do projeto (a análise da documentação do projeto</p><p>pode revelar situações de risco).</p><p>» Técnica Delphi (a mesma usada para estimativa de prazo, mas, nesse caso, busca</p><p>alcançar um consenso entre especialistas sobre os riscos de um projeto).</p><p>» Brainstorming.</p><p>» Entrevistas com participantes experientes do projeto, stakeholders e especialistas</p><p>em riscos.</p><p>» Diagramas de causa e efeito (também chamado de “diagrama de Ishikawa”).</p><p>» Análise das premissas do projeto.</p><p>» Análise das restrições do projeto.</p><p>59</p><p>O PLAnEJAMEntO DO PROJEtO • CAPÍTULO 3</p><p>3.5.2 Análise e priorização dos riscos</p><p>Uma vez identificado, cada risco é analisado para definir dois aspectos:</p><p>» Probabilidade de ocorrência: é a “chance” de o risco ocorrer. Existem diversas</p><p>maneiras de definir essa probabilidade, mas normalmente ela é definida a partir</p><p>de uma escala ordinal. Exemplo:</p><p>› Muito alta: quase certa de ocorrer em algum momento.</p><p>› Alta: provavelmente vai ocorrer em algum momento.</p><p>› Média: possível de ocorrer em algum momento.</p><p>› Baixa: improvável de ocorrer em algum momento.</p><p>› Muito baixa: raramente vai ocorrer, somente em circunstâncias excepcionais.</p><p>» Impacto: é o “quanto” o risco pode afetar o projeto se ocorrer. Geralmente, o</p><p>impacto também é definido a partir de uma escala ordinal e o foco é entender o</p><p>quanto o risco afeta o tempo, custo, escopo e qualidade dos produtos ou serviços.</p><p>› Muito elevado: pode acarretar o cancelamento do projeto, devido ao prazo ou custo</p><p>inaceitáveis, ou tornar seus produtos ou serviços inúteis.</p><p>› Elevado: pode trazer perdas significativas para o projeto (grande atraso na entrega,</p><p>aumento significativo no custo, qualidade muito baixa, escopo muito aquém da</p><p>necessidade do cliente).</p><p>› Moderado: pode acarretar perdas no tempo, custo, escopo ou qualidade que o cliente</p><p>deve estar ciente e aprovar.</p><p>› Reduzido: impacto parcial e aceitável no tempo, custo, escopo ou qualidade.</p><p>› Muito reduzido: impacto imperceptível no tempo, custo, escopo ou qualidade.</p><p>Após a definição da probabilidade de ocorrência e impacto, cada risco é priorizado,</p><p>ou seja, é definida uma ordem de importância para cada risco. Uma das formas de</p><p>priorizar os riscos é avaliá-los de acordo com uma matriz de probabilidade e impacto</p><p>ou matriz de vulnerabilidades.</p><p>A figura 38 apresenta um exemplo desse tipo de matriz para riscos que são ameaças</p><p>ao projeto, e as cores devem ser interpretadas da seguinte forma:</p><p>» Vermelho: riscos de alta prioridade, pois eles muito provavelmente ocorrerão e</p><p>seus impactos negativos no projeto são significativos.</p><p>60</p><p>CAPÍTULO 3 • O PLAnEJAMEntO DO PROJEtO</p><p>» Amarelo: riscos de média prioridade, pois eles podem ou não ocorrer e seus</p><p>impactos negativos são aceitáveis ou gerenciáveis.</p><p>» Verde: riscos de baixa prioridade, pois eles raramente ocorrerão, e caso ocorram,</p><p>seus impactos negativos no projeto não são significativos.</p><p>Figura 38. Exemplo de matriz de probabilidade e impacto para priorização de riscos (ameaças).</p><p>Fonte: Elaborado pela autora.</p><p>3.5.3 Planejamento das respostas aos riscos</p><p>A partir da prioridade de cada risco, deve ser criado um plano de respostas aos riscos,</p><p>ou seja, um plano que descreve as ações a serem tomadas para tratar cada risco. As</p><p>ações a serem tomadas dependem de cada risco, mas, em linhas gerais, um plano de</p><p>respostas contempla ações que adotam estratégias distintas, dependendo se o risco</p><p>é uma ameaça ou uma oportunidade.</p><p>A tabela a seguir apresenta algumas estratégias normalmente adotadas quando os</p><p>riscos são uma ameaça ao projeto. Note que os riscos de mais alta prioridade (alta</p><p>probabilidade de ocorrer e alto impacto no projeto) requerem ações que busquem</p><p>eliminar a probabilidade de ocorrência ou os impactos negativos. Por outro lado,</p><p>riscos de baixa prioridade (baixa probabilidade de ocorrer e baixo impacto no projeto)</p><p>são apenas monitorados, não necessitando de nenhuma ação imediata mais efetiva.</p><p>tabela 12. Estratégias e suas ações.</p><p>Estratégia Ação</p><p>Prevenção Ações que buscam eliminar a probabilidade de ocorrência da ameaça ou a eliminação dos seus</p><p>impactos no projeto.</p><p>transferência Ações que buscam transferir o impacto negativo para terceiros.</p><p>Mitigação Ações que buscam limitar a probabilidade de ocorrência da ameaça ou a diminuição dos seus</p><p>impactos no projeto.</p><p>Aceitação nenhuma ação será tomada e a ameaça será monitorada para avaliar a sua evolução.</p><p>Fonte: Elaborado pela autora.</p><p>61</p><p>O PLAnEJAMEntO DO PROJEtO • CAPÍTULO 3</p><p>Sintetizando</p><p>O que vimos neste Capítulo:</p><p>» O Plano de Gerenciamento do Projeto (PGP) define como o projeto será executado, monitorado, controlado e finalizado,</p><p>e ainda, integra os demais planos do projeto, como, por exemplo, o plano de custos, o plano de qualidade e o plano de</p><p>riscos, entre outros.</p><p>» O plano de gerenciamento do escopo compõe o PGP e descreve como o escopo do projeto será definido, validado e</p><p>controlado.</p><p>» O plano de gerenciamento do escopo é dividido em três partes: coleta dos requisitos, definição do escopo e criação da</p><p>Estrutura Analítica do Projeto (EAP).</p><p>» A coleta dos requisitos está relacionada com definição, detalhamento e documentação das necessidades e expectativas das</p><p>partes interessadas e as características dos produtos/serviços que irão atender a essas necessidades/expectativas.</p><p>» A definição do escopo detalha os limites do projeto.</p><p>» A EAP ou WBS tem como objetivo dividir o projeto em unidades de trabalho menores, menos complexas e, portanto, mais</p><p>gerenciáveis.</p><p>» A validação do escopo é uma verificação formal da viabilidade e adequação da coleta dos requisitos, da criação da</p><p>declaração de escopo e da EAP às necessidades do cliente.</p><p>» O plano de gerenciamento de tempo está relacionado com a definição do tempo necessário para a execução das tarefas.</p><p>» O principal elemento do Plano de Gerenciamento de Tempo é o cronograma do projeto.</p><p>» A criação do cronograma do projeto envolve quatro etapas: definir as atividades do projeto, sequenciar as atividades do</p><p>projeto, estimar os recursos da atividade e estimar a duração da atividade.</p><p>» O plano de gerenciamento de custos trata a questão dos custos para realização do projeto.</p><p>» O plano de gerenciamento da qualidade lida com critérios objetivos para avaliar se as entregas do projeto possuem a</p><p>qualidade desejada.</p><p>» O plano de gerenciamento de riscos define como os riscos serão identificados, priorizados e gerenciados ao longo do</p><p>projeto.</p><p>62</p><p>Introdução</p><p>Neste capítulo, será estudada a fase de execução do projeto, que é composta por</p><p>atividades responsáveis pela execução do que foi planejado anteriormente. Tais</p><p>atividades podem ser agrupadas da seguinte forma:</p><p>» Orientação e gerenciamento do trabalho do projeto.</p><p>» Garantia da qualidade.</p><p>» Gerenciamento da equipe do projeto.</p><p>» Gerenciamento das comunicações do projeto.</p><p>» Gerenciamento dos stakeholders.</p><p>Objetivos</p><p>» Compreender as atividades relativas à fase de execução do projeto.</p><p>» Refletir sobre a garantia da qualidade e o gerenciamento da equipe do projeto,</p><p>das comunicações do projeto e dos stakeholders.</p><p>Figura 39. Orientando, gerenciando e assegurando o desempenho.</p><p>Fonte: https://www.shutterstock.com/pt/image-photo/business-partners-discuss-plan-meetings-goals-1525378448.</p><p>4CAPÍTULO</p><p>A EXECUÇÃO DO PROJETO</p><p>63</p><p>A EXECUÇÃO DO PROJETO • CAPÍTULO 4</p><p>4.1 Orientação e gerenciamento do trabalho do projeto</p><p>Esse grupo engloba as atividades que devem ser executadas pelo gerente de projeto</p><p>e pela equipe do projeto a fim de executar o plano do projeto previamente definido.</p><p>Essas atividades estão relacionadas com:</p><p>» Execução das atividades definidas para o projeto.</p><p>» Implementação dos métodos e padrões planejados.</p><p>» Manutenção da motivação da equipe.</p><p>» Tratamento dos conflitos.</p><p>» Obtenção, gerenciamento e uso dos diversos recursos materiais.</p><p>» Criação e avaliação das entregas do projeto.</p><p>» Gerenciamento dos riscos e implementação das respostas, quando pertinente.</p><p>» Adaptação das alterações aprovadas no escopo e plano do projeto.</p><p>» Seleção de fornecedores.</p><p>» Gerenciamento de terceiros.</p><p>» Solicitação de alterações no escopo, custo, cronograma etc.</p><p>» Coleta de dados e divulgação do progresso do projeto.</p><p>» Coleta e documentação das lições aprendidas.</p><p>4.2 Garantia da qualidade</p><p>Figura 40. Selo de qualidade.</p><p>Fonte: https://www.shutterstock.com/pt/image-photo/red-superior-quality-stamp-wooden-stamper-148369613.</p><p>64</p><p>CAPÍTULO 4 • A EXECUÇÃO DO PROJETO</p><p>As atividades de garantia de qualidade têm como objetivo assegurar que os padrões</p><p>de qualidade, procedimentos e processos estão sendo seguidos conforme planejado.</p><p>Apesar do nome, essas atividades não são as atividades de qualidade propriamente</p><p>ditas, como testes de softwares e inspeção de documentos, entre outros. O principal</p><p>objetivo da garantia de qualidade é demonstrar que as atividades de qualidade que</p><p>constam do plano de qualidade do projeto estão realmente sendo executadas.</p><p>A principal técnica para realizar a garantia da qualidade é a auditoria da qualidade.</p><p>É por meio da auditoria que é possível avaliar se os processos que fazem parte do</p><p>plano de qualidade estão sendo efetivamente executados.</p><p>A auditoria da qualidade é uma revisão estruturada e independente para determinar se</p><p>as atividades do projeto estão cumprindo as políticas, os processos e os procedimentos</p><p>da organização e do projeto. Os objetivos da auditoria da qualidade incluem:</p><p>» Identificar todas as boas práticas sendo implementadas.</p><p>» Identificar todas as não conformidades, lacunas e deficiências.</p><p>» Compartilhar as boas práticas introduzidas ou implementadas em projetos</p><p>similares na organização e/ou no setor.</p><p>» Oferecer apoio proativo de forma positiva para melhorar a implementação de</p><p>processos, a fim de ajudar a equipe a aumentar a produtividade.</p><p>» Contribuir para o repositório de lições aprendidas da organização.</p><p>As auditorias de qualidade podem ser programadas ou aleatórias, e podem ser realizadas</p><p>por auditores internos ou externos.</p><p>4.3 Gerenciamento da equipe do projeto</p><p>Figura 41. Motivando a equipe.</p><p>Fonte: https://www.shutterstock.com/pt/image-photo/multiracial-euphoric-business-team-people-give-1477336895.</p><p>65</p><p>A EXECUÇÃO DO PROJETO • CAPÍTULO 4</p><p>Durante a execução do projeto, as atividades de gerenciamento da equipe envolvem a</p><p>seleção dos recursos humanos, o desenvolvimento da equipe com o aprimoramento das</p><p>competências dos membros da equipe (se necessário), e o gerenciamento do dia a dia</p><p>da equipe do projeto, com resolução de conflitos, avaliação de desempenho e feedbacks.</p><p>Para que a execução das atividades do projeto possa ser efetivamente realizada, é</p><p>preciso garantir que a equipe do projeto esteja pronta para tal. Nesse contexto, o gerente</p><p>do projeto é responsável pela mobilização da equipe, ou seja, ele é responsável por</p><p>contratar, negociar ou requisitar os recursos humanos necessários e adequados para</p><p>o projeto. Caso essa mobilização não seja realizada da forma adequada, é possível ter</p><p>problemas no custo, no prazo, na satisfação do cliente e na qualidade dos produtos e</p><p>serviços, reduzindo as chances de sucesso no projeto. Vale lembrar que, atualmente,</p><p>em muitos projetos, é possível o uso de equipes remotas, ou seja, equipes que estão</p><p>geograficamente distribuídas. Esse mecanismo é bastante interessante, pois aumenta</p><p>a flexibilidade na inclusão de novos recursos e na liberação de recursos existentes.</p><p>No que diz respeito ao desenvolvimento da equipe do projeto, deve-se considerar</p><p>mecanismos que promovam:</p><p>» a melhoria das competências e habilidades técnicas e interpessoais dos membros</p><p>da equipe.</p><p>» a motivação da equipe.</p><p>» a melhoria no ambiente de trabalho.</p><p>» a diminuição da rotatividade de pessoal.</p><p>Nesse contexto, existem várias estratégias que podem ser adotadas como treinamento,</p><p>mentoria, coaching e atividades em grupo para aprimorar as relações interpessoais,</p><p>definição de um código de conduta ou alocação dos membros da equipe em um mesmo</p><p>espaço físico. Independentemente das estratégias adotadas, é importante ressaltar</p><p>que essas ações devem visar sempre ao aperfeiçoamento do desempenho do projeto.</p><p>Por fim, em qualquer projeto é importante que o gerente do projeto possua habilidades</p><p>para identificar, construir, manter, motivar, liderar e inspirar a equipe, a fim de</p><p>atingir os objetivos do projeto. É bom notar que o GP atua em um ambiente em que</p><p>os membros da equipe possuem experiência em setores diversos, caracterizando,</p><p>muitas vezes, uma diversidade cultural. Dessa forma, o gerenciamento do dia a dia</p><p>da equipe do projeto envolve:</p><p>» Acompanhar o desempenho dos membros da equipe.</p><p>» Fornecer feedbacks construtivos.</p><p>» Resolver conflitos.</p><p>66</p><p>CAPÍTULO 4 • A EXECUÇÃO DO PROJETO</p><p>» Esclarecer papéis e responsabilidades de cada um.</p><p>» Gerenciar mudanças para otimizar o desempenho do projeto.</p><p>Saiba mais</p><p>Feedback significa, basicamente, dar retorno. No contexto de gerenciamento de recursos humanos, feedback está associado a</p><p>explicar ou esclarecer para os membros da equipe seus pontos fortes e fracos e como a empresa vê o seu desempenho.</p><p>4.4 Gerenciamento das comunicações do projeto</p><p>Em alguns tipos de projeto é preciso ter especial atenção em “como” e “para quem” as</p><p>informações do projeto são divulgadas. Por exemplo: em um projeto de fusão de dois</p><p>bancos certamente surgirão boatos e rumores sobre demissões em massa, fechamento</p><p>de agências, transferência de setores para outras cidades, entre outros. Nesse caso</p><p>específico, as comunicações do projeto exercem um papel fundamental, pois permitem</p><p>repassar aos diversos stakeholders as informações precisas e adequadas no momento</p><p>correto. Entretanto, o gerenciamento de comunicações não apenas trata da distribuição</p><p>de informações relevantes, mas procura também garantir que as informações repassadas</p><p>para os stakeholders sejam geradas, recebidas e compreendidas de forma apropriada.</p><p>De forma objetiva, o gerenciamento de comunicações é responsável pela criação, coleta,</p><p>distribuição, armazenamento, recuperação, e pela disposição final das informações</p><p>do projeto, de forma a criar um fluxo de comunicação eficiente e com bons resultados</p><p>entre os stakeholders. Contudo, essas ações devem estar alinhadas com o plano de</p><p>gerenciamento de comunicações previamente estabelecido. Geralmente, esse plano é</p><p>definido em função dos diversos stakeholders do projeto, uma vez que cada um deles</p><p>apresenta uma necessidade distinta em termos de acesso às informações do projeto.</p><p>A tabela a seguir apresenta um exemplo de tipos de comunicação de um projeto:</p><p>tabela 13. tipos de comunicação de um projeto.</p><p>De Para Frequência Tipo Responsável</p><p>GP Stakeholder Semanal</p><p>Boletim informal de progresso:</p><p>» Status do progresso (planejado x realizado)</p><p>» Objetivos alcançados e problemas encontrados</p><p>» Ações necessárias</p><p>GP</p><p>GP Comitê diretor Mensal</p><p>Relatório de acompanhamento:</p><p>» Status do progresso (planejado x realizado)</p><p>» Estimativas de custo e prazo revisadas</p><p>GP</p><p>GP Equipe A cada ponto de</p><p>revisão</p><p>Relatório de revisão:</p><p>» Avaliação da qualidade do produto</p><p>» Estatísticas de falhas encontradas</p><p>GP</p><p>Fonte: Elaborado pela autora.</p><p>67</p><p>A EXECUÇÃO DO PROJETO • CAPÍTULO 4</p><p>4.5 Gerenciamento dos stakeholders</p><p>Em outras partes deste material já foi discutida a importância de identificar quem são</p><p>os stakeholders de um projeto e de entender quais as suas expectativas e necessidades.</p><p>Seguindo essa mesma linha de raciocínio, durante a execução do projeto, é preciso</p><p>envolver e engajar os stakeholders de forma efetiva no projeto, trabalhando junto a</p><p>eles, incentivando a sua participação nas atividades do projeto e estabelecendo canais</p><p>adequados de comunicação. Essas ações visam:</p><p>» Engajar os stakeholders nas atividades apropriadas do projeto, de forma a garantir</p><p>seu compromisso ao longo de todo o projeto.</p><p>» Gerenciar as expectativas dos stakeholders, comunicando e negociando, de forma</p><p>a garantir que as metas do projeto sejam atingidas.</p><p>» Esclarecer e solucionar questões que foram identificadas durante o andamento</p><p>do projeto.</p><p>Assim, o gerenciamento dos stakeholders ajuda a aumentar a probabilidade de sucesso</p><p>do projeto, garantindo que as partes interessadas entendam claramente as metas, os</p><p>objetivos, os benefícios e os riscos do projeto. Isso permite que elas apoiem ativamente</p><p>o projeto e ajudem na orientação das atividades e decisões do projeto.</p><p>Sintetizando</p><p>O que vimos neste Capítulo:</p><p>» A orientação e a gerência do trabalho do projeto estão relacionadas a um conjunto de ações (p. ex.: tratar os conflitos,</p><p>manter a equipe motivada etc.), que devem ser executadas pelo gerente de projeto e pela equipe do projeto.</p><p>» A garantia da qualidade durante a execução do projeto é essencial, pois ela demonstra que as atividades de qualidade que</p><p>constam do plano de qualidade do projeto estão realmente sendo executadas.</p><p>» A principal técnica para garantia da qualidade na execução do projeto é a auditoria de qualidade.</p><p>» A equipe do projeto deve ser mobilizada, aprimorada e gerenciada.</p><p>» A mobilização da equipe envolve a seleção dos recursos humanos e sua disponibilização no projeto.</p><p>» O aprimoramento da equipe envolve tanto as melhorias de aspectos técnicos e interpessoais quanto a motivação e</p><p>melhorias do ambiente de trabalho.</p><p>» O gerenciamento da equipe envolve ações no dia a dia associadas à resolução de conflitos, avaliação e feedback.</p><p>» O gerenciamento das comunicações está associado com a distribuição adequada e no momento correto das informações</p><p>do projeto aos stakeholders.</p><p>» O gerenciamento dos stakeholders tenta promover o engajamento efetivo dos stakeholders, tornando-os parte essencial do</p><p>projeto, gerenciando suas expectativas e esclarecendo questões relevantes.</p><p>68</p><p>Introdução</p><p>A fase de controle do projeto, que é estudada</p><p>neste capítulo, é composta de atividades</p><p>responsáveis por monitorar a execução das atividades planejadas, ou seja, enquanto a</p><p>equipe executa as atividades definidas no plano do projeto, essa execução é monitorada</p><p>para verificar se tudo está ocorrendo conforme planejado. Dessa forma, as atividades</p><p>de controle também são responsáveis pela definição e execução de ações preventivas e</p><p>corretivas. As ações preventivas têm o objetivo de tentar prevenir problemas potenciais</p><p>detectados pelo gerente do projeto. Por outro lado, as ações corretivas têm o objetivo</p><p>de corrigir alguma distorção (no prazo, no custo ou na qualidade) que surgiu durante</p><p>a execução do projeto.</p><p>O controle do projeto também envolve a coleta de dados do projeto, a medição do</p><p>desempenho do projeto e a disseminação de informações sobre esse desempenho.</p><p>Por exemplo, o GP pode coletar com a equipe a quantidade de horas efetivamente</p><p>gastas na execução de determinadas tarefas e comparar com a quantidade de horas</p><p>planejadas para realizar essas tarefas. Assim, ele poderá determinar se o projeto está</p><p>adiantado, no prazo ou atrasado.</p><p>Dessa forma, o controle do projeto está relacionado a:</p><p>» Comparação entre o desempenho planejado e o real.</p><p>» Identificação de áreas que exigem atenção especial.</p><p>» Recomendação de ações para corrigir ou evitar os desvios.</p><p>» Análise e monitoramento dos riscos.</p><p>» Fornecimento de informações para relatórios de progresso.</p><p>» Monitoramento da implementação das mudanças aprovadas.</p><p>5CAPÍTULO</p><p>O COntROLE DO PROJEtO</p><p>69</p><p>O COntROLE DO PROJEtO • CAPÍTULO 5</p><p>Entre as diversas atividades relacionadas ao controle do projeto, é possível destacar:</p><p>» Controle Integrado de Mudanças.</p><p>» Validação do escopo.</p><p>» Controle do escopo.</p><p>» Controle do cronograma.</p><p>» Controle dos custos.</p><p>» Controle da qualidade.</p><p>» Controle dos riscos.</p><p>É importante ressaltar que o controle do escopo, do cronograma, dos custos, da</p><p>qualidade e dos riscos fazem parte da atividade de Controle Integrado de Mudanças.</p><p>Objetivos</p><p>» Compreender as atividades relacionadas ao controle do projeto.</p><p>» Refletir sobre as atividades relacionadas ao controle do projeto.</p><p>5.1 Controle integrado de mudanças</p><p>Figura 42. Mudanças ocorrendo de forma integrada.</p><p>Fonte: https://www.shutterstock.com/pt/image-illustration/background-beautiful-abstract-business-transformation-</p><p>innovation-1043337913.</p><p>70</p><p>CAPÍTULO 5 • O COntROLE DO PROJEtO</p><p>Durante a execução de um projeto é extremamente comum que algumas mudanças</p><p>ocorram. Tais mudanças podem ser solicitadas pelo próprio cliente ou serem motivadas</p><p>por alguns fatores ou situações que surgem ao longo do projeto. As situações que mais</p><p>comumente geram mudanças são:</p><p>» No início do projeto, o cliente não consegue identificar claramente todos os</p><p>requisitos do produto ou serviço a ser criado pelo projeto. Assim, ao longo do</p><p>projeto o cliente pode querer incluir novas demandas não solicitadas inicialmente.</p><p>» Um evento externo, como a mudança de uma legislação ou uma demanda</p><p>governamental que afeta diretamente o projeto.</p><p>» Um erro ou omissão no detalhamento do escopo do produto, como não incluir o</p><p>cadastramento de dados biométricos dos clientes no projeto de desenvolvimento</p><p>de um sistema bancário cujo acesso é controlado por biometria.</p><p>» Um erro ou omissão no detalhamento do escopo do projeto, como não incluir</p><p>o treinamento dos usuários na EAP de um projeto em que o cliente solicita que</p><p>isso seja realizado.</p><p>» A implementação de uma ação de contingenciamento em função de um risco</p><p>identificado no projeto, como subcontratar uma empresa para realizar parte do</p><p>projeto porque a equipe não tem pessoal especializado em quantidade suficiente</p><p>para realizá-lo.</p><p>» Andamento do projeto, em termos de prazo ou custo, está aquém ou além do que</p><p>foi planejado, levando à necessidade de ajustes para tentar colocá-lo novamente</p><p>no rumo correto.</p><p>Note que essas mudanças podem levar ao aumento ou redução do escopo do produto</p><p>ou projeto com impacto direto no prazo, custo e qualidade. Portanto, o gerenciamento</p><p>cuidadoso de um projeto requer estar preparado e atento a essas mudanças.</p><p>O controle integrado de mudanças é a atividade responsável pelo gerenciamento</p><p>contínuo e cuidadoso das mudanças em um projeto, aprovando-as ou rejeitando-as.</p><p>A palavra integrado significa que todos os artefatos afetados pela mudança devem</p><p>ser atualizados para refletir a nova situação, tais como, o plano de gerenciamento</p><p>do projeto, a declaração do escopo, a EAP, o cronograma, o orçamento, entre outros.</p><p>De forma mais detalhada, o controle integrado de mudanças é responsável por registrar</p><p>as mudanças solicitadas, avaliar a sua real necessidade e seus impactos (no prazo, no</p><p>custo, na qualidade etc.), e aprová-las ou reprová-las formalmente. Entretanto, para</p><p>que as mudanças em um projeto sejam avaliadas e aprovadas ou reprovadas é preciso</p><p>que uma pessoa ou um grupo de pessoas tenha autoridade para tal. Normalmente, é</p><p>71</p><p>O COntROLE DO PROJEtO • CAPÍTULO 5</p><p>definido um comitê para controle das mudanças com participação do GP, de membros</p><p>da equipe de projeto e do cliente. Tal comitê, que pode ser definido no início do</p><p>projeto, poderá ter suas responsabilidades e autonomias registradas no Termo de</p><p>Abertura do Projeto ( TAP).</p><p>O controle integrado de mudanças está relacionado à(ao):</p><p>» Identificação de quais mudanças ocorreram ou precisam ocorrer.</p><p>» Revisão do impacto dos custos e benefícios gerados pela mudança.</p><p>» Aprovação das mudanças solicitadas e ações preventivas e corretivas recomendadas.</p><p>» Replanejamento do escopo, custo, cronograma etc., para contemplar a mudança.</p><p>» Gerenciamento das mudanças aprovadas, verificando o seu cumprimento.</p><p>5.2 Validação do escopo</p><p>Figura 43. Aceitando formalmente as entregas concluídas.</p><p>Fonte: https://www.shutterstock.comb/pt/image-photo/business-partnership-meeting-office-1443390962.</p><p>A validação do escopo do projeto é responsável por obter dos stakeholders o aceite</p><p>formal das entregas concluídas. É importante ressaltar que tal atividade não tem como</p><p>objetivo controlar a qualidade das entregas, pois o foco está na aceitação das entregas</p><p>pelo cliente. Geralmente, a validação do escopo é realizada em uma reunião formal</p><p>com o cliente em que a entrega a ser validada é apresentada ao cliente e este avalia</p><p>se a entrega está de acordo com o que foi definido no escopo do projeto.</p><p>É importante compreender que existe uma grande diferença entre validar o escopo e</p><p>realizar o controle de qualidade, conforme mostrado na tabela a seguir:</p><p>72</p><p>CAPÍTULO 5 • O COntROLE DO PROJEtO</p><p>tabela 14. Validar escopo versus realizar o controle da qualidade.</p><p>Validar o Escopo Realizar o Controle da Qualidade</p><p>Trata da aceitação das entregas liberadas pela equipe</p><p>do projeto.</p><p>Trata da avaliação da qualidade do produto gerado no</p><p>projeto, ou seja, é um processo que tenta garantir que a</p><p>entrega gerada tem a qualidade desejada.</p><p>Esse processo é feito junto com o cliente. Esse controle é realizado antes de entregar o produto</p><p>gerado ao cliente,</p><p>É um processo formal que deve coletar o aceite do</p><p>cliente (e-mail, assinatura etc.).</p><p>Ele é normalmente realizado internamente, pela</p><p>equipe do projeto, mas eventualmente o cliente pode</p><p>participar.</p><p>Fonte: Elaborado pela autora.</p><p>Exemplos:</p><p>» A Especificação de Requisitos foi concluída pelos Analistas. Em seguida, foi</p><p>realizada uma inspeção nesse documento, pela própria equipe do projeto, para</p><p>garantir que a especificação não possui defeitos. Essa inspeção é uma forma de</p><p>realizar o controle da qualidade da especificação.</p><p>» O modelo de Entidades-Relacionamentos foi liberado pelos analistas e consta</p><p>na EAP como uma entrega formal do projeto. É marcada uma reunião com o</p><p>cliente em que o administrador de dados irá avaliar o modelo elaborado para</p><p>formalizar sua aceitação. Nessa reunião, será realizada a validação do escopo.</p><p>5.3 Controle do escopo</p><p>Figura 44. Controlando “O que fazer e o que não fazer no projeto?”</p><p>Fonte: https://www.shutterstock.com/pt/image-illustration/person-does-not-know-what-do-1923457298.</p><p>O principal objetivo do controle do escopo é garantir que todas as mudanças</p><p>solicitadas e todas as ações corretivas sejam processadas por meio do controle</p><p>integrado de mudanças.</p><p>73</p><p>O COntROLE DO PROJEtO • CAPÍTULO 5</p><p>A importância dessa atividade reside no fato de que as mudanças podem e vão ocorrer</p><p>em um projeto e o não tratamento adequado dessas mudanças pode levar a sérios</p><p>impactos nos prazos e custos. Duas situações comuns que o controle do escopo tenta</p><p>evitar são:</p><p>» Scope creep: clientes solicitam mudanças aparentemente pequenas diretamente</p><p>à equipe do projeto, levando a alterações substanciais no orçamento e</p><p>cronograma do projeto.</p><p>» Gold plating: com o intuito de agradar ou impressionar o cliente, alguns membros</p><p>da equipe se afastam dos requisitos previamente estabelecidos e criam elementos</p><p>desnecessários ou não solicitados por ele, mudando o escopo do projeto.</p><p>Essas situações, se não forem controladas adequadamente, podem levar ao fracasso</p><p>ou cancelamento do projeto. Assim, para que o controle do escopo seja realizado da</p><p>forma adequada é preciso:</p><p>» Definir a documentação necessária para solicitação de mudanças no escopo</p><p>do projeto:</p><p>› Essa documentação pode ser um formulário (Word, Excel) a ser preenchido pelo</p><p>solicitante no qual ele descreve, de forma breve e objetiva, o que deseja, razão da</p><p>mudança, urgência etc.</p><p>› O objetivo é evitar solicitações diretas à equipe de desenvolvimento, mudanças</p><p>solicitadas sem avaliar sua relevância, alterações no escopo sem o detalhamento</p><p>necessário, entre outros.</p><p>» Criar um grupo responsável pela análise das solicitações de mudança de escopo:</p><p>› Alguém desse grupo deve ser o ponto focal para o recebimento das solicitações.</p><p>› Pelo menos um membro do cliente deve fazer parte desse grupo.</p><p>› Deve ser estabelecido qual o nível de autonomia desse grupo em relação a aprovar/</p><p>reprovar as solicitações (quanto mais autonomia, melhor).</p><p>› Caso o grupo não tenha autonomia total, devem ser estabelecidos os níveis para</p><p>autorização das mudanças no escopo.</p><p>» A reprovação da solicitação deve sempre ser justificada ao solicitante.</p><p>» Divulgar o processo de solicitação de mudança a todos os stakeholders:</p><p>› É muito importante que haja transparência, ou seja, todos os envolvidos (tanto do</p><p>lado do cliente quanto do lado da equipe do projeto) devem estar cientes de como</p><p>ocorre esse processo.</p><p>74</p><p>CAPÍTULO 5 • O COntROLE DO PROJEtO</p><p>» Gerar relatórios sobre o impacto das mudanças no prazo e custo do projeto:</p><p>› É muito importante que sejam registrados e divulgados os impactos das mudanças</p><p>aprovadas no tempo e custo do projeto.</p><p>› Essa divulgação pode se periódica (junto com o relatório de desempenho geral do</p><p>projeto, por exemplo), mas deve destacar esses impactos.</p><p>» Obter sempre a aprovação formal do cliente para a mudança:</p><p>› Uma vez aprovada a solicitação, ela só deve ser efetivamente implementada pela</p><p>equipe após a sua aprovação formal (e-mail, assinatura etc.) pelo cliente.</p><p>Saiba mais</p><p>Para apoiar o cadastramento e o acompanhamento das solicitações de mudança, é possível usar um Sistema de</p><p>Gerenciamento de Tickets (Issue Tracking Systems). Existem alguns bons sistemas open source desse tipo, como</p><p>Bugzilla e Trac.</p><p>5.4 Controle do cronograma</p><p>O controle do cronograma tem como objetivo monitorar o andamento das tarefas</p><p>previstas no cronograma do projeto a fim de reconhecer eventuais desvios e atrasos</p><p>e tomar medidas corretivas e preventivas, evitando, assim, atrasos no projeto.</p><p>Para realizar o controle do cronograma, é preciso, primeiramente, conhecer o</p><p>desempenho real da equipe. Para isso, é preciso coletar periodicamente informações</p><p>como, quais tarefas já foram realizadas e se elas foram realizadas no prazo planejado,</p><p>e quais tarefas estão em andamento e a sua previsão de término. A partir desse</p><p>levantamento, é possível determinar a situação atual do cronograma (adiantado</p><p>ou atrasado) e que fatores tiveram influência nessas variações de prazo. A análise</p><p>das variações no cronograma pode resultar em solicitações de mudança no próprio</p><p>cronograma ou no escopo do projeto, de forma a manter os prazos de entrega</p><p>previamente planejados.</p><p>O monitoramento periódico do cronograma é importante por causa de um efeito</p><p>conhecido como Síndrome do Estudante, que diz que existe uma tendência natural</p><p>do ser humano de postergar suas atividades até o último momento. Esse efeito é</p><p>representado pela figura 45. Note que o esforço empregado na execução da tarefa é</p><p>pequeno quando a data de entrega está distante e aumenta consideravelmente quando</p><p>a data de entrega se aproxima. Para evitar esse efeito e minimizar as chances de atraso</p><p>75</p><p>O COntROLE DO PROJEtO • CAPÍTULO 5</p><p>é muito importante monitorar uma tarefa durante toda a sua execução e não apenas</p><p>próximo ao seu término.</p><p>Figura 45. nível de esforço e a data de entrega.</p><p>Fonte: Elaborado pela autora.</p><p>Atenção</p><p>Durante o controle do cronograma, o Gerente de Projeto deve acompanhar de perto as tarefas do caminho crítico.</p><p>Caminho crítico: sequência de tarefas do cronograma que, se atrasarem, causarão o atraso do projeto.</p><p>Na ocorrência de atrasos no cronograma é possível adotar duas técnicas para tentar</p><p>recolocar o cronograma no prazo planejado inicialmente:</p><p>» Paralelização (Fast Tracking): consiste em paralelizar o final de uma tarefa com</p><p>o início da tarefa sucessora, encurtando o cronograma em alguns dias.</p><p>Figura 46. Paralelização.</p><p>Fonte: Elaborado pela autora.</p><p>76</p><p>CAPÍTULO 5 • O COntROLE DO PROJEtO</p><p>» Compressão (Crashing): consiste em aumentar a quantidade de horas trabalhadas</p><p>por dia ou a quantidade de recursos alocados na tarefa.</p><p>Atenção</p><p>Tanto a técnica de paralelização quanto a de compressão devem ser utilizadas com cuidado:</p><p>» Pode haver sobrecarga dos recursos, ou seja, recursos trabalhando muitas horas por dia.</p><p>» Pode ser necessário pagar horas extras, o que vai aumentar o custo do projeto.</p><p>» Aumentar a quantidade de recursos de uma tarefa não necessariamente diminui a quantidade de horas para realizá-la. Por</p><p>exemplo, se um programador vai levar 16 horas para executar uma tarefa, isso não quer dizer que dois programadores vão</p><p>levar oito horas para realizá-la.</p><p>Pode ser interessante o uso de ferramentas para o controle do cronograma?</p><p>Importante</p><p>A utilização de uma ferramenta adequada, como o Microsoft Project©, é fundamental para o gerenciamento do tempo e,</p><p>em particular, para o controle do cronograma, pois ele exige cálculos detalhados, cujos erros podem comprometer todo o</p><p>monitoramento. Nesse caso, o uso de planilhas não é recomendado.</p><p>Existem pontos de atenção no controle do cronograma! Observemos!</p><p>Atenção</p><p>Pontos de atenção no controle do cronograma:</p><p>» Colete periodicamente os dados de desempenho da equipe, isto é, informações sobre quais tarefas foram iniciadas e o seu</p><p>progresso, quais tarefas foram concluídas e quanto tempo levaram.</p><p>» Dê atenção especial às atividades do caminho crítico.</p><p>» Aja preventivamente, assim que as causas que podem impactar no cronograma planejado forem detectadas.</p><p>» Tente utilizar paralelismo e compressão para tratar pontualmente as tarefas atrasadas.</p><p>» Gere periodicamente relatórios de desempenho contendo as datas de início e término planejadas e reais de cada tarefa e</p><p>comunique aos stakeholders.</p><p>5.5 Controle dos custos</p><p>O controle dos custos tem como objetivo monitorar o andamento das tarefas previstas</p><p>no projeto a fim de detectar desvios no orçamento planejado e tomar medidas corretivas</p><p>e preventivas, evitando, assim, aumento nos custos do projeto.</p><p>77</p><p>O COntROLE DO PROJEtO • CAPÍTULO 5</p><p>Para realizar o controle dos custos também é preciso coletar periodicamente informações</p><p>e conhecer o desempenho real da equipe. Na realidade, os mesmos dados levantados</p><p>no controle do cronograma também são usados no controle dos custos. Por isso, essas</p><p>duas atividades ocorrem conjuntamente e não podem ser dissociadas.</p><p>A principal técnica de controle de custos é a Análise de Valor Agregado, também</p><p>conhecida como Técnica do Valor Agregado ou Gerenciamento do Valor Agregado. Essa</p><p>técnica requer uma série de cálculos e deve ser adotada caso o gerente de projeto use</p><p>alguma ferramenta que implementa esses cálculos.</p><p>Saiba mais</p><p>Tanto o controle do cronograma quanto o controle dos custos dependem do uso de ferramentas adequadas. Veja a lista de</p><p>ferramentas comerciais e open source para gerenciamento de tempo e custo. Disponível em: http://en.wikipedia.org/wiki/</p><p>Comparison_of_project_management_software.</p><p>5.6 Controle da qualidade</p><p>É uma atividade técnica usada para verificar se as entregas têm a qualidade desejada</p><p>e se estão completas e corretas, de acordo com o escopo do produto. Caso sejam</p><p>descobertos problemas de qualidade, é feita a análise dos defeitos para determinar</p><p>suas causas e definir ações para eliminar tais causas.</p><p>No contexto do gerenciamento da qualidade, dois termos por vezes são confundidos</p><p>e tratados como sinônimos. Veja, a seguir, uma tabela que compara garantia de</p><p>qualidade com controle da qualidade.</p><p>Tabela 15. Garantia de qualidade versus controle da qualidade.</p><p>Garantia da Qualidade Controle da Qualidade</p><p>Foco na adequação dos processos. Foco na descoberta de defeitos.</p><p>Voltada para a prevenção. Voltado para a detecção.</p><p>Orientada a processos. Orientada a produtos.</p><p>Utiliza auditoria e análise de processos. Utiliza revisões e testes para avaliar o produto.</p><p>Analisa os processos para recomendar ações corretivas ou</p><p>preventivas.</p><p>Revisa ou testa os produtos para identificar defeitos.</p><p>É realizada durante a execução das tarefas. É realizada após a elaboração do produto.</p><p>Procura garantir que a equipe está trabalhando em</p><p>conformidade com o que foi definido.</p><p>Procura avaliar se o produto está em conformidade</p><p>com o que foi definido.</p><p>Fonte: Elaborado pela autora.</p><p>78</p><p>CAPÍTULO 5 • O COntROLE DO PROJEtO</p><p>As duas principais estratégias de controle da qualidade são as inspeções e os testes:</p><p>» Inspeção: é o exame de um produto para determinar se ele está em conformidade</p><p>com os padrões predefinidos. Note que a inspeção não envolve o uso efetivo</p><p>do produto. Geralmente uma inspeção é feita a partir de uma lista de itens que</p><p>devem ser verificados em determinado produto. Por exemplo: ao fabricar uma</p><p>televisão, um funcionário pode inspecioná-la para verificar se ela não está</p><p>arranhada, nem com parafusos soltos e nem com a tela trincada.</p><p>» Teste: é o processo de usar um produto ou parte dele e verificar se ele corresponde</p><p>ao que foi definido. Note que o teste envolve, necessariamente, o uso efetivo do</p><p>produto. Por exemplo: ao fabricar uma televisão, um funcionário pode testá-la</p><p>ligando-a, alterando os canais, o volume, o brilho etc.</p><p>5.7 Controle dos riscos</p><p>Figura 47. Como controlar os riscos?</p><p>Fonte: https://www.shutterstock.com/pt/image-photo/firefighter-extinguishes-burning-car-after-accident-1779471089.</p><p>O controle dos riscos tem como objetivo monitorar os riscos identificados previamente,</p><p>identificar novos riscos que podem ter surgido ao longo do projeto, executar as ações</p><p>do plano de resposta aos riscos e avaliar a eficácia das ações executadas anteriormente.</p><p>Assim, essa atividade é executada continuamente durante todo o ciclo de vida do</p><p>projeto, sendo o responsável pelo monitoramento dos riscos identificados e riscos</p><p>residuais, identificação de novos riscos, execução das ações definidas no plano de</p><p>respostas e avaliação da eficácia das ações executadas.</p><p>79</p><p>O COntROLE DO PROJEtO • CAPÍTULO 5</p><p>O controle dos riscos inclui:</p><p>» Reavaliar os riscos existentes e os respectivos planos de resposta.</p><p>» Avaliar a eficácia das respostas executadas anteriormente.</p><p>» Verificar se os procedimentos e políticas adequadas estão sendo seguidos.</p><p>» Analisar se as contingências estabelecidas de custo, prazo etc., devem ser</p><p>modificadas.</p><p>O controle dos riscos geralmente gera como resultado um conjunto de ações:</p><p>» Ações corretivas recomendadas: são respostas que não foram inicialmente</p><p>planejadas, mas são necessárias para lidar com os riscos emergentes que não</p><p>foram identificados anteriormente ou que foram aceitos passivamente.</p><p>» Ações preventivas recomendadas: ações que visam garantir que, futuramente,</p><p>o projeto não sofrerá impacto dos riscos identificados.</p><p>Sintetizando</p><p>O que vimos neste Capítulo:</p><p>» O controle integrado de mudanças diz respeito, entre outros, à(ao): identificação de quais mudanças ocorreram ou</p><p>precisam ocorrer, revisão do impacto dos custos e benefícios gerados pela mudança, replanejamento do escopo, custo,</p><p>cronograma, entre outros, para contemplar a mudança etc.</p><p>» A validação do escopo é responsável por obter das partes interessadas o aceite formal das entregas concluídas, sem ter</p><p>como objetivo o controle da qualidade das entregas.</p><p>» O controle do escopo tem como principal objetivo garantir que todas as mudanças solicitadas e todas as ações corretivas</p><p>sejam processadas por meio do controle integrado de mudanças.</p><p>» O controle do cronograma tem como objetivo monitorar o andamento das tarefas previstas no cronograma do projeto,</p><p>para reconhecer eventuais desvios e atrasos e tomar medidas corretivas e preventivas. Dessa forma, evitam-se atrasos no</p><p>projeto.</p><p>» O objetivo do controle dos custos é monitorar o andamento das tarefas previstas no projeto, a fim de identificar desvios no</p><p>orçamento planejado e tomar medidas corretivas e preventivas, evitando, assim, o aumento nos custos do projeto.</p><p>» O controle da qualidade verifica se as entregas têm a qualidade desejada e se estão completas e corretas, de acordo com o</p><p>escopo do produto.</p><p>» O objetivo do controle dos riscos é monitorar os riscos identificados previamente, identificar novos riscos que podem ter</p><p>surgido ao longo do projeto, executar as ações do plano de resposta aos riscos e avaliar a eficácia das ações executadas</p><p>anteriormente.</p><p>80</p><p>Introdução</p><p>Da mesma forma que existem atividades específicas associadas à iniciação de um</p><p>projeto, também existem atividades especificamente destinadas ao encerramento</p><p>do projeto. Na realidade, essas atividades devem ser executadas no encerramento do</p><p>projeto ou no encerramento de uma fase do projeto, para os casos de projetos que são</p><p>divididos em fases. Existem duas grandes atividades no encerramento de um projeto,</p><p>que serão tratadas neste capítulo:</p><p>» Encerramento das atividades do projeto ou fase.</p><p>» Encerramento das aquisições.</p><p>Objetivos</p><p>» Compreender as atividades relacionadas ao encerramento do projeto ou fase.</p><p>» Compreender o encerramento das aquisições.</p><p>Figura 48. Projeto encerrado!</p><p>Fonte: https://www.shutterstock.com/pt/image-photo/smiling-businessman-doing-relaxing-exercise-</p><p>workplace-1185464599.</p><p>6CAPÍTULO</p><p>O EnCERRAMEntO DO PROJEtO</p><p>81</p><p>O EnCERRAMEntO DO PROJEtO • CAPÍTULO 6</p><p>6.1 Encerramento do projeto ou fase</p><p>Essa atividade consiste em finalizar todas as atividades e encerrar, formalmente, o</p><p>projeto ou uma fase do projeto. Ela está relacionada a:</p><p>» Garantia de que os critérios de sucesso do projeto foram atingidos.</p><p>» Formalização do aceite dos produtos ou serviços entregues.</p><p>» Liberação dos recursos para que eles possam ser utilizados em outros</p><p>empreendimentos.</p><p>» Transferências dos produtos ou serviços para a próxima fase (se o encerramento</p><p>é de uma fase).</p><p>» Registro das lições aprendidas para uso futuro.</p><p>» Investigação das razões do fracasso do projeto (se o projeto falhou).</p><p>Mais uma vez, o papel do gerente de projeto (GP) é fundamental. Ele deve revisar as</p><p>informações referentes aos encerramentos de fases anteriores (se existirem) e assegurar</p><p>que todo o trabalho do projeto foi concluído e que o projeto atingiu os objetivos.</p><p>Assim, o encerramento do projeto ou fase contempla várias ações:</p><p>» Ações necessárias para atender aos critérios de conclusão do projeto ou de</p><p>término da fase.</p><p>» Ações necessárias para transferir produtos, serviços ou resultados do projeto</p><p>para a próxima fase ou para produção e/ou operações.</p><p>» Ações necessárias para auditar o projeto em relação ao seu</p><p>sucesso ou fracasso.</p><p>» Ações necessárias para coletar lições aprendidas e arquivar informações do</p><p>projeto para o uso futuro da organização.</p><p>6.2 Encerramento das aquisições</p><p>Figura 49. Encerramento do contrato.</p><p>Fonte: https://www.shutterstock.com/pt/image-vector/contract-signing-document-seal-pen-sign-1214452414.</p><p>82</p><p>CAPÍTULO 6 • O EnCERRAMEntO DO PROJEtO</p><p>Em diversos projetos, principalmente nos mais complexos, é comum a contratação</p><p>de recursos, produtos ou serviços de terceiros. Em gerenciamento de projetos, essas</p><p>contratações são chamadas de aquisições. Exemplos de aquisições:</p><p>» Contratar um profissional terceirizado para executar determinada tarefa do</p><p>projeto para a qual não existem recursos adequados na equipe.</p><p>» Alugar equipamentos ou salas que serão usadas em uma fase do projeto.</p><p>» Subcontratar outra empresa para realizar uma tarefa específica, como, por</p><p>exemplo, projetar o layout de um website.</p><p>Dessa forma, se existem empresas ou recursos subcontratados, o encerramento do</p><p>projeto ou fase deve, necessariamente, encerrar também essas aquisições.</p><p>O encerramento das aquisições é responsável pelo encerramento dos contratos,</p><p>aceitação do produto e/ou serviço gerado e resolução de pendências, além de atividades</p><p>administrativas como finalização das solicitações em aberto, atualização nos registros</p><p>para mostrar os resultados finais e arquivamento dessas informações para uso futuro.</p><p>O principal benefício do encerramento das aquisições é a documentação dos acordos</p><p>e outros documentos relacionados, para futuras consultas. Por exemplo, o comprador</p><p>notificará formalmente o fornecedor de que o contrato foi terminado. Entretanto, se</p><p>houver garantias para o produto, as obrigações do fornecedor continuarão após o</p><p>encerramento das aquisições.</p><p>Atenção</p><p>Para encerrar um projeto temos que:</p><p>» Avaliar se o trabalho realizado está em conformidade com os requisitos estabelecidos.</p><p>» Encerrar as aquisições.</p><p>» Entregar os produtos ou serviços terminados.</p><p>» Obter a aceitação final do produto ou serviço.</p><p>» Terminar o encerramento financeiro.</p><p>» Solicitar feedback do cliente sobre o projeto.</p><p>» Terminar os relatórios finais de desempenho.</p><p>» Atualizar a base de conhecimento de lições aprendidas.</p><p>As atividades de encerramento do projeto devem sempre ser executadas, não importando</p><p>se o projeto foi interrompido, cancelado ou terminado com sucesso.</p><p>83</p><p>O EnCERRAMEntO DO PROJEtO • CAPÍTULO 6</p><p>Atenção</p><p>É possível confundir o “encerrar projeto ou a fase” com o “encerrar aquisições”. Para tentar desfazer tal situação, vejamos:</p><p>» Podem existir muitas aquisições em um projeto. Dessa forma, haverá muitos encerramentos de aquisições, mas apenas</p><p>um encerramento do projeto, que será no fim do projeto ou da fase. É bom notar que, com o fim do contrato de cada</p><p>aquisição, o gerente do projeto realiza uma auditoria da aquisição e encerra a aquisição. Quando, depois, o projeto for</p><p>completado totalmente, o gerente do projeto o encerrará.</p><p>» O encerramento das aquisições precisa ocorrer antes do encerramento final do projeto.</p><p>Sintetizando</p><p>O que vimos neste Capítulo:</p><p>» O encerramento do projeto deve sempre ocorrer, independentemente se o projeto foi concluído, interrompido ou</p><p>cancelado.</p><p>» O encerramento do projeto ou fase envolve a formalização do aceite dos produtos ou serviços entregues, entre outras</p><p>ações.</p><p>» O encerramento das aquisições é responsável pelo encerramento dos contratos, aceitação do produto e/ou serviço gerado</p><p>e resolução de pendências, além de atividades administrativas como finalização das solicitações em aberto, entre outros.</p><p>» Não confundir encerramento do projeto ou fase com encerramento das aquisições.</p><p>84</p><p>Referências</p><p>ABNT. NBR ISO 10006. Gestão da qualidade – Diretrizes para a qualidade no gerenciamento de Projetos,</p><p>2000.</p><p>DINSMORE, Paul; CABANIS-BREWIN, Jeannette. AMA – Manual de Gerenciamento de Projetos. Brasport,</p><p>2009.</p><p>MULCAHY´S, Rita; DIETHELM, Laurie. Preparatório para o Exame de PMP. 7. ed. RMC Publications, 2011.</p><p>MENDES, João Ricardo Barroca. Gerenciamento de Projetos. FGV, 2009.</p><p>HELDMAN, Kim. Gerência de Projetos – Guia para o Exame Oficial do PMI. 5. ed. Campus, 2009.</p><p>PROJECT MANAGEMENT INSTITUTE (PMI). Um Guia do Conhecimento em Gerenciamento de Projetos</p><p>(Guia PMBOK). 5. ed. Project Management Institute (PMI), 2013.</p><p>_Hlk79152813</p><p>_Hlk79152840</p><p>_Ref69489436</p><p>_Hlk70608853</p><p>_Hlk70945729</p><p>_Hlk70609227</p><p>_Hlk70525499</p><p>_Hlk70525565</p><p>_Hlk70529561</p><p>_Hlk70525580</p><p>_Hlk79155618</p><p>_Hlk79155641</p><p>_Hlk79155679</p><p>_Hlk71902330</p><p>_Hlk72239296</p><p>_Hlk79155860</p><p>_Hlk70942670</p><p>_Hlk79155896</p><p>_Hlk79155911</p><p>_Hlk79155932</p><p>_Hlk79155961</p><p>_Hlk79155973</p><p>_Hlk79155993</p><p>_Hlk79156040</p><p>_Hlk79156062</p><p>_Hlk79156077</p><p>Organização do Livro Didático</p><p>Introdução</p><p>Capítulo</p><p>Visão Geral sobre Gerência de Projetos</p><p>Capítulo</p><p>O Início do Projeto</p><p>Capítulo</p><p>O Planejamento do Projeto</p><p>Capítulo</p><p>A Execução do Projeto</p><p>Capítulo</p><p>O Controle do Projeto</p><p>Capítulo</p><p>O Encerramento do Projeto</p><p>Referências</p><p>para</p><p>explorar oportunidades estratégicas quanto para prevenir ameaças à sua estratégia e</p><p>atender às necessidades do mercado.</p><p>1</p><p>CAPÍTULO</p><p>VISãO GERAL SOBRE GERÊnCIA DE</p><p>PROJEtOS</p><p>10</p><p>CAPÍTULO 1 • VISãO GERAL SOBRE GERÊnCIA DE PROJEtOS</p><p>Figura 3. Estratégia das organizações e projetos.</p><p>Fonte: Elaborado pela autora.</p><p>Como os projetos são o modus operandi para implementar de forma efetiva a estratégia</p><p>das organizações, o alinhamento destes à estratégia é vital para conservar e usar com</p><p>eficiência os recursos da organização e, portanto, não desperdiçar pessoas, capital e</p><p>equipamentos.</p><p>Saiba mais</p><p>Modus operandi significa o modo pelo qual um indivíduo ou uma organização desenvolve ou opera suas atividades.</p><p>Alguns exemplos de projetos criados como resultado de considerações estratégicas:</p><p>tabela 1. Exemplos de projetos de acordo com a consideração estratégica.</p><p>Consideração estratégica Exemplos de projeto</p><p>Demanda de mercado</p><p>Uma companhia automobilística autoriza um projeto para a</p><p>fabricação de carros energeticamente eficientes em resposta à</p><p>escassez de gasolina.</p><p>Oportunidade/necessidade estratégica de</p><p>negócios</p><p>Uma empresa de treinamento autoriza um projeto para criar um</p><p>novo curso.</p><p>Avanço tecnológico</p><p>Uma empresa de produtos eletrônicos autoriza um novo projeto</p><p>para desenvolver um laptop mais veloz, mais barato e de menor</p><p>tamanho.</p><p>Solicitação do cliente</p><p>Uma companhia de energia elétrica autoriza um projeto de</p><p>construção de uma nova subestação para atender a um novo</p><p>parque industrial.</p><p>Fonte: PMBOK (2013 p. 10).</p><p>11</p><p>VISãO GERAL SOBRE GERÊnCIA DE PROJEtOS • CAPÍTULO 1</p><p>Outro exemplo bastante simples de projeto seria escrever um artigo de fim de semestre</p><p>de uma disciplina. Nesse cenário, você pode ter:</p><p>» uma oportunidade: viajar e apresentar o artigo em um congresso.</p><p>» uma ameaça: ser reprovado na disciplina, caso não escreva o artigo.</p><p>Note que, em ambos os casos, é vital planejar a construção do artigo antes de começar</p><p>a escrevê-lo efetivamente! Esse planejamento envolve definir o título e o objetivo do</p><p>seu artigo, definir as seções do artigo, quantas páginas ele deverá ter, a data final na</p><p>qual o artigo deverá ser entregue, entre outros. Em seguida, várias tarefas deverão</p><p>ser executadas, como realizar a revisão bibliográfica e/ou coletar dados da pesquisa</p><p>realizada, a escrita do artigo e a sua revisão. É importante ressaltar que, ao final de</p><p>todas essas tarefas, será gerado um produto único: o seu artigo!</p><p>Mas o que é um projeto, afinal? A literatura técnica apresenta várias definições</p><p>para projeto:</p><p>Processo único, consistindo em um grupo de atividades coordenadas e</p><p>controladas com datas para início e término, empreendido para alcance</p><p>de um objetivo conforme requisitos específicos, incluindo limitações de</p><p>tempo, custo e recursos. (ABNT, 2000)</p><p>“Um empreendimento temporário, planejado, executado e controlado</p><p>com objetivo de criar um produto ou serviço único.” (PMBOK, 2013).</p><p>“Esforço temporário empreendido para criar um produto, serviço ou</p><p>resultado exclusivo.” (PMBOK, 2013, p. 3)</p><p>A partir dessas definições, é possível estabelecer as principais características de um</p><p>projeto, que são:</p><p>» Temporalidade: projetos são empreendimentos temporários, isto é, devem</p><p>obrigatoriamente ter um início e um fim bem definidos. Não importa se são</p><p>curtos ou longos.</p><p>» Exclusividade: projetos criam produtos ou serviços únicos.</p><p>» Objetividade: projetos têm um foco claro, ou seja, devem ser definidos claramente</p><p>os produtos e serviços a serem gerados.</p><p>» Elaboração progressiva: o produto ou serviço tem suas características</p><p>determinadas progressivamente.</p><p>12</p><p>CAPÍTULO 1 • VISãO GERAL SOBRE GERÊnCIA DE PROJEtOS</p><p>1.2 Operações versus projetos</p><p>Como foi mostrado nas seções anteriores, todo projeto possui início e fim bem definidos.</p><p>Será, então, que atividades rotineiras ou processos rotineiros ou operações podem ser</p><p>considerados projetos? Não! O projeto é realizado apenas uma vez. Quando o projeto</p><p>é concluído obtém-se um novo produto ou serviço. Por outro lado, as operações são</p><p>processos rotineiros, repetitivos e com padrão conhecido.</p><p>tabela 2. Exemplos de projetos e de operações.</p><p>Exemplos de projetos Exemplos de processos rotineiros ou operações</p><p>Montar um estande de vendas para um congresso de</p><p>contabilidade.</p><p>Inserir diariamente notas fiscais de venda no livro</p><p>contábil.</p><p>Projetar um celular com determinadas características. Fabricação de celulares, montando-os, peça por peça.</p><p>Fonte: Elaborado pela autora.</p><p>tabela 3. As semelhanças e as diferenças entre Operação e Projeto.</p><p>Operação Projeto</p><p>Semelhanças</p><p>» Realizados por pessoas</p><p>» Limitados aos recursos disponíveis</p><p>» Planejados, executados e controlados</p><p>Diferenças</p><p>» Contínua: mesmo processo repetido várias vezes</p><p>» Repetitiva: produz o mesmo resultado diversas</p><p>vezes</p><p>» Temporário: início e fim bem</p><p>definidos</p><p>» Exclusivo: produz resultado único</p><p>Fonte: Elaborado pela autora.</p><p>1.3 Ciclo de vida de um projeto</p><p>Projetos possuem um ciclo de vida, que é definido por um conjunto de fases, executadas</p><p>em uma ordem lógica e em um espaço finito de tempo, que conectam o início e o</p><p>fim do projeto. Cada fase do projeto apresenta um ou mais resultados que indicam a</p><p>evolução do projeto. Esses resultados são chamados entregas ou deliverables.</p><p>No passado, o foco da gestão de projetos consistia em alocar pessoal competente para</p><p>assegurar o seu sucesso. Apesar de essa abordagem ser necessária, o pensamento</p><p>atual diz que procedimentos, processos, políticas e ferramentas são vitais para um</p><p>bom gerenciamento. Entre as abordagens de gerenciamento, a mais difundida é a</p><p>do Project Management Body of Knowledge (PMBoK), que considera que a gestão de</p><p>projetos deve ser realizada por meio de cinco grupos de processos, como ilustrado</p><p>na figura a seguir:</p><p>13</p><p>VISãO GERAL SOBRE GERÊnCIA DE PROJEtOS • CAPÍTULO 1</p><p>Figura 4. Grupos de processos de gerenciamento.</p><p>Fonte: PMBOK (2013).</p><p>Por trás da organização do gerenciamento em cinco grupos de processos está um</p><p>princípio bastante simples: primeiro, planejar; em seguida, executar; depois, avaliar</p><p>o que foi realizado e, por fim, aplicar ações para melhoria. Nesse contexto, o ciclo de</p><p>vida mais famoso é o PDCA (Plan-Do-Check-Act).</p><p>Figura 5. Ciclo PDCA.</p><p>Fonte: Elaborado pela autora.</p><p>1.4 Fatores de sucesso</p><p>No princípio do gerenciamento de projetos, o sucesso ou fracasso era medido</p><p>exclusivamente por meio de fatores técnicos, ou seja, o produto final era avaliado</p><p>como adequado ou inadequado.</p><p>14</p><p>CAPÍTULO 1 • VISãO GERAL SOBRE GERÊnCIA DE PROJEtOS</p><p>Na moderna gestão de projetos, alguns fatores devem ser observados:</p><p>» Cumprimento de prazos.</p><p>» Cumprimento de custos.</p><p>» Cumprimento do escopo.</p><p>» A qualidade do produto final (que passa a ser definida pelo cliente).</p><p>Saiba mais</p><p>O escopo do projeto define o que será feito e o que não será feito no projeto.</p><p>Dessa forma, podemos chegar a mais uma definição importante relacionada ao</p><p>gerenciamento de projetos:</p><p>“Um projeto pode ser considerado bem-sucedido se foi realizado dentro do prazo,</p><p>orçamento e escopo estabelecidos, possui o nível de qualidade desejado e atendeu</p><p>às expectativas das partes interessadas (stakeholders).” (PMBOK, 2013)</p><p>Saiba mais</p><p>Stakeholders são as partes interessadas no projeto, tais como clientes, entre outros.</p><p>1.5 Perfil do Gerente de Projeto</p><p>Como vimos anteriormente, projetos:</p><p>» São executados por pessoas.</p><p>» Possuem recursos limitados (financeiros, humanos etc.).</p><p>» Têm um ciclo de vida.</p><p>» Demandam que um conjunto de atividades seja executado.</p><p>» Devem produzir o resultado previamente definido.</p><p>15</p><p>VISãO GERAL SOBRE GERÊnCIA DE PROJEtOS • CAPÍTULO 1</p><p>Nesse contexto, surge a necessidade de estabelecer uma estrutura própria, liderada</p><p>por um gerente de projeto, que defina a alocação dos recursos adequados e verifique o</p><p>cumprimento dos prazos e orçamentos previamente definidos, por meio de ferramentas</p><p>de planejamento e controle.</p><p>O gerente de projetos</p><p>é a pessoa alocada pela organização executora para liderar a</p><p>equipe responsável por alcançar os objetivos do projeto.</p><p>Não confunda gerente de projetos com gerente funcional ou gerente de operações.</p><p>O gerente funcional, normalmente, atua na gerência de uma unidade funcional ou de</p><p>negócios, e os gerentes de operações são responsáveis pela eficiência das operações</p><p>de negócios.</p><p>Que habilidades o gerente de projeto deve demonstrar?</p><p>» Liderança.</p><p>» Desenvolvimento de equipe.</p><p>» Motivação.</p><p>» Comunicação.</p><p>» Influência.</p><p>» Tomada de decisões.</p><p>» Consciência política e de negócio.</p><p>» Negociação.</p><p>E quais as competências de um gerente de projeto?</p><p>» Conhecimentos técnicos e administrativos.</p><p>» Habilidades gerenciais, de relacionamento e políticas.</p><p>» Atitude.</p><p>tabela 4. Competências do gerente de projeto.</p><p>Competências do Gerente de Projeto Significado</p><p>Conhecimentos técnicos e administrativos</p><p>Passíveis de aprendizado na formação profissional ou experiência.</p><p>Estão ligados ao campo racional:</p><p>» Domínio de conceitos, técnicas e metodologias.</p><p>» Competência na área de especialização e áreas correlatas.</p><p>» Conhecimento das práticas, políticas e valores da organização.</p><p>» Conhecimento de sistemas administrativo-financeiros e de RH.</p><p>16</p><p>CAPÍTULO 1 • VISãO GERAL SOBRE GERÊnCIA DE PROJEtOS</p><p>Competências do Gerente de Projeto Significado</p><p>Habilidades gerenciais, de</p><p>relacionamento e políticas</p><p>Relacionadas diretamente aos aspectos da personalidade. Estão</p><p>ligadas ao campo emocional:</p><p>» Liderança.</p><p>» Comunicação.</p><p>» negociação.</p><p>» Influência.</p><p>» Motivação.</p><p>» Disciplina.</p><p>» Resolução de conflitos.</p><p>Atitude</p><p>Baseada em valores, sentimentos e crenças individuais:</p><p>» Interesse por questões administrativas.</p><p>» Ambição profissional.</p><p>Fonte: Elaborado pela autora.</p><p>1.6 Estruturas organizacionais</p><p>De que forma a equipe de um projeto pode ser organizada dentro do contexto de uma</p><p>organização? As estruturas organizacionais normalmente restringem a disponibilidade</p><p>de recursos em um espectro que varia de hierárquico a projetizado, passando por</p><p>algumas combinações destes:</p><p>1.6.1 Estrutura funcional ou hierárquica</p><p>Esta estrutura não tem exatamente um gerente de projeto destacado unicamente</p><p>para esse fim. A figura dominante é a do gerente funcional, que poderá montar sua</p><p>equipe a partir de pessoas de outras equipes, de outros departamentos, como mostra</p><p>a figura a seguir.</p><p>Figura 6. Estrutura hierárquica de uma organização.</p><p>Fonte: PMBOK (2013, p. 21).</p><p>17</p><p>VISãO GERAL SOBRE GERÊnCIA DE PROJEtOS • CAPÍTULO 1</p><p>No exemplo da figura 7 a seguir aparecem os departamentos de Produção, Manutenção</p><p>e Administração. Logo, cada funcionário terá, em um nível superior, um gerente de</p><p>produção ou um gerente de manutenção ou um gerente de administração. Porém, cada</p><p>departamento pode se especializar, ou seja, ter subdivisões: Fundição e Laminação</p><p>são especializações do departamento de Produção; Caldeiraria, Mecânica e Elétrica</p><p>são especializações do departamento de Manutenção e, por fim, RH e Vendas são</p><p>especializações do departamento de Administração. O gerente do projeto pode, por</p><p>exemplo, ser o gerente funcional de produção, que terá em sua equipe pessoas de</p><p>outras áreas. As equipes destacadas em vermelho formariam a equipe do gerente</p><p>funcional responsável pelo projeto.</p><p>Figura 7. Exemplo de projeto em uma estrutura hierárquica.</p><p>Fonte: Elaborado pela autora.</p><p>E quais são as vantagens e desvantagens desse tipo de estrutura organizacional?</p><p>Tabela 5. Vantagens e desvantagens na estrutura hierárquica.</p><p>Vantagens Desvantagens</p><p>Pessoas se reportam a apenas um gerente. Dificuldade de coordenação entre funções diferentes.</p><p>Desenvolvimento mais fácil de excelência técnica. Conflito de interesses entre funções diferentes.</p><p>Objetivos e prioridades claras. Gerentes funcionais não se sentem responsáveis por</p><p>projetos multifuncionais.</p><p>Sinergia mais fácil entre especialistas. Adesão ao ponto de vista da função.</p><p>Fácil gerenciamento dos especialistas. Subordinação dos objetivos da gerência funcional aos</p><p>objetivos da gerência de projeto.</p><p>Fonte: Elaborado pela autora.</p><p>18</p><p>CAPÍTULO 1 • VISãO GERAL SOBRE GERÊnCIA DE PROJEtOS</p><p>1.6.2 Estrutura projetizada</p><p>A maior vantagem desta estrutura organizacional é que a autoridade total do projeto</p><p>é do gerente de projeto, ao qual está subordinada a equipe do projeto.</p><p>Figura 8. Exemplo de projeto em uma estrutura projetizada.</p><p>Fonte: Elaborado pela autora.</p><p>E quais são as vantagens e desvantagens da estrutura organizacional projetizada?</p><p>tabela 6. Vantagens e desvantagens na estrutura projetizada.</p><p>Vantagens Desvantagens</p><p>Orientada a resultados Desenvolvimento de know-how limitado</p><p>Responsabilidades claras Perda de memória corporativa</p><p>Comunicação efetiva Instabilidade de emprego</p><p>Coordenação de tarefas multifuncionais facilitada Estrutura temporária</p><p>Identidade de projeto: motivação Funções e trabalhos duplicados</p><p>Alto poder de adaptabilidade Perda de uniformidade</p><p>Fonte: Elaborado pela autora.</p><p>Nos próximos tópicos será mostrada a estrutura matricial, que possui uma combinação</p><p>de características funcionais e projetizadas e que, ainda, pode ser classificada como</p><p>fraca, forte ou balanceada.</p><p>1.6.3 Estrutura matricial fraca</p><p>O gerente de projeto funciona como um coordenador ou facilitador. Um facilitador</p><p>atua como um assistente de equipe e coordenador de comunicações, ou seja, seu</p><p>poder de tomar decisões é limitado.</p><p>19</p><p>VISãO GERAL SOBRE GERÊnCIA DE PROJEtOS • CAPÍTULO 1</p><p>Figura 9. Exemplo de projeto em uma estrutura matricial fraca.</p><p>Fonte: Elaborado pela autora.</p><p>1.6.4 Estrutura matricial forte</p><p>Esta estrutura se assemelha à estrutura projetizada e possui gerente de projeto em</p><p>tempo integral com autoridade considerável. Entretanto, sua equipe é formada pelos</p><p>membros das unidades funcionais, que são destacados para atuar em determinado</p><p>projeto.</p><p>Figura 10. Exemplo de projeto em uma estrutura matricial forte.</p><p>Fonte: Elaborado pela autora.</p><p>20</p><p>CAPÍTULO 1 • VISãO GERAL SOBRE GERÊnCIA DE PROJEtOS</p><p>1.6.5 Estrutura matricial balanceada</p><p>Neste tipo estrutura organizacional, o gerente de projetos não tem autoridade total</p><p>sobre o projeto e sobre o financiamento do projeto. Sua equipe também é formada pelos</p><p>membros das unidades funcionais, que são destacados para atuar em determinado</p><p>projeto.</p><p>Figura 11. Exemplo de projeto em uma estrutura balanceada.</p><p>Fonte: Elaborado pela autora.</p><p>A partir das características de cada estrutura organizacional apresentada anteriormente,</p><p>é possível estabelecer uma relação entre essas estruturas organizacionais e as</p><p>características do projeto, como mostra o quadro a seguir.</p><p>Quadro 1. Influência das estruturas organizacionais nos projetos.</p><p>Estrutura da</p><p>Organização/</p><p>Características do</p><p>Projeto</p><p>Funcional</p><p>Matricial</p><p>Por projeto</p><p>Fraca Balanceada Forte</p><p>Autoridade do gerente</p><p>de projetos</p><p>Pouca ou</p><p>nenhuma</p><p>Limitada Baixa a moderada</p><p>Moderada a</p><p>alta</p><p>Alta a quase</p><p>total</p><p>Disponibilidade de</p><p>recursos</p><p>Pouca ou</p><p>nenhuma</p><p>Limitada Baixa a moderada</p><p>Moderada a</p><p>alta</p><p>Alta a quase</p><p>total</p><p>Quem controla o</p><p>orçamento do projeto</p><p>Gerente funcional</p><p>Gerente</p><p>funcional</p><p>Misto</p><p>Gerente de</p><p>projetos</p><p>Gerente de</p><p>projetos</p><p>Função do gerente de</p><p>projetos</p><p>tempo parcial tempo parcial tempo integral</p><p>tempo</p><p>integral</p><p>tempo integral</p><p>Equipe administrativa</p><p>do gerenciamento de</p><p>projetos</p><p>tempo parcial tempo parcial tempo integral</p><p>tempo</p><p>integral</p><p>tempo integral</p><p>Fonte: PMBOK (2013, p. 22).</p><p>21</p><p>VISãO GERAL SOBRE GERÊnCIA DE PROJEtOS • CAPÍTULO 1</p><p>Sintetizando</p><p>O que vimos neste Capítulo:</p><p>» Os projetos são o modus operandi para implementar a estratégia nas organizações.</p><p>» Projeto é um empreendimento temporário, que tem foco claro e que cria produtos ou serviços únicos e elaborados</p><p>progressivamente, enquanto operações são processos rotineiros, em que o mesmo processo é repetido várias vezes, bem</p><p>como o resultado.</p><p>» Um projeto possui ciclo de vida. O mais famoso é o PDCA (Plan-Do-Check-Act), ou seja, planejar (Plan), executar (Do),</p><p>avaliar (Check) e agir (Act).</p><p>» Para um projeto ter sucesso é preciso observar: prazos, custos, escopo e a qualidade do projeto final.</p><p>» O gerente de projetos é a pessoa alocada pela organização executora para liderar a equipe responsável por alcançar os</p><p>objetivos do projeto. Ele deve ter habilidades e competências, que lidam com liderança, motivação, conhecimentos</p><p>técnicos, entre outros.</p><p>» As estruturas organizacionais dizem respeito à forma com que a equipe de um projeto pode ser organizada dentro da</p><p>empresa.</p><p>» Estruturas organizacionais: funcional ou hierárquica, projetizada e matricial (fraca, forte ou balanceada).</p><p>22</p><p>Introdução</p><p>Neste capítulo, será estudada a fase de iniciação do projeto, que é formada por</p><p>atividades responsáveis pela autorização formal para o início do projeto.</p><p>As principais metas desta fase são:</p><p>» Desenvolver o Termo de Abertura do Projeto.</p><p>» Identificar os stakeholders.</p><p>Também nesta etapa são, geralmente, definidos o Gerente de Projeto (GP) e os fatores</p><p>críticos de sucesso. Outra meta da iniciação do projeto é pôr o objetivo do projeto em</p><p>sintonia com as partes interessadas (stakeholders), dando-lhes a visibilidade sobre</p><p>o escopo do projeto.</p><p>Objetivos</p><p>» Compreender a elaboração do Termo de Abertura do Projeto (TAP).</p><p>» Identificar as partes interessadas ou stakeholders de um projeto.</p><p>2.1 Elaboração do termo de Abertura do Projeto (tAP)</p><p>O desenvolvimento do Termo de Abertura do Projeto (também chamado de Project</p><p>Charter) é o processo de geração de um documento que dá a autorização formal para</p><p>a existência de um projeto e permite ao gerente do projeto ter autoridade para usar</p><p>os recursos necessários para executá-lo.</p><p>É importante notar que o Termo de Abertura do Projeto não é um contrato, porque</p><p>não há pagamento ou qualquer tipo de promessa envolvendo pagamento. Assim, o</p><p>Termo de Abertura do Projeto:</p><p>2CAPÍTULO</p><p>O InÍCIO DO PROJEtO</p><p>23</p><p>O InÍCIO DO PROJEtO • CAPÍTULO 2</p><p>» define, em alto nível, o que é o projeto, por que ele será executado, quem são</p><p>os principais envolvidos, quais os resultados esperados e o que será entregue</p><p>(produtos e serviços).</p><p>» é usado como um marco formal do início do projeto.</p><p>» permite que todos os participantes tenham uma visão geral do que é o projeto</p><p>e seus objetivos.</p><p>» é um documento curto que pode ser alterado posteriormente, conforme a</p><p>evolução do entendimento do projeto.</p><p>» deve ser aprovado pelos principais stakeholders.</p><p>» deve ser confeccionado pelo gerente de projeto (GP), mas sua elaboração</p><p>representa um esforço conjunto, tanto da equipe do projeto quanto do cliente.</p><p>Não existe um padrão de documentação definido para o Termo de Abertura do Projeto.</p><p>Entretanto, devido à sua natureza, podemos destacar alguns tópicos que normalmente</p><p>fazem parte de um TAP:</p><p>» Visão Geral do Projeto</p><p>› Nome do Projeto</p><p>› Requisitos do Negócio: informações sobre os motivos do projeto ser executado.</p><p>Deve responder: que problema será resolvido? Que oportunidade ou necessidade</p><p>será tratada?</p><p>› Objetivos do Projeto: descreve, de forma objetiva, a expectativa sobre os resultados</p><p>do projeto. Os objetivos devem ser descritos de forma que, ao final do projeto, seja</p><p>possível avaliar de forma concreta se eles foram atingidos ou não.</p><p>› Escopo do Projeto: descreve os produtos e/ou serviços que serão gerados durante e</p><p>ao final do projeto. Descreve, também, o que não será gerado pelo projeto.</p><p>› Premissas do Projeto: descreve as premissas para fins de planejamento, ou seja,</p><p>tudo aquilo que precisa ser realizado para que o projeto tenha sucesso, mas não faz</p><p>parte do seu escopo.</p><p>› Restrições do Projeto: descreve as limitações associadas ao projeto. Podem ser</p><p>limitações tecnológicas, orçamentárias, de prazo, de recursos humanos, entre outras.</p><p>› Patrocinadores: lista de patrocinadores, ou seja, quem está financiando o projeto.</p><p>24</p><p>CAPÍTULO 2 • O InÍCIO DO PROJEtO</p><p>» Visão Geral da Abordagem do Projeto:</p><p>› Produtos/Serviços: lista de produtos e/ou serviços que serão gerados durante e ao</p><p>final do projeto.</p><p>› Estágios ou Atividades: definição das principais fases do ciclo de vida do projeto,</p><p>também chamadas de macroatividades do projeto.</p><p>› Cronograma: definição de um cronograma em alto nível com os principais marcos</p><p>do projeto (normalmente descrito com um diagrama de Gantt).</p><p>› Recursos do Projeto: definição dos recursos materiais necessários para a execução</p><p>do projeto (espaço físico, equipamentos, softwares etc.).</p><p>› Organização e Responsabilidades: definição dos principais envolvidos, detalhando</p><p>os papéis, habilidades e responsabilidades (tanto do lado do cliente quanto do lado</p><p>do fornecedor).</p><p>› Controle do Projeto: definição de como será realizado o acompanhamento do projeto.</p><p>› Riscos: lista de riscos associados ao projeto, com as respectivas ações para mitigá-los.</p><p>» Aprovação:</p><p>› Identifica os nomes e papéis dos principais stakeholders. As assinaturas dos envolvidos,</p><p>se necessária, devem ser coletadas aqui.</p><p>› O TAP é geralmente apresentado como aprovado em uma reunião comumente</p><p>chamada de reunião de kick-off, que formaliza o início do projeto.</p><p>Figura 12. Diagrama de Gantt.</p><p>Fonte: Elaborado pela autora.</p><p>25</p><p>O InÍCIO DO PROJEtO • CAPÍTULO 2</p><p>Para elaborar o TAP de forma adequada deve-se adotar a regra SMART:</p><p>» Specific (específico): deve ser redigido de forma clara, concisa e objetiva.</p><p>» Measurable (mensurável): os objetivos do projeto devem ser mensuráveis, ou</p><p>seja, possíveis de serem medidos por meio de um ou mais indicadores.</p><p>» Agreed (acordado): deve ser acordado com as partes interessadas (stakeholders).</p><p>» Realistic (realista): deve estar centrado na realidade, no que é possível de ser</p><p>feito considerando as premissas e as restrições existentes.</p><p>» Time Bound (limitado no tempo): deve ter um prazo determinado para sua</p><p>finalização.</p><p>É preciso ficar atento para evitar alguns erros comumente cometidos ao elaborar o</p><p>Termo de Abertura do Projeto. A seguir, é apresentada uma lista de alguns erros mais</p><p>comuns:</p><p>» Definir os objetivos do projeto com base nos produtos a serem gerados e não</p><p>com base nas necessidades e oportunidades do negócio.</p><p>» Não definir os objetivos de forma mensurável (quantitativa ou qualitativamente).</p><p>» Não definir os produtos e serviços que estão no escopo.</p><p>» Não definir os produtos e serviços que estão fora do escopo.</p><p>Note que o TAP prevê a definição das premissas e restrições do projeto. Porém, o que</p><p>seria uma premissa e uma restrição?</p><p>» De acordo com PMBOK (2013, p. 124): “Premissas são fatores que, para fins</p><p>de planejamento, são considerados verdadeiros, reais ou certos, sem prova ou</p><p>demonstração”.</p><p>» Segundo Mulcahy (2009), restrições são “Fatores que limitam as opções da equipe”.</p><p>O Apêndice A, no final deste capítulo, contém um exemplo de Termo de Abertura de</p><p>Projeto.</p><p>2.2 Identificação das partes interessadas (stakeholders)</p><p>A identificação das partes interessadas (stakeholders) de um projeto consiste em</p><p>identificar pessoas ou grupos de indivíduos ou organizações que estarão, em algum</p><p>momento, envolvidos no projeto e cujos interesses serão afetados de forma positiva</p><p>ou negativa pelos resultados do projeto.</p><p>26</p><p>CAPÍTULO 2 • O InÍCIO DO PROJEtO</p><p>Os principais stakeholders de um projeto são:</p><p>» O patrocinador.</p><p>» O cliente.</p><p>» Os usuários do produto ou serviço.</p><p>» Órgãos do governo.</p><p>» O gerente do projeto (GP).</p><p>» A empresa executora.</p><p>» A equipe do projeto.</p><p>Figura 13. Patrocinador (sponsor).</p><p>PATROCINADOR</p><p>Fonte: https://www.shutterstock.com/pt/image-photo/sponsor-businessman-on-blurred-abstract-</p><p>background-1174861192.</p><p>Figura 14. Cliente satisfeito.</p><p>Fonte: https://www.shutterstock.com/pt/image-photo/clients-hand-picked-happy-face-smile-1680384592.</p><p>27</p><p>O InÍCIO DO PROJEtO • CAPÍTULO 2</p><p>Figura 15. A equipe do projeto.</p><p>Fonte: https://www.shutterstock.com/pt/image-photo/asian-female-employee-tell-project-idea-1494203657.</p><p>Cada stakeholder de um projeto possui algum tipo de interesse</p><p>e tem, também, algo a</p><p>oferecer. Ao identificar os stakeholders, devemos também entender essas questões. A</p><p>tabela a seguir apresenta alguns stakeholders normalmente encontrados em projeto</p><p>de TI, quais seus interesses e o que eles têm a oferecer:</p><p>Tabela 7. Stakeholders, seus interesses e expertise.</p><p>Stakeholder Interesse Expertise</p><p>Patrocinador e</p><p>Cliente</p><p>Introduzir mudança com benefício</p><p>máximo</p><p>Estratégias de negócio, processos</p><p>de negócio e tendências</p><p>Usuário Introduzir mudanças com interrupção</p><p>mínima no dia a dia</p><p>Processo de negócio e processos</p><p>operacionais</p><p>Gerente de Projeto Completar o projeto dentro do prazo,</p><p>custo e com os recursos disponíveis Gerência de projeto</p><p>Analista Especificar os requisitos no prazo previsto técnicas e ferramentas de análise</p><p>e modelagem</p><p>Desenvolvedor Produzir um sistema tecnicamente</p><p>excelente</p><p>Métodos de projeto, tecnologias de</p><p>programação</p><p>Fonte: Elaborado pela autora.</p><p>28</p><p>CAPÍTULO 2 • O InÍCIO DO PROJEtO</p><p>Saiba mais</p><p>» O patrocinador do projeto, ou seja, aquele que apoia financeiramente o projeto, também é chamado de sponsor.</p><p>» Expertise significa competência ou qualidade de um especialista.</p><p>» Requisitos são demandas ou necessidades dos clientes.</p><p>Uma estratégia simples e eficaz para identificação de stakeholders consiste em aplicar</p><p>as perguntas a seguir:</p><p>» Quem financiará a construção do produto ou serviço?</p><p>» Quem fará uso do produto ou serviço?</p><p>» Quem será afetado pelo produto ou serviço?</p><p>» Quem fiscalizará ou controlará o uso do produto ou serviço?</p><p>» Quem construirá o produto ou serviço?</p><p>Exemplos de projetos e seus stakeholders:</p><p>tabela 8. Projetos e seus stakeholders.</p><p>Projeto Stakeholders</p><p>Construção de um prédio</p><p>Incorporadora (provavelmente será o patrocinador).</p><p>Arquiteto (responsável pelo projeto do prédio).</p><p>Engenheiro civil (responsável pela obra, será o gerente do projeto).</p><p>Equipe de construção: pedreiros, carpinteiros, eletricistas, pintores etc.</p><p>Prefeitura (responsável pela liberação da obra e fiscalização).</p><p>Bombeiros (responsáveis pela liberação da ocupação do prédio).</p><p>Empresas de fornecimento de energia elétrica, água e gás encanado</p><p>(responsáveis pela definição dos padrões técnicos para instalação desses</p><p>serviços).</p><p>Desenvolvimento de um sistema de</p><p>venda para uma loja de autopeças</p><p>Dono da loja (provavelmente será o patrocinador).</p><p>Gerente da loja (usuário).</p><p>Vendedores (usuários).</p><p>Gerente do projeto.</p><p>Analistas de sistemas.</p><p>Web designers.</p><p>Programadores.</p><p>Fonte: Elaborado pela autora.</p><p>29</p><p>O InÍCIO DO PROJEtO • CAPÍTULO 2</p><p>Gotas de conhecimento</p><p>Projeto: Atualização do website www.bomdespachomg.com.br.</p><p>Data da última atualização: 7/1/2008</p><p>Ciclo do Projeto: Atualização – 1ª fase</p><p>Equipe: local</p><p>Responsável: TBD (to be defined)</p><p>Quadro 2. Project Charter.</p><p>Título do projeto Data de início N.</p><p>Atualização do website www.bomdespachomg.com.br 3/1/2008 001/2008</p><p>Patrocinador</p><p>Empresas apoiadoras</p><p>1 – Resumo do Projeto</p><p>O website www.bomdespachomg.com.br existe na internet desde 2002. É necessária sua atualização constante. Este</p><p>projeto será o marco inicial desses trabalhos, a cultura e história de Bom Despacho/MG é uma das mais variadas do</p><p>Estado, o que torna o universo de pesquisa bastante amplo.</p><p>2 – Objetivo do Projeto</p><p>» Levantamento de fotos antigas.</p><p>» Levantamento de publicações (revistas, jornais, livros, entrevistas) de textos históricos.</p><p>» Envolver a comunidade como um todo na elaboração do website.</p><p>» Divulgação do website para a comunidade.</p><p>3 – Demanda</p><p>O atual trabalho que se encontra no website www.bomdespachomg.com.br está desatualizado e necessita receber</p><p>novas informações, complementar outras existentes, ampliar assuntos ainda não pesquisados.</p><p>4 – O que é escopo</p><p>» Pesquisa de imagens, fotos, figuras.</p><p>» Pesquisa de textos (entrevistas, livros, revistas, jornais).</p><p>» Digitalização do material pesquisado.</p><p>» Divulgação do website para a comunidade.</p><p>» Estabelecimento de parcerias.</p><p>5 – O que não é escopo do Projeto</p><p>» Atualização do website.</p><p>» Pesquisa e publicação de tudo o que for encontrado nas fontes de publicações e imagens.</p><p>6 – Interessados (Stakeholders)</p><p>» Comunidade em geral.</p><p>» Paróquias.</p><p>» Historiadores.</p><p>» Professores.</p><p>» Biblioteca.</p><p>» Prefeitura.</p><p>» Instituições sociais de Bom Despacho.</p><p>» Líderes comunitários.</p><p>7 – Interfaces com projetos existentes</p><p>» Em 2004 foram catalogados os artesãos da ARtEBOM.</p><p>» Em 2006 foram estreitados laços com o Museu da Cidade e com a D. Sebastiana da tabatinga.</p><p>30</p><p>CAPÍTULO 2 • O InÍCIO DO PROJEtO</p><p>8 – Prazo estimado para a conclusão do Projeto</p><p>Um mês</p><p>9 – Orçamento estimado para a conclusão do Projeto</p><p>R$ 600,00</p><p>10 – Equipe básica</p><p>» Orientador: Jacinto Guerra.</p><p>» Coordenador: Ítalo Coutinho.</p><p>» Estagiária: Beatriz Amaral.</p><p>11 – Restrições</p><p>» As pesquisas ficarão restritas aos interesses do tutor.</p><p>» O prazo é uma restrição, bem como o custo.</p><p>12 – Premissas</p><p>» Fontes de pesquisas disponíveis.</p><p>» Recursos financeiros disponíveis.</p><p>13 – Gerente do Projeto</p><p>» Trabalharemos no esquema de tutoria.</p><p>Fonte: Elaborado pela autora.</p><p>Sintetizando</p><p>O que vimos neste Capítulo:</p><p>» O Termo de Abertura do Projeto (TAP) formaliza o início do projeto e permite que todos os participantes tenham uma</p><p>visão geral do que é o projeto e seus objetivos.</p><p>» O TAP pode conter: o nome do projeto, os requisitos do negócio, os objetivos do projeto, o escopo do projeto, as premissas</p><p>e restrições do projeto, os patrocinadores (sponsors), os nomes e os papéis dos principais stakeholders.</p><p>» Para se definir o objetivo do projeto usa-se a regra SMART, que significa que o objetivo deve ser específico, mensurável,</p><p>acordado, realista e limitado no tempo, ou seja, specific, measurable, agreed, realistic e time bound.</p><p>» A identificação das partes interessadas em um projeto, ou stakeholders, consiste em identificar pessoas ou grupos de</p><p>indivíduos ou organizações que estarão, em algum momento, envolvidos no projeto e cujos interesses serão afetados</p><p>positiva ou negativamente pelos resultados do projeto.</p><p>» Os principais stakeholders de um projeto são:</p><p>› O patrocinador.</p><p>› O cliente.</p><p>› Os usuários do produto ou serviço.</p><p>› Órgãos do governo.</p><p>› O gerente do projeto (GP).</p><p>› A empresa executora.</p><p>› A equipe do projeto.</p><p>31</p><p>Introdução</p><p>Neste capítulo, será estudada a fase de planejamento do projeto, que é composta por</p><p>atividades responsáveis pelo desenvolvimento do Plano de Gerenciamento do Projeto</p><p>(PGP) e pela criação dos documentos do projeto que serão usados para executá-lo.</p><p>À medida que surgem mais dados relacionados ao projeto e suas características</p><p>vão sendo mais bem definidas, pode ser necessário um planejamento adicional ou,</p><p>ainda, revisar o planejamento feito anteriormente. Esse detalhamento progressivo</p><p>do plano de gerenciamento do projeto é conhecido como “planejamento por ondas</p><p>sucessivas”, pois tanto o planejamento quanto a documentação evoluem de forma</p><p>contínua e iterativa.</p><p>O Plano de Gerenciamento do Projeto define como o projeto será executado, monitorado,</p><p>controlado e finalizado, além de integrar os demais planos do projeto, como o plano</p><p>de custos, plano de qualidade e plano de riscos, entre outros.</p><p>Assim como o Termo de Abertura do Projeto, também não existe um padrão de</p><p>documentação definido para o PGP. Na realidade, o PGP é, muitas vezes, formado por</p><p>um conjunto de documentos. Entretanto, independentemente do padrão adotado, o</p><p>PGP deve ser composto de planos menores e mais focados:</p><p>» Plano de Gerenciamento do Escopo.</p><p>» Plano de Gerenciamento do Tempo.</p><p>» Plano de Gerenciamento do Custo.</p><p>» Plano de Gerenciamento da Qualidade.</p><p>» Plano de Gerenciamento de Riscos.</p><p>Assim, para entender o planejamento de um projeto é imprescindível entender o</p><p>planejamento de cada uma de suas partes.</p><p>3CAPÍTULO</p><p>O PLAnEJAMEntO DO PROJEtO</p><p>32</p><p>CAPÍTULO 3 • O PLAnEJAMEntO DO PROJEtO</p><p>Objetivos</p><p>» Compreender as principais atividades do Plano de Gerenciamento do Escopo.</p><p>» Compreender as principais</p><p>atividades do Plano de Gerenciamento do Tempo.</p><p>» Compreender as principais atividades do Plano de Gerenciamento do Custo.</p><p>» Compreender as principais atividades do Plano de Gerenciamento da Qualidade.</p><p>» Compreender as principais atividades do Plano de Gerenciamento de Riscos.</p><p>3.1 Plano de gerenciamento do escopo</p><p>Para entender o que é o plano de gerenciamento do escopo é preciso entender,</p><p>inicialmente, o que é o escopo de um projeto e a sua importância para o sucesso do</p><p>projeto.</p><p>Vimos anteriormente que o escopo do projeto descreve os produtos ou serviços que</p><p>serão gerados ao final do projeto. O escopo também descreve o que não será gerado</p><p>pelo projeto. Assim, é possível afirmar que o escopo é a definição clara e objetiva dos</p><p>produtos ou serviços que serão entregues ao final do projeto e nada mais será entregue</p><p>além do escopo. Logo, em projetos com escopo mal definido não é possível saber de</p><p>forma precisa que características terão os produtos ou serviços criados pelo projeto.</p><p>E essa imprecisão abre brechas para que o escopo seja mudado constantemente,</p><p>fugindo dos objetivos iniciais e levando a estouros de prazos e orçamentos.</p><p>Assim, é preciso ter um cuidado especial com o escopo do projeto. O plano de</p><p>gerenciamento do escopo é um componente do PGP que descreve como o escopo do</p><p>projeto será definido, validado e controlado.</p><p>» Definição: está relacionada à coleta de informações e elaboração de um ou mais</p><p>documentos que descrevem o escopo.</p><p>» Validação: está relacionada à avaliação dos documentos gerados pelo cliente, ou</p><p>seja, o cliente avalia os documentos previamente elaborados e verifica se eles</p><p>estão em conformidade com as suas necessidades.</p><p>» Controle: está relacionado com o controle das alterações do escopo durante a</p><p>execução do projeto. (Este item será abordado com mais detalhes no Capítulo 5).</p><p>A etapa mais crítica relacionada ao escopo do projeto é sua definição. É possível</p><p>dividi-la em três partes:</p><p>33</p><p>O PLAnEJAMEntO DO PROJEtO • CAPÍTULO 3</p><p>» Coleta dos requisitos.</p><p>» Definição do escopo.</p><p>» Criação da Estrutura Analítica do Projeto (EAP).</p><p>3.1.1 Coleta dos requisitos</p><p>A coleta de requisitos é responsável por definir, detalhar e documentar as necessidades</p><p>e expectativas dos stakeholders e as características dos produtos ou serviços que irão</p><p>satisfazer a essas necessidades e expectativas.</p><p>Atente para o diálogo a seguir:</p><p>Cliente: “Este relatório não está do jeito que eu pedi!”</p><p>Analista: “Está sim, foi o que você definiu para mim naquele e-mail. Eu</p><p>retornei sua requisição explicando quais campos seriam os campos mestre,</p><p>quais seriam os campos detalhe e como as totalizações seriam feitas.”</p><p>Cliente: “Não adianta falar essa linguagem comigo, eu não sou Bill Gates.</p><p>E quem vai fazer o cadastro dos 5.000 itens do meu estoque?”</p><p>Analista: “O sistema foi entregue para você de forma operacional. Vocês</p><p>vão fazer o cadastro.”</p><p>Cliente: “O quê? Você vai me entregar o sistema vazio? E quanto ao controle</p><p>de férias dos funcionários que eu não achei onde estava no menu?”</p><p>Analista: “Mas pensei que tivesse ficado claro que isso não estaria nesta</p><p>versão do sistema!”</p><p>[...]continua indefinidamente ou até o primeiro enfartar.</p><p>Quem está certo nessa discussão? Provavelmente, os dois ou nenhum dos dois. Esse é</p><p>um exemplo de problema de escopo! Pode ser que os requisitos do sistema não foram</p><p>coletados adequadamente.</p><p>Identificar, entender e documentar os requisitos são pontos essenciais para o sucesso</p><p>do projeto. A execução inadequada dessa tarefa pode trazer grande impacto sobre</p><p>o desenvolvimento do produto, porque impacta no custo e prazo do projeto e na</p><p>qualidade do produto. Em casos extremos, a coleta equivocada de requisitos pode</p><p>ocasionar até mesmo o cancelamento do projeto.</p><p>34</p><p>CAPÍTULO 3 • O PLAnEJAMEntO DO PROJEtO</p><p>Do ponto de vista de um produto, um requisito pode ser definido como:</p><p>Uma característica do produto ou a descrição de algo que ele é capaz de realizar, para</p><p>atingir os seus objetivos.</p><p>Então, como podemos coletar os requisitos dos clientes? Há vários métodos para</p><p>coleta de requisitos:</p><p>» Entrevista: é sempre individual (não existe entrevista com dois ou três</p><p>entrevistados) e deve ter as perguntas preparadas com antecedência.</p><p>» Reunião: é formal, reúne várias pessoas e deve sempre ser conduzida de acordo</p><p>com uma pauta, ou seja, pontos a serem discutidos e resolvidos na reunião.</p><p>» Brainstorming: reúne várias pessoas e é usado para gerar e coletar múltiplas</p><p>ideias relacionadas ao produto ou serviço.</p><p>» Prototipagem: consiste em construir um protótipo funcional do produto esperado,</p><p>antes de realmente construí-lo. (PMBOK, 2013, p. 116)</p><p>» Análise de documentação/conteúdo: usada para extrair requisitos por meio</p><p>da análise da documentação já existente. Essa documentação geralmente é</p><p>composta de especificações ou manuais de produtos anteriores, documentos</p><p>legais e fiscais que contêm regras a serem observadas, entre outros.</p><p>Saiba mais</p><p>Coleta de requisitos também é chamada de levantamento, identificação ou elicitação de requisitos.</p><p>Ao final dessa fase, os requisitos coletados estarão descritos de forma detalhada em</p><p>um documento chamado “Especificação de Requisitos”. Dessa forma, a especificação</p><p>de requisitos detalha as características dos produtos ou serviços a serem entregues</p><p>ao final do projeto.</p><p>3.1.2 Definição do escopo</p><p>A partir do documento de Especificação de Requisitos, obtido na atividade anterior,</p><p>é possível criar a Declaração de Escopo, que detalha as entregas do projeto (produtos</p><p>e/ou serviços) e as atividades necessárias para criar essas entregas. Assim, a definição</p><p>do escopo detalha os limites do projeto, ou seja, características que o produto ou</p><p>serviço terá ou não terá, e atividades que serão e não serão executadas.</p><p>35</p><p>O PLAnEJAMEntO DO PROJEtO • CAPÍTULO 3</p><p>Atenção</p><p>Não confundir escopo do produto com escopo do projeto:</p><p>» Escopo do Produto: são as características do produto ou serviço que se espera como resultado do projeto (O QUÊ vai ser</p><p>construído). Está descrito no documento de Especificação de Requisitos.</p><p>» Escopo do Projeto: define as atividades e os recursos necessários para que sejam entregues os produtos/serviços conforme</p><p>especificado (COMO vai ser construído). Está descrito na Declaração de Escopo.</p><p>Exemplo: Considere o desenvolvimento de um sistema para gerenciamento de um</p><p>consultório médico. Qual é o escopo do produto e o escopo do projeto?</p><p>» Escopo do Produto: um sistema, em Java, com funcionalidades para manter o</p><p>cadastro de pacientes e planos de saúde, consultar pacientes e suas fichas médicas,</p><p>atualizar ficha médica e agendar consultas. O sistema não terá funcionalidades</p><p>para impressão de receitas médicas, apenas o envio da receita para o e-mail do</p><p>paciente.</p><p>» Escopo do Projeto: para desenvolver o sistema, serão necessários um programador</p><p>pleno, um analista e um designer. O cronograma contará com atividades de</p><p>especificação, aprovação, projeto, construção, testes, homologação e instalação</p><p>e terá duração de três meses. Não estão previstas atividades de treinamento dos</p><p>funcionários do consultório.</p><p>A Declaração do Escopo deve conter:</p><p>» Objetivo do Projeto: contém descrição objetiva do projeto e critérios mensuráveis</p><p>que definem o seu sucesso, como metas de custo, prazo e qualidade, entre outros.</p><p>› Quais resultados o projeto pretende alcançar?</p><p>› Como o sucesso do projeto será objetivamente avaliado?</p><p>» Escopo do Projeto: descreve o trabalho necessário para que sejam entregues os</p><p>produtos ou serviços especificados.</p><p>› Qual trabalho será feito?</p><p>› Que atividades ou tarefas serão necessárias?</p><p>» Entregas do Projeto: descrição dos produtos e serviços a serem entregues,</p><p>destacando o que não será entregue.</p><p>› O que o cliente receberá ao final do projeto?</p><p>› O que o cliente não receberá ao final do projeto?</p><p>36</p><p>CAPÍTULO 3 • O PLAnEJAMEntO DO PROJEtO</p><p>» Escopo do produto: descreve as características funcionais e não funcionais do</p><p>produto,</p><p>destacando o que será e o que não será entregue. É normal que essas</p><p>descrições se tornem mais detalhadas com o andamento do projeto. Deve fornecer</p><p>detalhes suficientes para os processos de planejamento posteriores.</p><p>› O que está contido no produto/serviço?</p><p>› Quais os requisitos e características do produto?</p><p>› O que será excluído?</p><p>» Premissas: descrever as condições que serão consideradas verdadeiras e que</p><p>são relevantes para o sucesso do projeto.</p><p>› Quais as pré-condições assumidas para o projeto?</p><p>› O que deverá ser feito para que o projeto tenha sucesso e que não está sob sua</p><p>responsabilidade?</p><p>» Restrições: descrever as restrições relacionadas ao escopo e que limitam as</p><p>opções da equipe.</p><p>› Existem limitações de prazo, custo, recursos humanos, condições de trabalho ou</p><p>outras que devem ser obedecidas?</p><p>» Organização do Projeto: são identificados os membros das equipes e os</p><p>stakeholders, seus papéis e responsabilidades.</p><p>› Qual vai ser a organização da equipe?</p><p>› Qual o perfil dos membros da equipe?</p><p>› Qual a responsabilidade de cada um dos membros da equipe?</p><p>» Abordagem do Projeto: define as fases do projeto (ciclo de vida).</p><p>› Quais as principais atividades que irão compor o ciclo de vida?</p><p>» Marcos do Cronograma: define o prazo dos marcos principais do cronograma.</p><p>› Quais os prazos relacionados às principais entregas?</p><p>3.1.3 Criação da Estrutura Analítica do Projeto (EAP)</p><p>Após a definição do escopo do projeto, surgem algumas perguntas: como detalhar</p><p>as atividades a serem executadas no projeto? Como definir quais atividades serão</p><p>realmente necessárias para construir o produto ou serviço?</p><p>Para responder a essas perguntas é preciso criar a Estrutura Analítica do Projeto</p><p>(EAP), também conhecida como Work Breakdown Structure ( WBS). O objetivo da EAP</p><p>37</p><p>O PLAnEJAMEntO DO PROJEtO • CAPÍTULO 3</p><p>é dividir o projeto em unidades de trabalho menores, menos complexas e, portanto,</p><p>mais gerenciáveis.</p><p>A criação da EAP é fundamental para o projeto, pois fornece uma visão estruturada</p><p>do que será entregue, facilitando o entendimento dos stakeholders em relação ao que</p><p>deve ser feito no projeto. Por esta razão, a EAP organiza, define e delimita o escopo</p><p>total do projeto.</p><p>A EAP pode ser definida como uma decomposição hierárquica das entregas e do trabalho</p><p>a ser executado pela equipe do projeto, ou seja, cada nível descendente representa</p><p>uma definição mais detalhada das entregas e do trabalho a ser realizado no projeto.</p><p>As unidades de nível mais baixo, que são as unidades básicas de monitoramento e</p><p>controle do projeto, são chamadas de pacotes de trabalho, e é sobre essas unidades</p><p>que são gerados o cronograma e as estimativas de prazo, recursos e custo.</p><p>Atenção</p><p>A EAP não define a ordem de execução das tarefas nem da entrega dos produtos ou serviços.</p><p>Não existe um padrão para definição da EAP; contudo, duas estratégias são comumente</p><p>adotadas:</p><p>» Visão de tarefas: quebrar o projeto em fases (e estas em subfases, se for o caso)</p><p>e definir os produtos de cada fase ou subfase e as tarefas para criação desses</p><p>produtos.</p><p>Figura 16. Visão de tarefas.</p><p>Fonte: Elaborado pela autora.</p><p>38</p><p>CAPÍTULO 3 • O PLAnEJAMEntO DO PROJEtO</p><p>» Visão de entrega: quebrar o projeto em produtos (e estes em subprodutos, se for</p><p>o caso) e, por fim, definir as tarefas para criação desses produtos ou subprodutos.</p><p>Figura 17. Visão por entrega.</p><p>Fonte: Elaborado pela autora.</p><p>Atenção</p><p>É possível ter mais de um nível de fases, bem como ter mais de um nível de produtos.</p><p>A construção de uma EAP envolve as seguintes atividades:</p><p>» Identifique as entregas e as tarefas relacionadas a elas usando a declaração de</p><p>escopo.</p><p>» Decomponha cada elemento nas partes que o compõem (visão de entrega) ou</p><p>nas tarefas necessárias para construí-lo (visão de tarefa).</p><p>» Verifique se os novos componentes gerados são necessários e suficientes para</p><p>representar/criar o componente de maior nível. Isso é importante para manter</p><p>a consistência.</p><p>» Proceda com a decomposição até a geração de pacotes de trabalho que possam</p><p>ser associados a alguma entidade responsável pela sua criação/execução e que</p><p>possam ter seu custo e prazo estimados adequadamente.</p><p>39</p><p>O PLAnEJAMEntO DO PROJEtO • CAPÍTULO 3</p><p>Saiba mais</p><p>O nível mais baixo da EAP é chamado de pacote de trabalho.</p><p>Exemplo 1: EAP organizada por Fases</p><p>Observe que no primeiro nível foram definidas as fases do projeto: Preparação,</p><p>Pintura e Finalização. Em seguida, as fases 1 e 3 foram quebradas em duas grandes</p><p>atividades cada uma. Por fim, no último nível foram definidos os pacotes de trabalho,</p><p>ou seja, tarefas elementares que que estão associadas a um responsável e que possuem</p><p>um prazo bem definido para serem executadas. Além disso, note que foram usados</p><p>substantivos para descrever as fases do projeto e verbos (que denotam ações) para</p><p>descrever as atividades e pacotes de trabalho.</p><p>Figura 18. Exemplo de EAP organizada em fases.</p><p>Fonte: Elaborado pela autora.</p><p>Exemplo 2: EAP organizada por Entregas</p><p>Nesse segundo exemplo, o primeiro nível representa as grandes entregas do projeto</p><p>(Paisagismo, Escavação, Concretagem, Acabamento e Encanamento), ou seja, o produto</p><p>ou serviço que será criado pelas atividades e tarefas subordinadas a ele. Note que a</p><p>40</p><p>CAPÍTULO 3 • O PLAnEJAMEntO DO PROJEtO</p><p>ordem em que as entregas são definidas não representa o momento no tempo em que</p><p>elas serão entregues.</p><p>Figura 19. EAP organizada por entrega.</p><p>Fonte: Elaborado pela autora.</p><p>Exemplo 3: EAP com problemas organizada por Fases</p><p>Nesse exemplo, o primeiro nível também representa as fases do projeto: Gerenciamento,</p><p>Levantamento, Desenvolvimento e Transição. Diferentemente dos exemplos anteriores,</p><p>a fase de Levantamento define uma entrega (Protótipo) que possui duas tarefas:</p><p>Desenvolver e Aprovar. Assim, esse exemplo mostra que, em meio a um conjunto de</p><p>tarefas, é possível definir uma entrega e as tarefas associadas a ela (a EAP define que</p><p>durante o Levantamento será criado um Protótipo). Por outro lado, essa EAP apresenta</p><p>alguns problemas:</p><p>» Algumas tarefas de último nível não representam pacotes de trabalho: por</p><p>exemplo, a tarefa “Coletar Requisitos” não representa uma tarefa elementar.</p><p>Ela deveria ser desmembrada em subtarefas que representam os verdadeiros</p><p>pacotes de trabalho.</p><p>» Algumas entregas não definem as tarefas associadas a ela: por exemplo, a</p><p>entrega Treinamento não define o que precisa ser feito para que o treinamento</p><p>seja efetivamente realizado. Provavelmente estão faltando pacotes de trabalho</p><p>como “Elaborar material de treinamento”, “Revisar material de treinamento” e</p><p>“Realizar o treinamento”.</p><p>» Alguns pacotes de trabalho não descrevem a ação a ser executada: por exemplo,</p><p>a tarefa “Publicação do site” deveria ser renomeada para “Publicar site”.</p><p>41</p><p>O PLAnEJAMEntO DO PROJEtO • CAPÍTULO 3</p><p>Figura 20. EAP com problemas organizada por fases.</p><p>Fonte: Elaborado pela autora.</p><p>Pontos importantes na construção de uma EAP:</p><p>» A EAP deve representar 100% do escopo do projeto.</p><p>» O que não está na EAP não faz parte do escopo do projeto.</p><p>» A EAP é um mapa de tudo que será feito para ter os produtos ou serviços finais</p><p>do projeto.</p><p>» A EAP não define a sequência em que os produtos serão criados nem a sequência</p><p>em que as tarefas serão executadas, ou seja, a ordem em que os pacotes de</p><p>trabalho aparecem não é relevante.</p><p>» O momento em que devemos parar de quebrar a estrutura varia de acordo com</p><p>o tipo de projeto e o tipo de gerenciamento desejado. Entretanto, algumas regras</p><p>podem ajudar:</p><p>› Regra 8-40: os pacotes de trabalho devem estar entre 8 e 40 horas.</p><p>› Regra 8-80: os pacotes de trabalho devem estar entre 8 e 80 horas.</p><p>› Nenhum pacote de trabalho deve ter menos de 24 horas.</p><p>» A definição da regra mais adequada para determinado projeto só é atingida com</p><p>a prática. Entretanto, a ideia principal é ter sempre pacotes gerenciáveis, mas</p><p>cujo custo de gerenciamento não seja maior que o custo do próprio pacote.</p><p>42</p><p>CAPÍTULO 3 •</p><p>O PLAnEJAMEntO DO PROJEtO</p><p>» Intuitivamente, nós estamos inclinados a gerar uma EAP orientada a tarefas,</p><p>porque é mais fácil e porque existe uma tendência de enxergar um projeto como</p><p>uma coleção de tarefas.</p><p>» Geralmente levamos mais tempo gerando uma EAP orientada a entregas, pois</p><p>ela possui maior nível de detalhes.</p><p>» O importante é não perder o foco e identificar na EAP as entregas a serem</p><p>realizadas:</p><p>› Se o pacote de trabalho é definido como um verbo, então ele representa uma tarefa.</p><p>› Se o pacote de trabalho é definido como um substantivo, então ele é uma entrega.</p><p>» Como a EAP representa 100% do escopo do projeto, alterações posteriores na</p><p>EAP devem ser inicialmente encaradas como uma alteração de escopo.</p><p>3.1.4 Validação do escopo</p><p>Após a definição do escopo por meio da coleta dos requisitos, criação da declaração</p><p>de escopo e da EAP, é necessário que esses elementos sejam validados, ou seja, que</p><p>eles sejam avaliados formalmente para verificar a sua viabilidade e adequação às</p><p>necessidades do cliente. Assim, é imprescindível que o cliente participe do processo</p><p>de validação, pois ele deverá dar o aceite formal (por e-mail, assinatura ou outro</p><p>meio) em todo esse material, de forma a explicitar a sua concordância com o que foi</p><p>definido no escopo.</p><p>Atenção</p><p>Pontos de atenção na elaboração do Plano de Gerenciamento do Escopo:</p><p>» Seja específico e claro com relação ao resultado esperado (entregas).</p><p>» Deixe claro o que o projeto não vai entregar.</p><p>» Mantenha o foco nos objetivos do projeto.</p><p>» Ouça todos os stakeholders.</p><p>» Pense nos detalhes, mas não se fixe nos detalhes.</p><p>» Atente-se para as restrições.</p><p>3.2 Plano de gerenciamento do tempo</p><p>O plano de gerenciamento do tempo lida com a questão da definição do tempo</p><p>necessário para execução das tarefas, e tempo é o único recurso que não pode ser</p><p>43</p><p>O PLAnEJAMEntO DO PROJEtO • CAPÍTULO 3</p><p>reposto, por mais dinheiro que se desembolse. Mesmo em projetos com pouca ou</p><p>nenhuma restrição de tempo, a falta de gerenciamento desse recurso afetará outras</p><p>partes do projeto como o custo, a qualidade e a satisfação do cliente.</p><p>O principal elemento desse plano é o cronograma do projeto e a criação do cronograma</p><p>envolve quatro atividades:</p><p>» Definir as atividades do projeto.</p><p>» Sequenciar as atividades do projeto.</p><p>» Estimar os recursos da atividade.</p><p>» Estimar a duração da atividade.</p><p>Entretanto, é importante ressaltar que essa divisão em quatro atividades é apenas</p><p>didática, ou seja, para facilitar o entendimento de como o cronograma deve ser</p><p>construído. Na prática, muitas vezes, executamos as quatro atividades em paralelo.</p><p>3.2.1 Definição das atividades</p><p>Este processo é responsável pela definição das atividades que produzirão o que está</p><p>especificado na EAP. Assim, uma falha bastante comum na criação do cronograma é não</p><p>atentar para o que está descrito na EAP e definir atividades que não estão associadas</p><p>ao que deverá ser entregue ou não detalhar suficientemente as atividades necessárias</p><p>para construir o que deverá ser entregue.</p><p>Atenção</p><p>Lembre-se de que a EAP representa o que faz parte e o que não faz parte do escopo do projeto.</p><p>A definição das atividades normalmente acontece usando uma ou algumas de quatro</p><p>técnicas:</p><p>» Decomposição: essa é a técnica mais comum e nela o projeto é decomposto</p><p>em pacotes de trabalho e, posteriormente, em atividades. Se a EAP foi criada</p><p>de acordo com as boas práticas, os pacotes de trabalho podem ser extraídos</p><p>diretamente dela.</p><p>» Planejamento por ondas sucessivas: a lista de atividades é elaborada de forma</p><p>progressiva, ou seja, as atividades iniciais ficam bastante detalhadas, enquanto as</p><p>atividades intermediárias e finais ficam menos detalhadas. Conforme o projeto vai</p><p>sendo executado, as atividades vão sendo detalhadas antes de serem executadas.</p><p>44</p><p>CAPÍTULO 3 • O PLAnEJAMEntO DO PROJEtO</p><p>» Templates: uma lista-padrão de atividades é usada como ponto de partida e</p><p>adaptada para a situação específica de um projeto. Templates são bastante úteis</p><p>quando o perfil dos projetos é semelhante, pois, nesse caso, existe uma forte</p><p>tendência de executar as mesmas atividades já executadas anteriormente no</p><p>outro projeto.</p><p>» Julgamento de especialistas: membros da equipe com mais experiência no</p><p>domínio do problema e/ou na tecnologia adotada para a solução ajudam a</p><p>definir as atividades necessárias</p><p>Note que, apesar de a Decomposição ser a técnica mais comumente adotada, em</p><p>situações reais é comum a adoção de várias dessas técnicas em conjunto.</p><p>3.2.2 Sequenciamento das atividades</p><p>Uma vez definidas as atividades necessárias, é preciso definir a sequência na qual</p><p>essas atividades serão executadas. Dependendo da natureza de cada atividade, duas</p><p>atividades podem ser executadas em paralelo ou uma após a outra, por exemplo.</p><p>O método mais comum para modelar o relacionamento entre as atividades é o Método</p><p>do Diagrama de Precedência (MDP). Tal método é implementado na grande maioria</p><p>das ferramentas para criação e controle de cronogramas de projeto, como o Microsoft</p><p>Project.</p><p>O MDP inclui quatro tipos de relacionamento entre duas atividades, mas, na prática,</p><p>somente três são usados. Conforme dissemos anteriormente, a natureza de cada</p><p>atividade é que irá determinar o tipo de relacionamento entre elas.</p><p>» Início-Início: as atividades sucessora e predecessora começam na mesma data</p><p>independentemente da duração de cada uma (a duração é representada pelo</p><p>comprimento das barras). Graficamente, a seta ligando o início da Atividade 1</p><p>no início da Atividade 2 representa que ambas começam na mesma data.</p><p>Figura 21. Relacionamento início-fim.</p><p>Fonte: Elaborado pela autora.</p><p>É importante notar que as Atividades 1 e 2 vão ser executadas em paralelo durante</p><p>algum tempo. Nesse caso, é comum alocar pessoas diferentes para executar cada uma</p><p>45</p><p>O PLAnEJAMEntO DO PROJEtO • CAPÍTULO 3</p><p>delas. Caso as duas atividades sejam executadas pela mesma pessoa, então ela vai ter</p><p>que trabalhar parte do seu dia na Atividade 1 e outra parte na Atividade 2.</p><p>Exemplo 1a: a criação do modelo Entidades-Relacionamentos vai iniciar juntamente</p><p>com a elaboração do protótipo da interface com o usuário, sendo que essa segunda</p><p>atividade vai levar mais tempo.</p><p>Figura 22. Exemplo de relacionamento início-início.</p><p>Fonte: Elaborado pela autora.</p><p>Exemplo 1b: a implementação do cadastro de clientes e dos relatórios de pedidos e</p><p>de produtos vai ter início na mesma data, apesar de terem durações diferentes.</p><p>Figura 23. Exemplo de relacionamento início-início.</p><p>Fonte: Elaborado pela autora.</p><p>» Fim-Início: a atividade sucessora se inicia somente quando a predecessora</p><p>termina. Esse é o tipo mais comum de relacionamento e leva a um encadeamento</p><p>de duas ou mais atividades no tempo. Graficamente, a seta que liga o final da</p><p>Atividade 1 no início da Atividade 2 indica que a Atividade 2 se iniciará assim</p><p>que a Atividade 1 terminar.</p><p>Figura 24. Relacionamento fim-início.</p><p>Fonte: Elaborado pela autora.</p><p>46</p><p>CAPÍTULO 3 • O PLAnEJAMEntO DO PROJEtO</p><p>Exemplo 2a: a realização do treinamento só vai iniciar quando a preparação do material</p><p>de treinamento terminar, o que faz todo o sentido.</p><p>Figura 25. Exemplo de relacionamento fim-início.</p><p>Fonte: Elaborado pela autora.</p><p>Exemplo 2b: esse exemplo mistura o relacionamento início-início com o relacionamento</p><p>fim-início. A implementação do cadastro de pedidos iniciará juntamente com a</p><p>elaboração dos testes do cadastro. Entretanto, a atividade de teste do cadastro só</p><p>iniciará quando ambas as atividades terminarem.</p><p>Figura 26. Exemplo de relacionamento início-início e fim-início.</p><p>Fonte: Elaborado pela autora.</p><p>» Fim-Fim: as atividades sucessora e predecessora terminam na mesma data,</p><p>independentemente da duração de cada uma. Graficamente, a seta ligando o</p><p>fim da Atividade 1 no fim da Atividade 2 representa que ambas terminam na</p><p>mesma data.</p><p>Figura 27. Relacionamento fim-fim.</p><p>Fonte: Elaborado pela autora.</p><p>Exemplo 3: a codificação das funcionalidades, a elaboração dos testes</p><p>funcionais e a</p><p>preparação do ambiente de testes devem terminar na mesma data.</p><p>47</p><p>O PLAnEJAMEntO DO PROJEtO • CAPÍTULO 3</p><p>Figura 28. Exemplo de relacionamento fim-fim.</p><p>Fonte: Elaborado pela autora.</p><p>Também é possível atribuir atrasos ou antecipações a cada um desses relacionamentos.</p><p>» Fim-início com atraso ou adiantamento: são acrescentados dias que vão atrasar</p><p>ou adiantar o início da segunda Atividade 2.</p><p>Figura 29. Relacionamento fim-início com atraso de X dias.</p><p>Fonte: Elaborado pela autora.</p><p>Figura 30. Relacionamento fim-início com adiantamento de X dias.</p><p>Fonte: Elaborado pela autora.</p><p>48</p><p>CAPÍTULO 3 • O PLAnEJAMEntO DO PROJEtO</p><p>Exemplo 4a: relacionamento fim-início com adiantamento de X dias.</p><p>Figura 31. Exemplo de relacionamento fim-início com atraso de 5 dias.</p><p>Fonte: Elaborado pela autora.</p><p>Exemplo 4b: a criação do manual do usuário vai iniciar 15 dias antes de terminar a</p><p>codificação das funcionalidades.</p><p>Figura 32. Exemplo de relacionamento fim-início com adiantamento de 15 dias.</p><p>Fonte: Elaborado pela autora.</p><p>» Início-início com atraso ou adiantamento: são acrescentados dias que vão</p><p>atrasar ou adiantar o início da segunda Atividade 2.</p><p>Figura 33. Relacionamento início-início com atraso de X dias.</p><p>Fonte: Elaborado pela autora.</p><p>Figura 34. Relacionamento início-início com adiantamento de X dias.</p><p>Fonte: Elaborado pela autora.</p><p>49</p><p>O PLAnEJAMEntO DO PROJEtO • CAPÍTULO 3</p><p>Exemplo 5: a criação da especificação de requisitos vai iniciar 10 dias após o início</p><p>das reuniões de elicitação.</p><p>Figura 35. Exemplo de relacionamento início-início com atraso de 10 dias.</p><p>Fonte: Elaborado pela autora.</p><p>3.2.3 Estimativa dos recursos da atividade</p><p>Outra atividade essencial na elaboração de um cronograma é a estimativa de recursos.</p><p>Ela é responsável por definir quais recursos (pessoas, equipamentos, materiais etc.)</p><p>e suas respectivas quantidades serão necessários para a execução de cada atividade.</p><p>Do ponto de vista de recursos humanos, se não for possível determinar um recurso</p><p>com perfil adequado para realizar a atividade, então provavelmente ela deve ser</p><p>decomposta em outras atividades. É importante destacar, ainda, que uma atividade</p><p>pode ter mais de um recurso humano associado à sua execução, mas sempre deve ser</p><p>definido um único responsável pela sua execução.</p><p>Dependendo da natureza da atividade, podem ser adotadas algumas alternativas:</p><p>contratar um recurso temporário específico para essa atividade, subcontratar uma</p><p>empresa para realizar a atividade, alugar equipamentos necessários à atividade, alugar</p><p>salas para realização da atividade, entre outras possibilidades.</p><p>3.2.4 Estimativa da duração da atividade</p><p>Por fim, deve-se estimar a duração da atividade, isto é, quanto tempo essa atividade</p><p>vai levar para ser executada. Estimativas de duração não são fáceis de se obter e</p><p>existe uma forte tendência, principalmente nos profissionais menos experientes, de</p><p>subestimar a duração de uma atividade.</p><p>Existem várias técnicas de estimativa. A tabela a seguir apresenta algumas técnicas</p><p>comumente adotadas e suas principais características.</p><p>50</p><p>CAPÍTULO 3 • O PLAnEJAMEntO DO PROJEtO</p><p>tabela 9. técnicas de estimativa de prazo.</p><p>Técnica Descrição</p><p>Estimativa por</p><p>analogia</p><p>» Baseia-se no uso de uma duração real de uma atividade análoga já executada</p><p>anteriormente como ponto de partida para estimativa de futuras atividades.</p><p>» Pode usar atividades já executadas do próprio projeto ou dados históricos de outros</p><p>projetos que já se encerraram.</p><p>Estimativa</p><p>paramétrica</p><p>» Baseia-se na definição de um nível de complexidade para a execução da tarefa, em que a</p><p>duração está associada ao nível de complexidade. Por exemplo:</p><p>› Complexidade baixa = 16h</p><p>› Complexidade média = 32h</p><p>› Complexidade alta = 48h</p><p>Estimativa de três</p><p>Pontos</p><p>» Procura aumentar a probabilidade de acerto da estimativa. Ao invés de definir uma única</p><p>duração para a atividade, o responsável define três estimativas para três cenários:</p><p>› Mais provável (Tm): a duração da atividade em condições normais.</p><p>› Otimista (to): a duração da atividade em um cenário de melhor caso.</p><p>› Pessimista (tp): a duração da atividade em um cenário de pior caso.</p><p>A estimativa final é obtida pela fórmula:</p><p>(to + 4tm + tp) / 6</p><p>técnica Delphi</p><p>» É uma técnica para ser usada com um grupo de especialistas ou profissionais experientes.</p><p>» É útil quando o nível de detalhamento do escopo do produto ainda é baixo.</p><p>» É executada em uma série de rodadas em que as estimativas vão sendo discutidas pelos</p><p>especialistas até que seja atingido um consenso.</p><p>» Exige a presença de um coordenador na reunião para mediar a aplicação da técnica (pode</p><p>ser o próprio gerente de projeto).</p><p>Planning Poker</p><p>» É uma técnica que segue o mesmo princípio da técnica Delphi, ou seja, uma série de</p><p>rodadas onde um grupo procura atingir o consenso sobre uma estimativa.</p><p>» É bastante popular nas equipes que adotam métodos de desenvolvimento ágeis.</p><p>Fonte: Elaborado pela autora.</p><p>Assim, a partir da definição das atividades, do seu sequenciamento, da definição dos</p><p>recursos necessários e durações, temos todos os elementos para elaborar o cronograma</p><p>do projeto. Geralmente o cronograma é criado usando ferramentas específicas para</p><p>esse fim, como o Microsoft Project©.</p><p>Atenção</p><p>Pontos de atenção na elaboração do Plano de Gerenciamento do Tempo:</p><p>Não minta para você mesmo. Não minta para os outros.</p><p>Resista à tentação de planejar os prazos do projeto com base no prazo desejado pelo cliente.</p><p>Aprenda com o passado da empresa. Analise as estimativas de projetos anteriores semelhantes.</p><p>Crie e invista para manter uma base de conhecimento de estimativas de prazos dos projetos da empresa.</p><p>Se o escopo não está bem definido, existe alto risco de erro nas estimativas de prazo. Lembre-se do primeiro item.</p><p>Seja realista: considere a verdadeira disponibilidade dos recursos.</p><p>51</p><p>O PLAnEJAMEntO DO PROJEtO • CAPÍTULO 3</p><p>3.3 Plano de gerenciamento de custos</p><p>Como o próprio nome já revela, o plano de gerenciamento de custos lida com a questão</p><p>dos custos para realização do projeto (também chamado de orçamento do projeto),</p><p>e também com a questão do pagamento do projeto por parte do cliente (também</p><p>chamado de cronograma de desembolso).</p><p>É importante notar que, em vários tipos de projeto, a estimativa de custo está</p><p>diretamente relacionada à quantidade e tipo da mão de obra que trabalha direta ou</p><p>indiretamente nele. Entretanto, o custo de um projeto não se limita somente a essa</p><p>variável, pois existem diversos outros componentes do custo, como equipamentos,</p><p>materiais, serviços, instalações e provisão de aumento dos funcionários, entre outros.</p><p>Existem várias técnicas para estimar custos:</p><p>tabela 10. técnicas de estimativa de custo.</p><p>Técnica Descrição</p><p>Estimativa por</p><p>Analogia</p><p>» Baseia-se no uso de um custo real de uma atividade análoga já executada anteriormente</p><p>como ponto de partida para a estimativa de custo de futuras atividades.</p><p>» Pode usar custos de atividades já executadas do próprio projeto ou dados históricos de</p><p>outros projetos que já encerraram.</p><p>Estimativa</p><p>Bottom-up</p><p>» Envolve a estimativa de custo a partir dos pacotes de trabalho da EAP ou pelo</p><p>cronograma detalhado.</p><p>» O custo final é obtido por meio da combinação dos custos individuais de cada</p><p>componente.</p><p>» A precisão da estimativa está diretamente ligada à complexidade e ao tamanho do pacote</p><p>de trabalho ou atividade.</p><p>Estimativa</p><p>Top-down</p><p>» Envolve a estimativa de custo a partir de um orçamento predefinido.</p><p>» O orçamento é distribuído em cada pacote de trabalho da EAP ou atividade do</p><p>cronograma detalhado.</p><p>» A precisão da estimativa está limitada ao orçamento disponibilizado.</p><p>» Importante: devemos usar essa técnica para avaliar “quanto conseguimos realizar com</p><p>o orçamento definido” e não para “fazer tudo o que o cliente quer dentro do orçamento</p><p>definido”.</p><p>Estimativa</p><p>Paramétrica</p><p>» Baseia-se no uso de um valor unitário de custo que é multiplicado pela quantidade de</p><p>trabalho</p>