Gerência de Projetos. para concursos. Questões comentadas

Transcrição

1 Gerência de Projetos para concursos Questões comentadas

2 Prefácio As pessoas têm planejado e gerenciado projetos desde o início dos tempos. Toda vez que uma civilização criou suas raízes houve projetos a serem gerenciados: prédios a construir, estradas a pavimentar e leis a serem escritas. Com o passar do tempo, as pessoas perceberam que as técnicas para controle de custo, desenvolvimento da programação, procura e compra de recurso e gerenciamento de riscos poderiam ser aplicadas a uma variedade de projetos, seja erguendo pontes, decidindo como se governar, preparando-se para concursos públicos ou desenvolvendo um projeto de TI. Essas ideias foram a base para se estabelecer técnicas de gerenciamento que hoje conhecemos como Gerenciamento de Projetos ou Gerência de Projetos. Conforme PMBOK, Gerenciamento de Projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas nas atividades do projeto a m de atender os requisitos do projeto. O Gerenciamento de Projeto é utilizado globalmente e sem distinção por corporações, governos e pequenas organizações. Isso se verica ainda mais quando contextualizamos no ambiente de TI. Em função disso, este tema é cobrado com muito anco nos concursos. Portanto, o Grupo Handbook de TI preparou para você o volume Gerência de Projetos, que traz uma séria de questões comentadas sobre as diversas áreas da Gerência de Projetos. Bons estudos, Grupo Handbook de TI Página 1 de 58

3 Direitos Autorais Este material é registrado no Escritório de Direitos Autorais (EDA) da Fundação Biblioteca Nacional. Todos os direitos autorais referentes a esta obra são reservados exclusivamente aos seus autores. Os autores deste material não proíbem seu compartilhamento entre amigos e colegas próximos de estudo. Contudo, a reprodução, parcial ou integral, e a disseminação deste material de forma indiscriminada através de qualquer meio, inclusive na Internet, extrapolam os limites da colaboração. Essa prática desincentiva o lançamento de novos produtos e enfraquece a comunidade concurseira Handbook de TI. A série Handbook de Questões de TI Comentadas para Concursos Além do Gabarito é uma produção independente e contamos com você para mantê-la sempre viva. Grupo Handbook de TI Página 2 de 58

4 Canais de Comunicação O Grupo Handbook de TI disponibiliza diversos canais de comunicação para os concurseiros de TI. Loja Handbook de TI Acesse a nossa loja virtual em Serviço de Atendimento Comunique-se diretamente conosco através do faleconosco@handbookdeti.com.br Twitter do Handbook de TI Acompanhe de perto promoções e lançamentos de produtos pelo nosso Twitter com/handbookdeti Página 3 de 58

5 1. Assuntos relacionados: Gerência de Projeto, Gerenciamento de Custos, Índice de Desempenho de Custo, Índice de Desempenho de Prazo, PMBOK, Banca: CESGRANRIO Instituição: BNDES Cargo: Analista de Suporte Ano: 2008 Questão: 39 Em determinado momento, um projeto apresenta as seguintes características: custo real (actual cost): R$1.000,00 valor agregado (earned value): R$1.200,00 valor planejado (planned value): R$1.600,00 Segundo o PMBOK, qual o índice de desempenho de custos (cost performance index) desse projeto? (a). 2,5 (b). 1,25 (c). 1,2 (d). 0,625 (e). 0,4 Solução: O índice de desempenho de custos (IDC) mede a eciência de custos em um projeto. Esse índice é calculado a partir da divisão do valor agregado (VA) pelo custo real (CR). Assim, para o projeto desta questão, teremos um IDC igual a 1,2 (1.2000/1.000). Esse resultado nos informa que tal projeto encontra-se em uma condição favorável, pois o IDC é maior que 1,0. Caso o IDC fosse menor do que 1,0, diríamos, de acordo com o PMBOK, que o projeto se encontraria em uma condição desfavorável. Note que, para esta questão, o valor planejado (VP) fornecido não foi utilizado. Tal valor é empregado no cálculo de outros índices, por exemplo, o índice de desempenho de prazos (IDP), que ajuda a revelar se o projeto está adiantado ou atrasado em relação ao planejado. Página 4 de 58

6 2. Assuntos relacionados: Gerência de Projeto, Gerência de Custos, Gerenciamento de Valor Agregado (GVA), Banca: CESGRANRIO Instituição: Petrobras Cargo: Analista de Sistemas - Eng. de Software Ano: 2008 Questão: 35 São enumeradas a seguir algumas métricas colhidas para determinado intervalo de tempo ao longo da vida de um projeto. I - Custo orçado do trabalho previsto. II - Custo orçado do trabalho realizado. III - Custo real do trabalho previsto. IV - Custo real do trabalho realizado. A técnica de Gerenciamento de Valor Agregado GVA (em Inglês, Earned Value Management EVM ) se baseia nas métricas (a). I e II, apenas. (b). I e III, apenas. (c). II e IV, apenas. (d). I, II e IV, apenas. (e). I, II, III e IV. Solução: A GVA é uma metodologia de gerenciamento usada para integrar o escopo, o cronograma e os recursos de tal forma que se permita medir, objetivamente, o desempenho e o progresso do projeto. Com essa metodologia é possível prever o desempenho do projeto com base no desempenho passado. Para utilizar a GVA, é importante seguir alguns processos essenciais a qualquer projeto, como: denição e elaboração do escopo do projeto, incluindo a Estrutura Analítica do Projeto (EAP); elaboração do cronograma a partir da EAP; estimativa de custo, partindo da alocação dos recursos às atividades do projeto; e monitoramento do projeto. Uma vez que esses processos tenham sido realizados, é possível realizar estimativas baseandose nos princípios básicos da GVA: BCWS (Budgeted Cost for Work Scheduled ou Custo Orçado para Trabalho Planejado) é o montante nanceiro que o projeto, de acordo com o planejamento, deveria ter consumido até um dado ponto do cronograma. O BCWS é conhecido também como Valor Planejado (PV); BCWP (Budgeted Cost for Work Performed ou Custo Orçado para Trabalho Realizado) reete o valor do montante de trabalho que foi efetivamente realizado até uma data especíca. O BCWP é conhecido também como Valor Agregado (VA); ACWP (Actual Cost of Work Performed ou Custo Real do Trabalho Realizado) representa o custo efetivo do trabalho realizado até o momento. O ACWP é conhecido também como Custo Real (CR). Página 5 de 58

7 Para medir o desempenho, o Custo Orçado do Trabalho Realizado é determinado e comparado ao Custo Real do Trabalho Realizado. O progresso é medido pela comparação entre o Valor Agregado e o Valor Planejado. Conforme explicado anteriormente, a GVA se baseia nas métricas de Custo Orçado do Trabalho Previsto, Custo Orçado do Trabalho Realizado e Custo Real do Trabalho Realizado. Logo, a alternativa correta é a letra d. Página 6 de 58

8 3. Assuntos relacionados: Gerenciamento de Projetos, PMBOK, Gerenciamento Financeiro de Projetos, Análise de Valor Agregado, EVA, Banca: Cesgranrio Instituição: Petrobras Cargo: Analista de Sistemas Pleno - Processos Ano: 2006 Questão: 26 Um gerente espera que o desempenho do seu projeto continue apresentando no futuro o mesmo tipo de variações ocorridas até então. Se o orçamento no término (ONT) = 390, o valor agregado (VA) = 375 e o custo real (CR) = 325, qual é o valor da estimativa no término (ENT)? (a). 337,34 (b). 338,00 (c). 340,00 (d). 342,31 (e). 381,33 Solução: A Análise do Valor Agregado (ou EVA, do Inglês, Earned Value Analysis) é um método de avaliação de desempenho nanceiro de projetos. No entanto, no PMBOK todas as referências ao termo EVA são substuídas pelo termo EVM (do Inglês, Earned Value Management), pois EVA pode ser confundido com EVA (Economic Value Added), que é uma metodologia uma metodologia patenteada pela consultoria Stern Stuart. Para efeitos de provas, os dois acrônimos podem ser considerados equivalentes. O EVA tem como objetivo a medida e a análise do desempenho obtido através da relação entre os custos reais incorridos e o trabalho realizado no projeto dentro de um determinado período de tempo. Em outras palavras, o EVA é a avaliação entre o que foi obtido (agregado) em relação ao que foi realmente gasto e ao que se planejava gastar, sendo o valor agregado a uma atividade, o valor orçado para ela. Para alcançar a resposta da questão, primeiramente é necessário compreender o signicado de cada uma das métricas apresentadas na questão. VP (Valor Planejado): É o custo planejado para que se alcance uma determinada etapa do projeto; CR (Custo Real): É o custo efetivamente desembolsado para o avanço do projeto. Em outras palavras, é o quanto de fato se gastou para alcançar determinada etapa do projeto; VA (Valor Agregado): É o custo planejado do projeto para o trabalho realizado até o momento. Em outras palavras, o valor agregado é o valor dos serviços realmente executados baseados nos custos orçados; ONT (Orçamento no Término): É o orçamento total do projeto, também conhecido como baseline de custo. O ONT é a principal saída do processo de orçamentação; ENT (Estimativa no Término): É uma estimativa do custo total do projeto. Página 7 de 58

9 Neste ponto, vamos tentar compreender a essência da questão. O que precisamos determinar é uma estimativa do custo total do projeto (ENT), tendo em vista que as atividades executadas até o momento tiveram custos diferentes dos custos planejados (VP é diferente de VA). As atividades executadas até o momento estavam orçadas em 375 (VA). Porém, tais atividades foram executadas com um custo de apenas 325 (CR). Isso signica dizer que, até o momento, gastou-se menos que o planejado. No EVA, tal variação é medida pelo Índice de Desempenho de Custo, que é calculado pela seguinte fórmula: IDC = VA/CR Se IDC = 1 : Projeto está gastando exatamente o planejado Se IDC > 1 : Projeto está gastando menos que o planejado Se IDC < 1 : Projeto está gastando mais que o planejado Portanto, no projeto em questão, o IDC vale 375/325. Como o gerente prevê que os mesmos tipos de variações irão continuar ocorrendo no projeto, sabemos que no restante do projeto será mantido o mesmo IDC. Por m, para calcular o ENT, basta utilizar a seguinte fórmula: ENT = CR + (ONT - VA)/IDC E, aplicando a fórmula aos dados do problema, chegamos ao valor de 338, que corresponde a alternativa B. ENT = ( )/(375/325) ENT = ENT = 338 Página 8 de 58

10 4. Assuntos relacionados: Gerência de Projetos, PERT, GERT, CPM, Técnica de Avaliação, Caminho Crítico, Banca: Cesgranrio Instituição: Petrobras Cargo: Analista de Sistemas Pleno - Processos Ano: 2006 Questão: 28 Você é gerente de um projeto para desenvolvimento de um novo pacote de software para a área nanceira de uma empresa. Neste projeto existem algumas atividades que exigem testes especializados, e que talvez seja necessário repetir as atividades mais de uma vez. Para o desenvolvimento do cronograma, qual das seguintes opções você deve escolher? (a). A Técnica de Avaliação e Análise Gráca (GERT), porque aceita o desvio condicional e ciclos para a atividade do teste. (b). A Técnica de Avaliação e Análise de Programas (PERT), porque aceita uma distribuição por média ponderada, que vai equilibrar o tempo necessário para a atividade do teste. (c). A Técnica de Avaliação e Análise de Programas (PERT), porque aceita o desvio condicional e ciclos para a atividade do teste. (d). O Método do Caminho Crítico, porque permite o cálculo da folga para a atividade do teste. (e). O Método do Caminho Crítico, porque aceita uma distribuição por média ponderada, que vai equilibrar o tempo necessário para a atividade do teste. Solução: Vamos denir os termos citados das alternativas para que possamos entender as técnicas utilizadas para desenvolvimento de cronograma. Em um projeto, a duração de cada atividade pode ser diferente da prevista inicialmente. A duração de uma atividade pode ser reduzida ou ampliada até por fatores que sequer podem ser previstos como variações abruptas de indicadores econômicos, catástrofes, entre outros. Para que essas variações nas durações das atividades possam ser levadas em consideração e, consequentemente, que o planejamento seja mais conável, o PERT (Program Evaluation and Review Tecnique Técnica de Avaliação e Revisão de Projetos) é utilizado. Neste caso, cada atividade é entendida como uma variável aleatória e é assumido que a forma da distribuição de probabilidade dessa variável é a distribuição Beta. Já o método CPM (Critical Path Method Método do Caminho Crítico) utiliza valores determinísticos e tanto o PERT quanto o CPM utilizam os conceitos de redes (grafos) para planejar e visualizar a coordenação das atividades do projeto. Um caminho através de uma rede é uma rota seguindo os arcos a partir de um nó inicial até um nó nal e o comprimento de um caminho é a soma das durações das atividades sobre o caminho. O caminho com maior comprimento é o caminho crítico. O GERT (Graphical Evaluation and Review Techniques Técnica de Revisão e Avaliação Gráca) é um modelo parecido com PERT e CPM, no entanto, possui como característica principal o controle relacionado aos loopings, como por exemplo, uma atividade de inspeção do projeto que precisa ser repetida várias vezes. A técnica GERT combina a teoria Página 9 de 58

11 de uxo de sinais grácos, das redes probabilísticas, do PERT/CPM e da árvore de decisões. Como o GERT é justamente o método que leva em consideração a possibilidade de repetições de atividades, ele é o mais indicado para atender os requisitos do enunciado. Logo, a alternativa correta é a letra (A). Já alternativa (B) arma que o PERT leva em consideração uma distribuição por média ponderada. Essa armativa não deixa de ser verdade, mas não resolve, da mesma maneira que o GERT, o problema da repetição das atividades. A alternativa (C) se vale de uma armativa absolutamente falsa, pois quem aceita desvio condicional e ciclos é o GERT e não o PERT. As alternativas (D) e (E) também são armativas falsas que atribuem, ao Método do Caminho Crítico (CPM), denições que são válidas para outros métodos. Página 10 de 58

12 5. Assuntos relacionados: Gerenciamento de Projetos, Análise de Viabilidade de Projetos, Valor Presente Líquido, VPL, Banca: Cesgranrio Instituição: Petrobras Cargo: Analista de Sistemas Pleno - Processos Ano: 2006 Questão: 30 Uma analista está avaliando o VPL de um projeto. O projeto apresenta um investimento inicial de R$ ,00 e entradas esperadas de caixa de R$ ,00, R$ ,00 e R$ 5.000,00 no nal do primeiro, segundo e terceiro ano, respectivamente. Se o custo de capital for de 10% ao ano, qual é o valor aproximado, em reais, do VPL do projeto? (a) ,18 (b) ,73 (c) ,18 (d) ,73 (e) ,60 Solução: A análise do valor presente líquido (VPL) é um método tradicional de avaliação de viabilidade de projetos. O método do VPL baseia-se no fato de que o valor do dinheiro está relacionado com o tempo. Em um regime econômico inacionário (ou seja, em que os preços dos bens sobem com o passar do tempo), o dinheiro tende a perder o seu valor à medida que o tempo passa. Em palavras bem simples, R$ 100,00 valem mais hoje do que os mesmos R$ 100,00 daqui a 1 ano, por exemplo. O segundo conceito fundamental que precisa ser compreendido é o conceito de uxos de caixa do projeto. Os uxos do projeto são qualquer entrada ou saída de dinheiro que acontece ao longo de um projeto. Quando o empreendor realiza o investimento inicial, ou realiza pagamentos de fornecedores, por exemplo, temos um uxo de caixa negativo. Já quando os produtos produzidos pelo projeto são vendidos, e a empresa recebe algum pagamento, temos um uxo de caixa positivo. O somatório dos uxos de caixa positivos e negativos para um dado período é chamado uxo de caixa líquido. O objetivo do método VPL é trazer o valor de todos os uxos de caixa do projeto para uma data inicial, considerando o valor do dinheiro no tempo. Para realizar essa operação, é necessário conhecer a taxa com a qual o dinheiro se desvaloriza ao longo do tempo. Tal taxa é conhecida como Taxa de Desconto. Quando todos os uxos de caixa são trazidos para uma única data levando em consideração o valor do dinheiro no tempo, passa a fazer sentido somar os uxos de caixa. O somatório de todos os uxos de caixa de um projeto trazidos a data uma data base de avaliação (geralmente, a data inicial do projeto), é chamado Valo Presente Líquido do Projeto, ou, simplesmente, VPL do Projeto. A fórmula para cálculo do VPL do projeto é mostrada a seguir: VPL = FC0 + FC1/(1+t)^1 + FC2/(1+t)^2 + FC3/(1+t)^ FCn/(1+t)^n Página 11 de 58

13 onde: FC0 = Fluxo de caixa inicial. Geralmente, corresponde ao investimento inicial. FCi = Fluxo de caixa do período i t = Taxa de desconto Cada uma das parcelas da fórmula mostra como o uxo de caixa do período tem o seu valor projetado para o presente. É importante frisar que no método VPL, utiliza-se juros compostos. Portanto, no denominador de cada uma das parcelas utiliza-se o operador de exponenciação, com o valor de acordo com o número de períodos. Aplicando a fórmula nos dados do problema, teremos o seguinte resultado: VPL = FC0 + FC1/(1+t)^1 + FC2/(1+t)^2 + FC3/(1+t)^3 VPL = -R$ R$10.000/(1+0,1)^1 + R$15.000,00/(1+0,1)^2 + R$5.000/(1+0,1)^3 VPL = R$1.244,18 Logo, a resposta da questão é a alternativa C. Por m, vale ainda mencionar mais uma informação, que talvez seja ainda mais importante que a fórmula do VPL. Trata-se da interpretação do valor obtido no cálculo do VPL. Em linhas gerais, o que temos é o seguinte: VPL > 0 : O projeto é viável economicamente. Ou seja, o projeto gera valor. VPL < 0 : O projeto é inviável economicamente. Ou seja, o projeto traz prejuízos. VPL = 0 : A realização do projeto é indiferente. Não gera valor nem traz prejuízos. Página 12 de 58

14 6. Assuntos relacionados: Gerência de Projeto, Gerência de Escopo, EAP, Banca: CESGRANRIO Instituição: Petrobras Cargo: Analista de Sistemas - Eng. de Software Ano: 2008 Questão: 34 A Estrutura Analítica do Projeto - EAP (em Inglês Work Breakdown Structure WBS) inclui (a). estimativas de prazos. (b). estimativas de custos. (c). entregas internas e externas. (d). alocação dos recursos às tarefas. (e). estratégias para mitigação dos riscos. Solução: A área de gerenciamento do escopo compreende os processos necessários para assegurar que o projeto inclua todo o trabalho necessário, e somente ele, para nalizar o projeto com sucesso. A gerência de escopo tem como principal preocupação denir o que está ou não incluído no projeto. A Estrutura Analítica do Projeto (EAP), elaborada pelo processo Criar EAP, é uma das principais saídas da gerência de escopo. (A) ERRADA As estimativas de prazo são elaboradas pela área de gerenciamento de tempo com base na estimativa de recursos necessários, sequenciamento e duração das atividades. O processo responsável por realizar as estimativas de prazo é o Desenvolvimento do cronograma. Existem diversas ferramentas e técnicas para realizar o desenvolvimento do cronograma, como: análise de rede do cronograma, método do caminha crítico, compressão do cronograma, nivelamento de recursos, software de gerenciamento de projetos (MS Project, Primavera), etc. As estimativas de prazo são descritas no Plano de Gerenciamento do Cronograma e não na EAP. (B) ERRADA As estimativas de custo são elaboradas pela área de gerenciamento de custos baseado na estimativa dos recursos necessários para nalizar cada atividade do cronograma. Os custos das atividades do cronograma são estimados para todos os recursos cujos custos serão lançados no projeto. As estimativas de custo podem ser geradas por meio de ferramentas e técnicas, como: estimativa análoga, modelagem paramétrica, estimativa bottom-up, software de gerenciamento de projetos, etc. As estimativas de custos estão descritas no Plano de Gerenciamento de Custos e não na EAP. (C) CORRETA Uma entrega é qualquer produto ou serviço gerado pelo projeto. Segundo PMBOK, a EAP é uma decomposição hierárquica orientada a entrega de trabalho a ser executado pela equipe de projeto, para atingir os objetivos do projeto e criar as entregas necessárias. A EAP subdivide o trabalho a ser realizado no projeto em partes menores, em que cada nível Página 13 de 58

15 descendente representa uma denição mais detalhada do trabalho do projeto. O nível mais baixo é conhecido como pacote de trabalho. É o ponto no qual o custo e o cronograma do trabalho podem ser estimados de forma conável. Enm, todo o trabalho a ser executado no projeto deve estar na EAP, e seus componentes auxiliam as partes interessadas (stakeholders) a visualizar as entregas (internas ou externas). (D) ERRADA A alocação dos recursos às tarefas denidas na EAP é realiza pela área de gerenciamento de recursos humanos e compreende a alocação propriamente dita da equipe ao projeto. Os papéis e responsabilidades denidos serão destinados a uma pessoa ou grupo de pessoas. As formas de alocação são: negociação, alocação prévia e contratação. A alocação de recursos é descrita no Plano de Gerenciamento de Pessoal e não na EAP. (E) ERRADA Estratégia de mitigação de riscos é realizada pela área de gerenciamento de riscos e compreende planejar as respostas aos riscos de forma a reduzir as ameaças, ou seja, determinar quais ações deverão ser tomadas para reduzir as ameaças aos objetivos do projeto. Várias alternativas podem ser adotadas, como: evitar: mudar o plano do projeto para eliminar o risco; transferir: passar a resposta ao risco para terceiros; mitigar: estabelecer estratégias antecipadas para evitar que eventos causadores do risco aconteçam; aceitar: não estabelece estratégias para lidar com os riscos. As respostas aos riscos são incluídas no Registro de Riscos e não na EAP. Página 14 de 58

16 7. Assuntos relacionados: Gerência de Projeto, WBS, PMBOK, Planejamento em Ondas Sucessivas, Banca: Cesgranrio Instituição: BNDES Cargo: Analista de Sistemas - Desenvolvimento Ano: 2008 Questão: 68 Você montou a WBS (Work Breakdown Structure) do seu projeto e chegou ao seu nível mais baixo, no qual foram especicadas as estimativas de custo e tempo. De acordo com o PMBOK, esse nível da WBS é denominado (a). subprojetos. (b). pacotes de trabalho. (c). entregas acordadas. (d). entregas principais. (e). fases do projeto. Solução: A WBS, em português traduzida para EAP - Estrutura Analítica do Projeto - integra o conjunto de conhecimentos de gerenciamento de projetos voltado à gerência do escopo do projeto. De acordo com o PMBoK, o gerenciamento do escopo do projeto inclui os processos necessários para garantir que o projeto inclua todo o trabalho necessário, e somente ele, para terminar o projeto com sucesso. A WBS é um documento elaborado durante o planejamento do projeto. Sua função é delimitar claramente todo o trabalho que deverá ser realizado e os entregáveis que o projeto deverá gerar, sejam eles externos, internos ou intermediários. O objetivo não é limitar a criatividade do trabalho, explicitando nos mínimos detalhes o que será feito, e sim permitir que o trabalho possa ser acompanhado em termos de rendimento, custo, prazo. Seguindo essas ideiaideias, a WBS é uma estrutura hierárquica, onde os níveis mais altos representam entregáveis ou fases num aspecto mais amplo, e os mais baixos, vão descrevendo as etapas necessárias para se atingir os níveis imediatamente superiores. Essa estrutura deve seguir a regra dos 100%: a soma do percentual do trabalho previsto nos nós irmãos deve completar 100% do trabalho necessário para alcançar o resultado previsto no nó pai. Esse conceito serve em qualquer parte da estrutura. Com isso, garante-se que todo trabalho será feito e apenas ele. Se o planejamento for a menor, o projeto não somará 100% ao nal; se for a maior, o somatório extrapolará os 100%, indicando que há algo a mais sendo feito. A quantidade de níveis que podem ser gerados não é rígida. O importante é ter como medida o contraponto entre uma estrutura pobre, que não dá suporte ao trabalho de gerenciamento do projeto e uma estrutura demasiadamente complexa, que gera um sobretrabalho tão grande ao ponto de tornar-se inviável. Uma boa forma de medir o nível de detalhamento ótimo é vericar se o patamar atual alcançado na hierarquia é suciente para estimar custo e cronograma do trabalho de forma conável. Se for o caso, provavelmente este é um nível de detalhe adequado de se descer. O último nível de um WBS é conhecido como pacote de trabalho, e é caracterizado por possuir estas qualidades. Página 15 de 58

17 Pela sua característica de organizar o escopo de forma hierárquica, a EAP tem no topo da árvore o projeto em si. Abaixo dela, não há regra que obrigue aparecerem apenas entregáveis ou apenas fases. Todos os elementos de organização do trabalho podem ser incluídos, inclusive de forma mesclada. Apesar disso, o mercado adota como prática trabalhar com uma vertente ou com outra, evitando misturá-las no mesmo WBS. Projetos muito grandes podem ter em níveis inferiores subprojetos, podendo estes, inclusive, serem planejados para execução por outras empresas, em contratos do projeto. Um fato importante é lembrar de colocar todas as fases e etapas do processo de gerenciamento do projeto dentro da WBS Se estas etapas são necessárias para a execução do projeto, elas não podem ser negligenciadas justamente no documento que trata do escopo do trabalho a ser realizado. Alguns projetos grandes também podem ter fases muito distantes onde não seja possível enxergar com clareza a estrutura do trabalho. Para esses casos, uma técnica comumente aplicada é o planejamento em ondas sucessivas. Nesta técnica, a equipe de gerenciamento de projetos espera até que a entrega ou subprojeto estejam esclarecidos para poder desenvolver os detalhes da EAP. No processo de criar a EAP, além da EAP propriamente dita, é gerado também o dicionário da EAP. Este documento de apoio à EAP descreve pormenorizadamente os detalhes das etapas e entregáveis apresentados na EAP. Estes detalhes são apresentados com o nível de riqueza maior possível, permitindo que os devidos controles sejam mais ecientes. Aqui, pode-se ter nos pacotes de trabalho, por exemplo, a descrição das etapas do trabalho esperadas, o prazo, custo e recursos envolvidos. Em fases e atividades, informações como referências técnicas e de qualidade. Subprojetos desenvolvidos por terceiros podem ter informações sobre o contrato, por exemplo. Página 16 de 58

18 8. Assuntos relacionados: PMBOK, Banca: Cespe Instituição: ANAC Cargo: Analista Administrativo - Tecnologia da Informação Ano: 2009 Questão: O PMBOK especica nove áreas de conhecimento da gestão de projetos: escopo, tempo, qualidade, custo, integração, recursos humanos, comunicação, riscos e aquisições. Como se verica na gura acima, há um grupo de processos de iniciação que procura facilitar a autorização formal para se iniciar um novo projeto ou uma fase do projeto, enquanto os processos de planejamento são utilizados pela equipe de gerenciamento de projetos para planejar ou gerenciar um projeto para a organização. O grupo de processos de execução é relativo às atividades utilizadas para se terminar o trabalho denido no plano de gerenciamento de projeto e, dessa forma, cumprir os requisitos do projeto, enquanto o grupo de processos de encerramento inclui todas as atividades necessárias para se entregar um produto terminado ou encerrar um projeto cancelado. Considerando as informações acima, julgue os itens de 101 a 105, a respeito das melhores práticas de gerenciamento de projetos. 101 O processo que consiste em desenvolver a declaração de escopo preliminar do projeto trata principalmente da autorização do projeto ou, em um projeto com várias fases, de uma fase do projeto; é usado para a documentação das necessidades de negócios e do novo produto, serviço ou outro resultado que deva satisfazer esses requisitos. 102 Segundo o PMBOK, assim como nem todos os processos são necessários em todos os projetos, nem todas as interações se aplicam a todos os projetos ou fases do projeto, como o que ocorre quando os projetos que dependem de recursos exclusivos podem denir funções e responsabilidades antes da denição do escopo. 103 O plano de gerenciamento do projeto determina qual trabalho deve ser realizado e quais entregas precisam ser produzidas, e a declaração do escopo do projeto determina como o trabalho deve ser realizado. Página 17 de 58

19 104 O processo estimativa de custos, envolve a determinação dos recursos (pessoas, equipamentos ou material), das quantidades de cada recurso que devem ser usadas e do momento em que cada recurso deve estar disponível para que as atividades do projeto sejam realizadas. 105 O sistema de controle de mudanças nos custos é documentado, controlado e monitorado pelo plano de gerenciamento de custos e desvinculado do processo de controle integrado de mudanças. Solução: Apesar do primeiro parágrafo deste grupo de questões abordar alguns aspectos importantes sobre o PMBOK, é interessante aprofundarmos um pouco mais a descrição sobre o assunto. PMBOK é o acrônimo de Project Management Body of Knowledge. Ele foi criado e continua sendo mantido pelo PMI (Project Management Institute). Esse instituto foi concebido em 1969 na Filadéla (EUA). A primeira versão ocial do PMBOK foi lançada em 1996 e, na verdade, tinha outro nome: A Guide to the Project Management Body of Knowledge. Em 2000 e em 2004 foram lançadas, respectivamente, as versões 2 e 3 do PMBOK. A quarta versão, lançada em 31/12/2008, é hoje a mais atual. Ao longo dessas versões ajustes foram feitos e novos conceitos foram agregados. Contudo, nenhuma modicação drástica foi feita na losoa desse Guia. O próprio Guia PMBOK v3 tem uma denição muito boa e que esclarece vários pontos importantes para a resolução das questões a seguir. Vejamos: O principal objetivo do Guia PMBOK é identicar o subconjunto do Conjunto de conhecimentos em gerenciamento de projetos que é amplamente reconhecido como boa prática. Identicar signica fornecer uma visão geral, e não uma descrição completa. Amplamente reconhecido signica que o conhecimento e as práticas descritas são aplicáveis à maioria dos projetos na maior parte do tempo, e que existe um consenso geral em relação ao seu valor e sua utilidade. Boa prática signica que existe acordo geral de que a aplicação correta dessas habilidades, ferramentas e técnicas podem aumentar as chances de sucesso em uma ampla série de projetos diferentes. Uma boa prática não signica que o conhecimento descrito deverá ser sempre aplicado uniformemente em todos os projetos; a equipe de gerenciamento de projetos é responsável por determinar o que é adequado para um projeto especíco. Com relação a sua organização, o PMBOK se apresenta da seguinte forma. Esse Guia de boas práticas prega um tipo de gerenciamento de projetos fortemente orientado a processos. O número de processos varia em função da versão do PMBOK, mas para se ter uma ideia geral, a sua versão 4 contém 42 processos. Esses processos são divididos entre 9 áreas de conhecimento, são elas: 1. Integração 2. Escopo 3. Tempo 4. Custos 5. Qualidade Página 18 de 58

20 6. Recursos humanos 7. Comunicações 8. Riscos 9. Aquisições Os processos também são divididos, de acordo com as suas características comuns, em 5 grupos de processos, são eles: 1. Iniciação: dene e autoriza o projeto ou uma fase do projeto; 2. Planejamento: dene e rena os objetivos e planeja a ação necessária para alcançar os objetivos e o escopo para os quais o projeto foi realizado; 3. Execução: integra pessoas e outros recursos para realizar o plano de gerenciamento do projeto para o projeto; 4. Monitoramento e controle: mede e monitora regularmente o progresso para identi- car variações em relação ao plano de gerenciamento do projeto, de forma que possam ser tomadas ações corretivas quando necessário para atender aos objetivos do projeto; 5. Encerramento: formaliza a aceitação do produto, serviço ou resultado e conduz o projeto ou uma fase do projeto a um nal ordenado. Um erro muito comum é confundir os grupos de processos com as fases do projeto. Os conceitos de grupo e fase não se equivalem nesse caso. Dependendo das características do projeto, pode-se ter diversas fases e em cada uma delas diversos processos de vários grupos podem ser executados. A Figura 1, do próprio Guia versão 3, nos auxilia nesse entendimento. Figura 1: sequência típica de fases no ciclo de vida de um projeto. Para concluirmos o entendimento da organização, podemos pensar que os processos são dispostos em um plano de duas dimensões. Um eixo de grupos de processos e outro eixo de área de conhecimento. A Figura 2, correspondente à versão 3 do PMBOK, traz justamente essa disposição. É uma ótima prática ter essa disposição em mente. Página 19 de 58

21 Figura 2: mapeamento entre os processos de gerenciamento de projetos e os grupos de processos de gerenciamento de projetos e as áreas de conhecimento. Página 20 de 58

22 101 ERRADO Como pode ser visto na Figura 2, de fato existe na versão 3 do PMBOK um processo chamado Desenvolver a Declaração do Escopo Preliminar do Projeto. Contudo, o seu real objetivo é desenvolver uma descrição alto nível do escopo do projeto, chamada de Declaração do Escopo Preliminar do Projeto. Para a confecção deste documento, a equipe de gerenciamento geralmente utiliza como entrada os seguinte documentos: Termo de Abertura do Projeto, Declaração do Trabalho do Projeto, Fatores Ambientais da Empresa e Ativos de Processos Organizacionais. Mais adiante no projeto, durante a execução de outro processo (Denição do Escopo) a Declaração Preliminar é renada e dá origem a outro documento, chamado de Declaração do Escopo do Projeto. É importante destacar que o processo Desenvolver a Declaração do Escopo Preliminar do Projeto deixou de fazer parte do PMBOK em sua versão 4. Veja a seguir as principais alterações entre as versões 3 e 4. o nome de todos os processos foram substituídos de substantivo para verbo; o número de processos foi reduzido de 44 para 42. Dois processos foram excluídos, dois foram adicionados e seis foram recongurados. A saber: 4.2 Desenvolver a declaração do escopo preliminar do projeto - Eliminado; 4.7 Encerrar o projeto - Alterado para 4.6 Encerrar o projeto ou fase; 5.1 Planejamento do escopo - Eliminado; 5.1 Coletar os requisitos - Adicionado; 9.4 Gerenciar a equipe do projeto - Alterado de um processo de controle para um processo de execução; 10.1 Identicar as partes interessadas - Adicionado; 10.4 Gerenciar as partes interessadas - Alterado para Gerenciar as expectativas das partes interessadas. Alterado de um processo de controle para um processo de execução; 12.1 Planejar compras e aquisições e 12.2 Planejar contratações - Alterados para 12.1 Planejar as aquisições; 12.3 Solicitar respostas de fornecedores e 12.4 Selecionar fornecedores - Alterados para 12.2 Realizar aquisições. O objetivo que o enunciado desta questão traz, na verdade, está relacionado a outro processo: Desenvolver o termo de abertura do projeto. É justamente por isso que a armação feita nesta questão está errada. 102 CERTO Tendo em vista o exposto acima, principalmente a denição retirada do próprio PM- BOK versão 3, não é difícil vericar que esta questão traz uma armação correta. Como o PMBOK é um conjunto de boas práticas para gerenciamento de projetos, nem tudo o que ele prega deve ser utilizado em todos os projetos. É função, principalmente, do gerente de projetos alinhar as características do projeto, do organização, da equipe, etc. às ferramentas e conceitos disponíveis no Guia. Página 21 de 58

23 103 ERRADO Um candidato desatente, mesmo conhecendo o assunto, pode se equivocar e marcar esta questão como CERTO. Isso porque ela inverte os propósitos do Plano de Gerenciamento do Projeto e da Declaração do Escopo do Projeto. O Plano de Gerenciamento do Projeto contempla tudo que é considerado necessário para denir como o projeto será executado, monitorado, controlado e encerrado. Ele documenta quais serão as saídas de todos os processos considerados do grupo de Processos de Planejamento. Além disso, ele inclui, dentre outros aspectos, o seguinte: o nível de implementação de cada processo selecionado; as descrições das ferramentas e técnicas que serão usadas para realizar esses processos; como os processos selecionados serão usados para gerenciar o projeto especíco, inclusive as dependências e interações entre esses processos e as entradas e saídas essenciais; como as mudanças serão monitoradas e controladas; a necessidade e as técnicas de comunicação entre as partes interessadas; o ciclo de vida do projeto selecionado e, para projetos com várias fases, as fases associadas do projeto. É interessante notar também que o Plano de Gerenciamento do Projeto pode ser constituído por planos auxiliares e outros tipos de documento. Alguns exemplos são: Plano de gerenciamento do escopo do projeto; Plano de gerenciamento do cronograma; Plano de gerenciamento da qualidade; Plano de gerenciamento das comunicações; Plano de gerenciamento de riscos; Plano de gerenciamento de aquisições; Lista de marcos; Linha de base do cronograma; Linha de base da qualidade; Registro de riscos. Já a Declaração do Escopo do Projeto é uma das saídas do processo Denição do Escopo. Esse documento descreve detalhadamente quais devem ser as entregas do projeto e qual é o trabalho necessário para que essas entregas sejam feitas. Ele também fornece um entendimento comum sobre qual é o escopo do projeto a todos os stakehouders. 104 ERRADO Esta questão traz uma armação que confunde muitas pessoas. O processo que envolve a determinação dos recursos (pessoas, equipamentos ou material), das quantidades de cada recurso que devem ser usadas e do momento em que cada recurso deve estar disponível para que as atividades do projeto sejam realizadas é o chamado Estimativa de Recursos da Atividade. O processo Estimativa de Custos não determina nenhum aspecto relacionado a recursos. Na verdade, ele obtém como entrada esse tipo de informação para desenvolver Página 22 de 58

24 estimativas realistas dos custos dos recursos considerados necessários para terminar cada atividades do projeto. Para isso, algumas das ferramentas utilizadas são: estimativa análoga (projetos similares), estimativa paramétrica (modelos matemáticos), análise de proposta de fornecedor, etc. 105 ERRADO Ao ler com atenção a armação feita por esta questão, mesmo sem grandes conhecimentos especícos sobre o PMBOK é provável que o candidato a julgue como errada. Anal de contas, se há um controle integrado de mudanças, ele certamente integra vários processos concorrentes relacionados a mudanças. Esse tipo de leitura crítica é muito importante para quem busca uma vaga em um concurso público. De qualquer forma, vamos aos conceitos que aparecem nesta questão. O Sistema de Controle de Mudanças nos Custos é uma das possíveis ferramentas utilizadas no processo de Controle de Custos. Esse sistema é sim documentado no Plano de Gerenciamento de Custos. Ele dene os procedimentos, formulários, documentos e níveis de aprovação necessários através dos quais é possível realizar mudanças na linha de base dos custos. Já o processo de Controle Integrado de Mudanças, como o próprio nome revela, trata da rejeição ou aprovação, de forma centralizada, de todas as mudanças signicativas no projeto, indiferentemente da área de conhecimento envolvida. Sem esse tipo de controle centralizado, equipes e processos correlacionados dicilmente se alinhariam novamente depois de mudanças signicativas. Um exemplo trivial de problema seria o seguinte. Imagine que por algum motivo o cronograma do projeto tivesse que ser reajustado, é claro para menos. Caso essa mudança fosse feita de forma isolada, como os processos que lidam com custo e a qualidade do projeto poderiam se adequar a esse novo cronograma? Em projetos grandes, onde centenas ou talvez milhares de pessoas estão envolvidas, muito provavelmente isso não seria feito, aumentando consideravelmente as possibilidades de fracasso no projeto. Por outro lado, sendo o controle de mudanças centralizado, todas as equipes e processos que podem sofrer impactos com as mudanças aprovadas são noticadas e, assim, podem realizar seus ajustes necessários. Página 23 de 58

25 9. Assuntos relacionados: Gerência de Projeto, Gerência de Tempo, Monte Carlo, Banca: FCC Instituição: MPU Cargo: Analista de Desenvolvimento de Sistemas Ano: 2007 Questão: 54 De acordo com o corpo de conhecimento da gerência de projetos, as simulações para análise de risco de prazos são possíveis utilizando (a). o Arrow Diagramming Method. (b). a técnica Monte Carlo. (c). o modelo WBS. (d). a análise de custo/benefício. (e). o Project Charter. Solução: Análise de risco é o uso sistemático da informação disponível para determinar quão frequentemente eventos denidos podem vir a ocorrer e a magnitude de suas consequências. A análise de risco pode ser realizada qualitativamente ou quantitativamente. A análise de risco qualitativa envolve a avaliação de uma situação por ponderações subjetivas e é caracteriza por declarações como Isto parece muito arriscado ou Nós provavelmente teremos um bom retorno disto. A análise de risco quantitativa busca associar valores numéricos aos riscos. Vamos focar no estudo da análise quantitativa para resolvermos esta questão. Os objetivos da análise quantitativa são: determinar a probabilidade de se conquistar um objetivo especíco do projeto; quanticar a exposição do risco para o projeto, e determinar o tamanho da reserva contingência do custo e cronograma que pode ser necessária; identicar riscos que requerem maior atenção, quanticando sua contribuição relativa ao risco do projeto; identicar custo, cronograma, ou objetivos de escopo realístico e alcançável. As técnicas e ferramentas para a análise quantitativa do risco são: Análise de sensibilidade: Essa análise quantica as consequências associadas à variação de cada elemento no projeto quando os outros elementos são mantidos em seus valores iniciais; Análise da árvore de decisão: A árvore de decisão é um diagrama que descreve uma decisão que está sendo considerada e as implicações da escolha de uma ou outra das alternativas disponíveis. É usada quando alguns futuros cenários ou resultados de ações são incertos. Ela incorpora as probabilidades e os custos ou premiações de cada caminho lógico de eventos e decisões futuras; Análise do valor monetário esperado: É um conceito estatístico que calcula o resultado médio quando o futuro inclui cenários que podem ou não acontecer; Página 24 de 58

26 Modelagem e simulação: Uma simulação utiliza um modelo que traduz as incertezas em um nível detalhado do projeto para seu impacto potencial nos objetivos iniciais. As simulações são normalmente realizadas usando a técnica de Monte Carlo. Agora sabemos que a técnica de Monte Carlo é utilizada na análise quantitativa de riscos para realizar simulações envolvendo tanto prazos quanto custos. A alternativa a ser marcada é a letra (B). Vamos conhecer os termos utilizados nas outras alternativas: (A) Arrow Diagramming Method, também conhecido como Método do diagrama de setas (MDS), é uma técnica de diagramação de rede do cronograma onde as atividades do cronograma são representadas por setas. A extremidade nal da seta representa o início, e a cabeça representa o término da atividade do cronograma. (C) Work Breakdown Struct também conhecido como estrutura analítica do projeto (EAP). Ela organiza e dene o escopo total do projeto. Cada nível descendente representa uma denição cada vez mais detalhada do trabalho do projeto. (E) Project Charter é o documento que reconhece formalmente a existência do projeto, menciona detalhes sobre os principais objetivos e razões pela existência deste projeto. Página 25 de 58

27 10. Assuntos relacionados: Desenvolvimento de Sistemas, Gerenciamento de Projetos, Gerenciamento de Riscos, Árvores de Decisão, Banca: Cesgranrio Instituição: BNDES Cargo: Analista de Sistemas - Desenvolvimento Ano: 2008 Questão: 37 Observe a árvore de decisão abaixo relativa ao desenvolvimento de um projeto de software. Os números decimais entre parênteses representam o valor da probabilidade da escolha do ramo, enquanto que o valor em reais, o custo de cada opção. Analisando a árvore acima, conclui-se que: (a). o custo esperado para realizar o trabalho contratando desenvolvimento terceirizado é de R$ 7.480,00. (b). o custo estimado para Desenvolver internamente é menor do que o custo estimado para Contratar desenvolvimento terceirizado. (c). quando não há probabilidade associada ao primeiro nível da árvore de decisão, pode-se assumir que essa probabilidade é de 50%. (d). supondo que a opção Contratar desenvolvimento terceirizado seja escolhida, e que uma equipe inexperiente assuma o trabalho, o custo esperado será de R$ 4.480,00. (e). as probabilidades associadas à árvore de decisão estão inconsistentes. Solução: A questão mostra uma aplicação prática de uma árvore de decisão no contexto de um projeto de software, em que se objetiva calcular o custo do projeto de acordo com as decisões que podem ser tomadas. Antes de iniciarmos os cálculos, vamos primeiro introduzir basicamente as árvores de decisão e suas utilidade básica. As árvores de decisão são representações grácas dos diversos caminhos que podem ser seguidos no contexto de um problema de tomada de decisão. Em outras palavras, as árvores de decisão procuram mostrar gracamente as consequências de decisões que podem ser tomadas em uma determinada situação. Comumente, as árvores de decisão também exibem as probabilidades associadas às decisões tomadas, sendo, portanto, ótimas ferramentas para a avaliação quantitativa de riscos. Página 26 de 58

28 É importante observar que, para serem consistentes, a soma das probabilidades das decisões que podem ser tomadas a partir de um determinado nó da árvore sempre devem dar 1 (ou 100%). Isso pode ser observado na gura da questão no momento em que se opta por contratar desenvolvimento terceirizado. A chance de contratar uma equipe experiente é de 30%, enquanto a chance de que a equipe contratada seja inexperiente é de 70%. Como a árvore apresentada obedece a essa regra em todos os seus pontos, podemos eliminar a alternativa E. O valor esperado em um determinado nó da árvore pode ser calculado como a média dos valores de cada uma de suas ramicações, ponderados pelas suas probabilidades. No caso da contratação de desenvolvimento terceirizado de uma equipe inexperiente, o custo esperado do projeto seria: (R$7000 x 0.8) + (R$4000 x 0.2) = R$6400 Logo, a alternativa D está errada. Calculado o custo esperado do desenvolvimento terceirizado com uma equipe inexperiente, podemos agora calcular o valor do nó imediatamente acima, ou seja, o custo esperado do desenvolvimento terceirizado. (R$6400 x 0.7) + (R$9000 x 0.3) = R$7180 Com isso podemos concluir que o custo esperado do desenvolvimento terceirizado, R$ 7.180,00, é maior do que o custo esperado de se desenvolver internamente. Logo, a alternativa A está errada, e a alternativa B está certa. A alternativa C é falsa por denição. Se não se conhece a probabilidade de uma determinada decisão, não há que se fazer considerações a respeito dela. No cenário apresentado, pela falta dessa informação na primeira decisão tomada desenvolver internamente ou terceirizar torna-se impossível calcular o valor esperado do projeto como um todo. O máximo que se poderia dizer é que o valor máximo esperado para o projeto seria de R$ 7.180,00 (no caso de terceirização), e que o valor mínimo esperado para o projeto seria de R$ 7.000,00, no caso de desenvolvimento interno. Página 27 de 58

29 11. Assuntos relacionados: Gerenciamento de Projetos, Gerenciamento de Riscos, Matriz de Probabilidade e Impacto de Riscos, Banca: Cesgranrio Instituição: Petrobras Cargo: Analista de Sistemas Pleno - Processos Ano: 2006 Questão: 29 Um gerente de projeto está construindo uma matriz de probabilidade e impacto de riscos para o seu projeto. Assim, esta matriz multiplica: (a). a probabilidade do risco pelo custo do impacto para calcular o valor esperado do evento de risco. (b). a probabilidade do risco pela probabilidade de impacto que caem no intervalo de 0,0 e 5,0 para calcular a probabilidade dos valores dos riscos. (c). a probabilidade do risco pelo valor esperado do evento de risco para calcular o impacto e atribuir uma pontuação ao risco, com base em um limiar pré-denido. (d). as escalas de probabilidade do risco e as escaladas de impacto do risco que caem no intervalo 0,5 e 1,0 para calcular a pontuação do risco. (e). as escalas de probabilidade do risco que caem no intervalo de 0,0 e 1,0 pelas escalas de impacto do risco para calcular a pontuação do risco. Solução: Em Gerência de Projetos, a área de gerenciamento de riscos é responsável por minimizar a probabilidade de ocorrência de desvios ao longo do ciclo de vida do projeto. Relembremos os processos do Gerenciamento de Riscos: Planejamento: denir qual será a abordagem aos riscos; Identicação: identicar, descrever e classicar os riscos; Análise Qualitativa: associar probabilidades e graus de impacto aos riscos através de técnicas como Matriz de Graduação, Matriz Probabilidade x Impacto (nosso foco nesta questão!); Análise Quantitativa: associar probabilidades e graus de impacto de forma numérica utilizando técnicas como Análise de Sensibilidade, Árvore de Decisão e Simulações; Planejamento de Respostas: denir qual ação será tomada mediante os riscos identicados (ex: evitar, transferir, mitigar, aceitar); Controle e Monitoração: garantir a execução do plano, identicar novos riscos, monitorar riscos residuais e realizar ajustes necessários. Como dissemos acima, o nosso foco nesta questão é a Análise Qualitativa de Riscos, a qual visa à detecção do impacto dos riscos identicados sobre os objetivos do projeto e sua probabilidade de ocorrência, classicando, paralelamente, os riscos por prioridade, de acordo com os efeitos sobre os objetivos do projeto (por exemplo, alto, médio ou baixo). A ferramenta (e técnica) Matriz de classicação de Riscos por Probabilidade e Impacto (PI) tem como objetivo atribuir uma classicação genérica a cada um dos riscos identicados do projeto, geralmente expressa como alta (condição vermelha), moderada (condição amarela) ou baixa (condição verde). Em uma matriz em preto e branco, essas condições podem ser indicadas pelos diferentes tons de cinza. Especicamente, na Figura 3, a área Página 28 de 58

30 cinza escuro (com os números mais altos) representa risco alto; a área cinza médio (com os números mais baixos) representa risco baixo; e a área cinza claro (com números intermediários) representa risco moderado. Esse tipo de classicação é denominado de escala ordinal, porque os valores são ordenados de forma descendente. Ao m desse processo, portanto, os riscos podem ser enumerados por ordem de prioridade de atenção. Figura 3: Matriz de Probabilidade e Impacto. A pontuação do risco ajuda a orientar as respostas a riscos. Por exemplo, riscos que, se ocorrerem, terão um impacto negativo nos objetivos (ameaças) e que se encontram na zona de alto risco (cinza escuro) da matriz podem exigir ações prioritárias e estratégias agressivas de resposta. As ameaças na zona de baixo risco (cinza médio) podem não exigir nenhuma ação de gerenciamento pró-ativo, além da sua colocação em uma lista de observação ou da sua adição a uma reserva para contingências. Isso ocorre de forma similar para as oportunidades. Portanto, deve-se buscar primeiro as oportunidades na zona de alto risco (cinza escuro) que podem ser obtidas mais facilmente e oferecem o maior benefício. As oportunidades na zona de baixo risco (cinza médio) devem ser monitoradas. A partir da Figura 3 podemos observar, facilmente, que a matriz de PI é determinada a partir da multiplicação de dois valores: o valor da probabilidade do risco (eixo y) vezes o valor do seu impacto (eixo x) (cada qual gerado na escala correspondente). Saiba que antes de se chagar a matriz PI, são elaboradas a escala de probabilidades e a escala de impacto dos riscos. O objetivo dessas escalas é desenvolver medidas predenidas que determinem que valor atribuir a determinado evento de risco. Assim, concluímos que a alternativa A está errada porque na multiplicação não se utiliza o valor da probabilidade e do custo do impacto de um risco diretamente, em vez disso são adotados os valores associados às respectivas escalas (eixo x e eixo y, na Figura). Podemos eliminar as alternativas B e C pelo mesmo motivo. Já a alternativa D está errada porque não podemos saber, à priori, o valor da escala de impacto de risco (a avaliação de impacto dos riscos costuma se dar por meio de técnicas de opinião especializada e entrevistas). Portanto, a alternativa E está correta (lembre-se que a probabilidade de um evento é sempre um número entre 0 e 1). Página 29 de 58

31 12. Assuntos relacionados: Gerência de Projeto, Gerência de Integração, Controle Integrado de Mudanças, Banca: CESGRANRIO Instituição: Petrobras Cargo: Analista de Sistemas - Eng. de Software Ano: 2008 Questão: 38 É recomendado que um projeto possua um mecanismo formal e documentado de controle de mudanças. Sobre este mecanismo, são feitas as armativas a seguir. I - O mecanismo deve rastrear e tratar mudanças em quaisquer fatores críticos de sucesso do projeto, incluindo escopo, prazos e custos. II - Para tornar o processo gerenciável, é recomendado que sejam rastreadas apenas mudanças que possuam impacto signicativo no custo ou nos prazos do projeto e que não sejam rejeitadas em primeira análise. III - A avaliação e a aprovação de quaisquer solicitações de mudanças são atribuições exclusivas do gerente de projeto, pois o mesmo detém a autoridade e a responsabilidade sobre os resultados nais do projeto perante os stakeholders. IV - Tipicamente, o mecanismo de controle de mudanças prevê algumas categorias de mudanças que são automaticamente aprovadas tais como as resultantes de emergências as quais devem ser registradas e rastreadas, da mesma forma que as demais. Estão corretas APENAS as armativas: (a). I e II. (b). I e III. (c). I e IV. (d). II e III. (e). III e IV. Solução: O controle de mudanças ou controle integrado de mudanças é um dos processos da área de gerenciamento de integração. Essa área compreende os processos necessários para garantir a integração efetiva entre os processos das áreas de gerenciamento visando os objetivos do projeto. A integração das áreas, por exemplo, consiste em escolher sobre quais pontos concentrar recursos e esforço em quais dias especícos, antecipando possíveis problemas, tratando-os antes de se tornarem críticos e coordenando o trabalho visando o bem geral do projeto. Mais especicamente, o processo controle integrado de mudanças consiste em registrar as mudanças no projeto, seus motivos e respectivos impactos e realizar as alterações necessárias de forma integrada visando o projeto como todo. O controle de mudanças é realizado durante todo o projeto. Uma mudança pode exigir alteração nas estimativas de custos, sequências de atividades, datas de cronograma e recursos necessários, e tudo isso deve ser monitorado e controlado para o sucesso do projeto. Uma das ferramentas ou técnicas para o controle integrado de mudanças é o sistema de controle de mudanças: um conjunto de procedimentos formais e documentados que denem como as entregas e a documentação do projeto serão controladas, alteradas e aprovadas. Página 30 de 58

32 De acordo com as armações da questão, temos: I Conforme explicado anteriormente, o controle de mudanças deve monitor e tratar todas as mudanças de forma integrada visando o sucesso do projeto. Isso inclui os fatores críticos do projeto como escopo, prazo, custo, recursos necessários, orçamento e requisitos de qualidade. Logo, armativa verdadeira; II As mudanças aprovadas devem ser monitoradas e avaliadas levando em consideração não apenas o custo ou prazo do projeto, mas também o impacto no escopo, orçamento e requisitos de qualidade. Logo, armação falsa; III Todas as mudanças solicitadas e documentas devem ser aceitas ou rejeitadas por uma autoridade dentro da equipe de gerenciamento de projetos ou por uma organização externa que represente o patrocinador ou cliente. O sistema de controle de mudanças muitas vezes inclui um comitê de controle de mudanças, responsável pela aprovação ou rejeição das mudanças solicitadas. As funções e responsabilidades desses comitês são denidas claramente nos procedimentos de controle de conguração e de controle de mudanças e são acordadas com o patrocinador, com o cliente e com outras partes interessadas. Ou seja, a avaliação e aprovação das mudanças não dependem exclusivamente do gerente de projetos, mas de um comitê. Logo, armação falsa; IV O sistema de controle de mudanças deve também incluir procedimentos para tratar mudanças que podem ser aprovadas sem revisão prévia; por exemplo, como um resultado de emergências. Tipicamente, um sistema de controle de mudanças tem uma forma automática de aprovação de categorias especícas de mudanças. Essas mudanças devem ainda ser documentadas e capturadas de forma que as transformações na linha base do projeto possam ser registradas. Logo, armação verdadeira. Conforme exposto acima, a alternativa correta é a letra c. Página 31 de 58

33 13. Assuntos relacionados: Gerência de Projeto, Gerência de Tempo, Desenvolvimento de Cronograma, Banca: CESGRANRIO Instituição: Petrobras Cargo: Analista de Sistemas - Eng. de Software Ano: 2008 Questão: 33 Ao apresentar o cronograma de um projeto à diretoria da empresa, o gerente foi informado de que a data de término do projeto deverá ser antecipada em 3 meses. Esta exigência implicará, necessariamente, em (a). refazer as estimativas de esforço para uma ou mais tarefas do projeto. (b). reduzir a duração do caminho crítico do projeto. (c). alocar mais recursos ao projeto. (d). fazer entregas diferentes das especicadas. (e). aumentar o custo do projeto. Solução: (A) ERRADA A antecipação da data nal do projeto consiste, normalmente, em alterar a duração de atividades que pertencem ao caminho crítico. O caminho crítico, geralmente, é a sequência de atividades do cronograma que determina a duração do projeto, isto é, o caminho mais longo do projeto. Dependendo da técnica de compreensão de cronograma utilizada, há a necessidade de refazer as estimativas de esforço das atividades relacionadas ao caminho crítico, mas não é uma implicação necessária para reduzir o prazo de um projeto. (B) CORRETA Antecipar a data nal do projeto em 3 meses implica em alterar as estimativas de duração das atividades do caminho crítico, ou seja, reduzir a duração do caminho crítico. Isso é realizado utilizando as técnicas de compressão de cronograma que consistem em reduzir o prazo do projeto denido inicialmente sem afetar o escopo para atender restrições de cronograma. As técnicas utilizadas são a compressão e o paralelismo. Na comprensão, as compensações entre custo e cronograma são analisadas para determinar o máximo de compressão para o menor custo incremental. Essa técnica pode produzir uma alternativa não viável devido ao aumento de custo. Na de paralelismo, as fases ou atividades que normalmente serão realizadas em sequenciamento são realizadas em paralelo. Tal técnica pode gerar retrabalho, devido a falta de informações mais detalhadas a respeito de uma atividade. (C) ERRADA Alocar mais recursos ao projeto não é implicação necessária para reduzir o prazo de um projeto. Dependendo da técnica de comprensão de cronograma utilizada, há a necessidade de alocar mais recursos para as atividades relacionadas ao caminho crítico do projeto, mas para isso tem que ser analisado o impacto nanceiro no projeto. Página 32 de 58

34 (D) ERRADA Algumas vezes, ao se diminuir um cronograma, altera-se também o escopo do projeto. É certo que não será a gerência de tempo que fará a alteração do escopo. Será sim a gerência de escopo, informada da diminuição do cronograma pela gerência de integração. De qualquer forma, é importante perceber que uma alteração no cronograma não necessariamente gera alterações das entregas. (E) ERRADA Aumentar o custo de um projeto depende da aprovação das pessoas interessadas, os stakeholders, no projeto, e não é uma negociação fácil. Além de que, o aumento de um custo de um projeto não é uma implicação necessária para reduzir o prazo de um projeto, conforme já descrevemos anteriormente. Página 33 de 58

35 14. Assuntos relacionados: Gerência de Projeto, Gerência de Tempo, Banca: FCC Instituição: MPU Cargo: Analista de Desenvolvimento de Sistemas Ano: 2007 Questão: 55 Considerando o corpo de conhecimento de gerenciamento de projetos, são dependências usadas no sequenciamento de atividades, inerentes à natureza do trabalho que está sendo feito e que freqüentemente envolvem limitações físicas. Também chamadas de lógica rígida (hard logic). Trata-se das dependências (a). explícitas. (b). externas. (c). arbitradas. (d). mandatórias. (e). prioritárias. Solução: A Gerência de Tempo do Projeto inclui os processos necessários para assegurar que o projeto será implementado no prazo previsto. Os seguintes processos principais: 1. Denição das Atividades; 2. Sequenciamento das Atividades; 3. Estimativa da Duração das Atividades; 4. Desenvolvimento do Cronograma; 5. Controle do Cronograma. No sequenciamento de atividades, os relacionamentos lógicos entre as atividades do cronograma são identicados e documentados. O sequenciamento faz uso de relações de precedência adequadas para dar suporte à elaboração do cronograma. Para denir a sequência entre as atividades, são utilizados os seguintes tipos de dependências: Dependências obrigatórias ou mandatórias: devem respeitar as limitações físicas ou restritivas e precisam ser modeladas no planejamento. Ou seja, há fatores que impossibilitam o início de determinada atividade. Por exemplo, antes de testar um código, ele deve, antes, ser construído. Algumas vezes essas dependências são chamadas também de lógica rígida (hard logic); Dependências arbitradas: são dependências estabelecidas com base no conhecimento das melhores práticas dentro de uma área de aplicação especíca ou em algum aspecto pouco usual do projeto. As dependências arbitradas podem, também, ser chamadas de lógica preferida (prefered logic), lógica preferencial (preferential logic) ou lógica na (soft logic); Dependências externas: são aquelas que envolvem relacionamento entre atividades do projeto e atividades que não são do projeto. Por exemplo, a atividade de teste em um projeto de software pode ser dependente da entrega de um hardware de fornecedor externo. Página 34 de 58

36 A letra a ser marcada é a letra (D), já que as dependências mandatórias respeitam as limitações físicas e também são conhecidas como hard logic. Página 35 de 58

37 15. Assuntos relacionados: Gerenciamento de Projetos, Método do Diagrama de Precedência (MDP), Banca: FCC Instituição: TRT 15a Região Cargo: Analista Judiciário - Tecnologia da Informação Ano: 2009 Questão: 47 Os tipos de dependências ou de relações de precedência incluídos no MDP - Método do Diagrama de Precedência são em número de (a). 1. (b). 2. (c). 3. (d). 4. (e). 5. Solução: O MDP (Método do Diagrama de Precedência) é um método de construção de diagramas de rede de cronograma do projeto. Esse diagrama usa retângulos, chamados de nós, para representar as atividades, que são conectadas através de setas. Tais setas são utilizadas para mostrar as dependências entre os nós conectados. A Figura 4 apresenta um MDP, como exemplo, de um projeto relativamente simples. Figura 4: exemplo de MDP. Nesse tipo de diagrama, existem 4 tipos de relações dependência: Término para Início: a iniciação da atividade sucessora depende do término da atividade predecessora. Este é o tipo mais comum; Término para Término: o término da atividade sucessora depende do término da atividade predecessora; Início para Início: a iniciação da atividade sucessora depende da iniciação da atividade predecessora; Início para Término: o término da atividade sucessora depende da iniciação da atividade predecessora. Portanto, é a alternativa D a correta. Página 36 de 58

38 16. Assuntos relacionados: Gerência de Projeto, PMBOK, Cronograma, Caminho Crítico, Banca: Cesgranrio Instituição: BNDES Cargo: Analista de Sistemas - Desenvolvimento Ano: 2008 Questão: 65 O diagrama de rede abaixo representa as atividades de um cronograma de um projeto, onde a duração de cada atividade é mensurada em dias. Se as durações das atividades H e I fossem alteradas, respectivamente, para 4 e 6 dias, qual seria o caminho crítico? (a). A-B-D-I (b). A-C-E-I (c). A-C-E-F-H (d). A-G-F-H (e). A-G-I Solução: A resolução dessa questão é simples e envolve o conhecimento do gerenciamento de tempo previsto pelas melhores práticas contidas no PMBoK. O caminho crítico de um projeto é considerado como a sequência de atividades que levam o projeto do início ao m cujas durações, se sofrerem qualquer atraso, acarretarão em atraso no projeto como um todo. Em um projeto onde não há paralelização de atividades, podemos considerar que a sequência natural das atividades é o próprio caminho crítico. Entretanto, essa análise se altera quando possuímos atividades que ocorrem concomitantemente. Nesses casos, teremos atividades que durarão mais do que outras. As atividades com duração maior geram folgas para o início das outras paralelas a ela. No caso do enunciado, olhemos os caminhos para chegar do ponto 2 ao 5. Veja que temos sequências de atividades paralelas: atividades B e D, com duração de 2 cada uma e duração de 4 no total; atividade G, com duração de 6; atividades C e E, com duração de 2 cada uma e duração de 4 no total. Veja que, para chegarmos até 5, obrigatoriamente teremos que realizar todas as atividades A, B, C, D, E e G. Como a atividade G tem duração de 6, ela dá uma folga para as Página 37 de 58

39 sequências B->D e C->E de 2 unidades de tempo. Logo, um atraso compartilhado de até 2 unidades de tempo nas atividades B e D (entre si) e C e E (também entre si) não atrasará o cronograma. Entretanto, qualquer atraso na atividade G ocasionará atraso no projeto. Assim, para facilitar, vamos analisar o diagrama já com os valores propostos pelo enunciado na Figura 5: Figura 5: diagrama de rede - durações alteradas. Com a denição acima, podemos ver que o caminho crítico passa a ser A->G->F->H. Página 38 de 58

40 17. Assuntos relacionados: Gerência de Projeto, Gerenciamento de Tempo, Gerenciamento de Custos, Assuntos relacionados: SPI Banca: Cesgranrio Instituição: Petrobras Cargo: Analista de Sistemas - Infraestrutura Ano: 2008 Questão: 49 Um gerente, após realizar todos os ajustes necessários no cronograma do seu projeto, obteve a tabela (gura) abaixo. Sabe-se que para este projeto PV (Planned Value) = 400, AC (Actual Cost) = 480 e EV (Earned Value) = 320. Qual é a duração total, em dias, do projeto do gerente, sem considerar nais de semana e feriados, e qual é o valor do SPI (Schedule Performance Index)? (a). 134 e 0,67 (b). 134 e 0,80 (c). 138 e 0,67 (d). 138 e 0,80 (e). 138 e 0,83 Solução: Duração total do projeto A duração total de um projeto é dada é pela soma da duração das atividades críticas do projeto. A duração das atividades e determinação de quais atividades críticas são denidas no processo de Desenvolvimento do cronograma. Segundo o PMBOK, o Desenvolvimento de cronograma é um dos processos da área de conhecimento de Gerenciamento de Tempo. Esta área tem como objetivo determinar as dependências e a duração das atividades do projeto, ou seja, elaborar o cronograma do projeto, e, ao longo do desenvolvimento, acompanhá-lo e controlá-lo. A área de Gerenciamento de Tempo inclui os seguintes processos: denição da atividade: denição de quais as atividades necessárias para produzir as várias entregas do projeto, isto é, os produtos e subprodutos identicados na EAP (Estrutura analítica do projeto - Work Breakdown Structure (WBS)); Página 39 de 58

41 sequenciamento de atividades: identicação e documentação das dependências entre as atividades do cronograma; estimativa de recursos da atividade: estimativa do tipo e das quantidades de recursos necessários para realizar cada atividade do cronograma; estimativa de duração da atividade: estimativa do número de períodos de trabalho que serão necessários para terminar as atividades individuais do cronograma; desenvolvimento do cronograma: análise dos recursos necessários, restrições do cronograma, durações e seqüências de atividades para criar o cronograma do projeto. Ou seja, este processo consiste em formalizar o cronograma, identicando suas datas, caminhos críticos e registrando os marcos e pontos de controle identicados; controle do cronograma: durante o desenvolvimento do projeto, o cronograma deve ser comparado, analisado e revisto sempre que necessário. O caminho crítico, geralmente, é a seqüência de atividades do cronograma que determina a duração do projeto, isto é, o caminho mais longo do projeto. Atividade crítica é qualquer atividade do cronograma em um caminho crítico. Qualquer atraso em uma atividade crítica, pode resultar, em um aumento da duração total do projeto. Para calcularmos a duração total do projeto, conforme a tabela desta questão, devemos denir as atividades do caminho crítico. Para isso, vericamos as dependências entre as atividades. De acordo com a tabela temos as seguintes dependências: a atividade #1 não dependente de nenhuma atividade; o início da atividade #2 depende do término da atividade #1, isto é, a atividade #2 não pode ser iniciada antes do m da atividade #1; o início da atividade #3 depende do término da atividade #2; o início da atividade #4 depende somente do m da atividade #1, isto é, a atividade #4 pode ser iniciada junto com a atividade #2 (é estranho testar um software antes de instalá-lo, mas relevemos isso); o início da atividade #5 depende do m da atividade #4; o início da atividade #6 depende do m da atividade #5; e o início da atividade #7 depende do m da atividade #3 e #6, isto é, a atividade #7 só pode iniciar após o m da atividade #6. Conforme as dependências existentes e a duração de cada atividade, a alocação delas no cronograma é mostrada na Figura 6. Conforme a alocação das atividades do cronograma apresentadas na Figura 6, a duração total do projeto é de 138 dias. Schedule Performance Index Os valores de VP, VA e CR são usados em conjunto para fornecer medidas de desempenho que indicam se o trabalho está sendo realizado conforme planejado em algum momento determinado. A técnica do valor agregado envolve o desenvolvimento destes valores-chave para cada atividade do cronograma ou pacote de trabalho. Esta técnica é empregada no processo Controle de Custos da área de conhecimento Gerenciamento de Custos do projeto. O Valor Planejado (VP) ou Planned Value (PV) é o montante nanceiro que o projeto, de acordo com o planejamento, deveria ter consumido até um dado ponto do cronograma. O VP também é conhecido como Budgeted Cost for Work Scheduled (BCWS) ou Custo orçado para trabalho planejado (COTR). O Valor Agregado (VA) ou Earned Value (EV) é o valor do montante de trabalho que foi efetivamente realizado até uma data especíca. O VA também é conhecido como Budgeted Cost for Work Performed (BCWP) ou Custo orçado para trabalho realizado (COTA). O Custo Real (CR) ou Actual Cost (AC) é o custo efetivo do trabalho realizado até o Página 40 de 58

42 momento. O Custo Real às vezes pode representar somente as horas de mão-de-obra direta, somente os custos diretos ou todos os custos, inclusive custos indiretos. O CR também é conhecido como Actual Cost of Work Performed (ACWP) ou Custo real do trabalho realizado (CRTR). Figura 6: cronograma do projeto. Esses dois valores, a VC e o VP, podem ser convertidos em indicadores de eciência para reetir o desempenho de custos e de prazos de qualquer projeto: Índice de Desempenho de Prazos (IDP) e Índice de desempenho de custos (IDC). O Índice de Desempenho de Prazos (IDP) ou Schedule Performance Index (SPI) é uma medida de eciência do cronograma em um projeto. É a relação entre o valor agregado (VA) e o valor planejado (VP). O IDP é calculado dividindo-se o VA pelo VP. Um IDP maior ou igual a um indica uma condição favorável e um valor menor que um indica uma condição desfavorável. O Índice de desempenho de custos (IDC) ou Cost Performance Index (CPI) é uma medida da eciência de custos em um projeto. É a relação entre o valor agregado (VA) e os custos reais (CR). IDC é calculado dividindo-se VA por CR. Um valor maior ou igual a um indica uma condição favorável e um valor menor que um indica uma condição desfavorável. Página 41 de 58